Re: [AD] 4.3 display update methods

[Chris Robinson <chris.kcat@xxxxxxxxxx>]

On Thursday 10 August 2006 03:39, Elias Pschernig wrote:
> > 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.

I don't see any reason why you would want the front buffer to also be the back 
buffer. It's completely the opposite of what the back buffer is, which is an 
off-screen buffer you fill up before flipping to show. If you draw to the 
back buffer, it shouldn't ever be visible until it's copied to the front 
buffer.

If you think about it like page flipping, the front buffer is the currently  
visible page, and the back buffer the non-visible page. Drawing to the back 
buffer shouldn't affect the front buffer/screen until its flipped, when the 
back buffer becomes the front buffer and the front buffer becomes the back 
buffer. If you want to draw directly to the visible page you can, but it's 
still the front buffer, not the back buffer.

> 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.

OSX, I'm pretty sure at least, does compositing, so typically another process 
won't be able to dirty your front buffer. The same would be true under X with 
compositing. X without compositing doesn't keep a backup of your window, so 
any changes to that part of the screen invalidates your front buffer.

I don't know how Windows behaves, though I wouldn't be surprised if it does 
some compositing too.

But even with compositing, you can't gaurantee a retained front buffer. 
Another process could grab a handle to your window and draw to the front 
buffer itself, and I'm pretty sure that doesn't generate invalidation events.