From: Chris <chr...@gm...> - 2006-07-24 20:20:41
|
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' =96 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= =20 interesting point once about OpenGL drivers that might need to change the=20 display update method on the fly, and the same could be true for Allegro.=20 Allegro should just pick the best (performing) update method given what mod= e=20 its in and with the user is doing. Similar to OpenGL, just have an=20 accessible 'front' buffer and a 'back' buffer, and let the user pick which = to=20 draw to.. this way, they can choose to implement dirty rectangles by drawin= g=20 directly to the front buffer and not needing to flip, or they can stay=20 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), ther= e'd=20 be no need to implicitly do retention and drive down performance.. It might= =20 be useful to allow the user to capture redraw requests from the system in a= =20 cross-platform manner, but I don't see the need for implicit retention. Use= rs=20 using double buffering wouldn't need to worry since it'll be cleared up on= =20 the next frame update, and users doing dirty-rectangles on a non-compositin= g=20 system can just watch for redraw events and add to their internal list of=20 areas to redraw. IMO, anyway. |