Re: [AD] 4.3 display update methods

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2006-08-10 at 03:20 -0700, Chris Robinson wrote:
> On Thursday 10 August 2006 02:51, Peter Hull wrote:
> > FRONT BUFFER: the visible window being shown
> > BACK BUFFER: the destination for all drawing operations.
> > (this doesn't imply any implementation, they could be the same thing,
> > as it is now for the 4.2 'screen' bitmap)
> 
> I'd vote for these two to always be seperate (eg. the back buffer will never 
> be the front buffer). In worst-case scenario, it can be a memory bitmap.

Well, in some scenarios, I could see that it makes sense if at least
internally, it is allowed (never required). Specifically, in response to
those update events mentioned earlier.

> > IMMEDIATE: means that drawing appears straight away
> > NOT IMMEDIATE: no drawing is visible until al_flip is called.
> 
> These should only be implied depending on which buffer (front or back) you 
> draw to, respectively, and not need an explicit mode set for it. Drawing to 
> the front buffer may still require a flush-type call, though (eg. glFlush, 
> XSync, etc).

Exactly. IMMEDIATE implies you draw directly to the front buffer, NOT
IMMEDIATE means you draw to the back buffer. And yes, even when drawing
to the front buffer, we need to provide some sort of flush call.

> 
> > FRONT BUFFER RETAINED: Whatever is visible will remain even if the
> > window is covered and uncovered. You will never receive repaint events
> > from the OS.
> > FRONT BUFFER NOT RETAINED: The app will receive repaint events from
> > the OS, which may be the whole buffer or just a sub-region.
> 
> Allegro itself shouldn't need to worry about retaining the front buffer. At 
> most, it could be implemented as a generic driver that works on top of an 
> actual system driver, and provides no acceleration or hardware capabilities.. 
> but I think that's a little out of scope for Allegro to do.

That's just the problem now. It seems from this thread that both Windows
and OSX will retain the front buffer (Is this also true when they
operate in OpenGL mode?). In this case, it would be tempting to specify
a retained front buffer as Allegro semantics - however, I don't see how
we could possibly do it under (current) X11.

> > BACK BUFFER RETAINED: After a flip, whatever had been drawn remains so
> > you can draw on top of it
> > BACK BUFFER NOT RETAINED: After a flip, you need to redraw everything.
> 
> A retained back buffer shouldn't be gauranteed, ever. It limits Allegro in 
> what it can pick for best performance, lowers performance of some drivers, 
> and is completely unavailable on others.

Seconded. It would be too much internal information, like it might
restrict the driver to choose a back buffer over flipping.

> > X does not retain the front buffer?
> 
> X and OpenGL.
> 

Where the question now is, how do Windows and OSX OpenGL work? In X11,
when I make a 3-line program to simpy open a window, attach a GLX
context, then do a glClear - moving another window over it will leave a
trail of garbage. Can someone confirm this is really not the case under
Windows and OSX? If they behave the same, then preserved front buffer
would be out of the question.

-- 
Elias Pschernig