Re: [AD] 4.3 display update methods

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2006-08-10 at 04:22 -0700, Chris Robinson wrote:
> 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.

Ah, ok. So my scenario simply would allow to draw to the front buffer -
but probably a better implementation would draw to the back buffer in
any case.

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

That would be a special case though, which we don't need to care about
in Allegro. If I can get a handle to a window of another application and
draw to it, then that's not a problem of the application this window
belongs to.

So basically, we have these ways to deal with it:

#1 Never provide update events, and trust that by the time Allegro 4.4
is out, all drivers will use compositing. And users could simply assume
that widow contents are preserved (which in the worst case means, X11
users must be careful not to obscure their window in certain Allegro
apps who don't do full updating each frame).

#2 Provide update events. Under Windows and OSX, those would never be
generated. But it would allow users to optionally deal with the case of
drivers (old X11) where window contents need updating.

#3 Never procide update events, and require drivers to make sure window
contents are preserved. This would be possible by maintaining a memory
buffer and updating the real display only from that buffer, reacting to
update events inside the driver. I'd say this is out of the question
though, since it will kill any performance.

Personally, I'd go for a hybrid of #1 and #2 - allow for the possibility
of such update events, but not implement them in standard drivers, at
least not initially.

-- 
Elias Pschernig