Re: [AD] 4.3 display update methods

[Chris Robinson <chris.kcat@xxxxxxxxxx>]

On Wednesday 09 August 2006 08:59, Peter Hull wrote:
> 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.

Which is a flaw, IMO. It's currently needed because on DOS you could assume 
that nothing would interfere with the graphics memory, so when you drew 
to 'screen', it would stay. There was no need for a talk-back mechanism. Then 
X and Windows came along, where your 'screen' could be dirtied by other 
processes at any time, but Allegro had no way of letting you know, and apps 
that aren't aware of such a thing would become problematic, so it had to keep 
a backup copy of what you did.

Now that we have a chance to design the API to be nice with resource sharing, 
we shouldn't try to emulate what is essentially a hack that kept older 
programs working. Let it be known that if you're not double buffering and 
updating regularly, that the screen may be invalidated, and for such, they 
should watch for screen invalidation events. This won't be a problem for most 
people as they'll be hapilly double-buffering at 'ZOMG 1000 FPS', but the 
corner cases need to be handled properly by the user. Keeping Allegro clean 
of this responsibilty directly will help make sure that users get the 
performance benefits from accelerated drivers that they expect, along with 
the control to do it how they want.

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

Examples using the current API to describe new API behavior don't really work, 
as the semantics are different and what is currently normal operations can 
become corner cases (or simply not possible). But still, if 'screen' is the 
front buffer, then I don't believe it should be Allegro's job to maintain the 
screen's cleanliness for you. The back buffer, sure, but the front buffer 
should be considered potentially volatile.

> However, this can give you a
> performance boost (or that's what's suggested in the D3D docs anyway,
> and I know that on my iMac, specifying a retained (my definitition)
> OpenGL context makes it use the software renderer)

Makes sense, since the only way to efficiently retain the back buffer and show 
it on the front buffer is to copy it instead of the faster way of page 
flipping. Accelerated OpenGL implementions don't gaurantee the state of the 
back buffer after a flip (since they don't need to and it provides potential 
performance benefits), so you'd have to use a specialized (software) 
implementation to get otherwise undefined behavior.

> In  both cases you need to call al_flip to make sure the screen is up
> to date with what you've drawn.

If you draw to the front buffer, you should not call al_flip, as that will 
overwrite the front buffer with with whatever was in the back buffer. An 
al_flush command would be more suited to making sure the display target is up 
to date (in both the front and back buffers) without changing them. al_flip 
should just make the back buffer contents visible on the front buffer, and 
leave the back buffer's contents undefined.

> What I think would be a major benefit for Allegro is if concepts like
> 'double buffered' , 'dirty rectangles' and 'video bitmap' became
> irrelevant to the end user - Allegro optimises itself to give the best
> performance for what the user is doing.

Proper dirty rectangles is very different from double buffering, and you can't 
really abstract the two away in an efficient manner. The best way to go would 
be to support double buffering (interacting with the back buffer), but allow 
the user to interact with the front buffer at their own peril.