Re: [AD] outdated files cleanup

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sun, 2006-08-13 at 22:36 +0200, Evert Glebbeek wrote:
> On Sunday 13 August 2006 22:15, Elias Pschernig wrote:
> > get rid of the current al_create_display which simply hooks into the 4.2
> > set_gfx_mode.
> 
> I suppose you mean, rewrite al_create_display() to use the new drivers 
> rather than piggy-bagging on top of the old drivers? ;)
> Anyway, arguing semantics. Personally I think it's a good idea to at least 
> temporarily remove or disable unused drivers, because I found that having 
> them around was a deterrent for working on the new drivers.

Yes, that's exactly my motivation. Can't say why, but all the outdated
stuff makes me cd .. out of 4.3 again whenever I want to start working
on the display code :)

> On that note, I haven't followed any of the discussion from the past week 
> or so since I was on vacation; if someone can summarise what has been 
> discussed with regard to display update methods I'd be grateful to them.
> I'll be at a conference for the next two weeks, so I won't get round to 
> doing any Allegro-related programming, but I will probably be able to 
> follow e-mail discussions.
> 

Basically, there seems to be agreement that we don't want the user to
choose the low level details, but let Allegro mostly figure out what's
best. Specifically, the only required default mode for graphics drivers
should be:

NON_IMMEDIATE, NO_RETAINED_FRONT_BUFFER, NO_RETAINED_BACK_BUFFER

Which means:

NON_IMMEDIATE: When you draw something, then it only gets visible at the
next al_flip().

NO_RETAINED_FRONT_BUFFER: The contents of the front buffer are not
guaranteed to be preserved. E.g. when the user alt-tabs away in
fullscreen or maybe even if the window gets obscured by another, then
window contents may get lost. (Probably we also want to allow for UPDATE
events, usng the display as an events source, which notify of rectangles
needing an update - so optionally, users could code a more efficient
update mechanism than updating the whole screen each frame.)

NO_RETAINED_BACK_BUFFER: If you draw something, then do al_flip(), you
cannot expect graphics read back from the display to be the same as
before. E.g.: putpixel(0, 0, 5); al_flip(); then getpixel(0, 0) could be
5, or not. The reason is, we might otherwise force drivers to choose
some internal mechanism over another, like flipping vs buffering, which
the user shouldn't have to decide.

-- 
Elias Pschernig