Re: [AD] 4.3 display update methods

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Wed, 2006-08-09 at 16:59 +0100, Peter Hull wrote:
> On 8/9/06, Chris Robinson <chris.kcat@xxxxxxxxxx> wrote:
> > On Wednesday 09 August 2006 07:28, Elias Pschernig wrote:
> > > As I understand, the retained just means that you need to call al_flip
> > > before graphics updates get visible. So it is retained in that al_line
> > > won't immediately make a line appear, but only the next al_flip.
> >
> > Ah. You mean double buffering, then. When I think of retained, I think that
> > it's kept after use (eg. something is retained for later use). I think
> > AL_DOUBLEBUFFER or some such would be clearer to indicate that the commands
> > won't be immediately visible.
> 
> When I say retained, I mean that 'the system' (i.e Allegro + the OS)
> will keep whatever you drew on the screen forever. This is like
> current Allegro. For example you can make a simple drawing program
> just by calling
> if (mouse_b) putpixel(screen, mouse_x, mouse_y, color);
> in a loop. The app doesn't need to remember which pixels are supposed
> to be lit. Maybe 'maintained' is a better word?

Ah, ok, I had misunderstood then. So basically, in OpenGL, it would
mean, you somehow expect a persistent front buffer. I'm not sure if you
can enforce that.

And what would al_flip() do in that mode? Would it get a no-op?

I can see how it would be useful to have such a mode, but I think you
can always get more performance with the mode where the OS/window
manager sends events about rectangles who need updating (and then let
the user maintain a memory buffer or whatever else).

Such a persistent mode could also easily be implemented as a driver
independent addon. But anyway, if there's drivers who could benefit from
it performance-wise in a way not possible with the other modes, we
should probably add it.

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/