Re: [AD] 4.3 display update methods

[Chris <chris.kcat@xxxxxxxxxx>]

On Monday 24 July 2006 03:52, Peter Hull wrote:
> Looking at the update method flags for the display, I see that they
> are 'implementations' – i.e. double buffer, triple buffer etc.
>
> I think it would be desirable, and in the spirit of things we
> discussed earlier, if they were instead a representation of what the
> user wants to achieve.

I think it would be best to not give the user an option at all. Bob made an 
interesting point once about OpenGL drivers that might need to change the 
display update method on the fly, and the same could be true for Allegro. 
Allegro should just pick the best (performing) update method given what mode 
its in and with the user is doing. Similar to OpenGL, just have an 
accessible 'front' buffer and a 'back' buffer, and let the user pick which to 
draw to.. this way, they can choose to implement dirty rectangles by drawing 
directly to the front buffer and not needing to flip, or they can stay 
buffered and flip every completed frame.

> I imagine that the user might want to specify a 'retained' mode, where
> anything drawn is maintained by Allegro, and a 'non-retained' mode, if
> the user is able to respond to a system request to redraw the display
> (this would be handled via events).

With compositing desktops coming up (and in some cases, already here), there'd 
be no need to implicitly do retention and drive down performance.. It might 
be useful to allow the user to capture redraw requests from the system in a 
cross-platform manner, but I don't see the need for implicit retention. Users 
using double buffering wouldn't need to worry since it'll be cleared up on 
the next frame update, and users doing dirty-rectangles on a non-compositing 
system can just watch for redraw events and add to their internal list of 
areas to redraw.

IMO, anyway.