Re: [AD] 4.3 display update methods

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2006-07-24 at 11:52 +0100, Peter Hull wrote:
> I know we may be going over old ground here but:
> 
> 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 also think this would make more sense. What is the point of putting
there AL_TRIPLEBUFFER, and then the program will only run on very few
system who support it.

> 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). There might also be a
> 'never-retained' mode which could give better performance if the user
> knows that the display is _always_ going to be redrawn every frame.
> There might also be a direct access mode where the user can get a
> pointer to video memory (or a simulation of it), which would be useful
> for emulators.
> 
> Allegro would then decide how to achieve this – for example retained
> mode might be a window backed by a memory bitmap.
> 
> Would this be possible? Are there other modes that would be necessary?
> 

We also should have something like al_update_rectangle in addition to
al_flip_display, it would not update the complete window, but only a
portion. Drivers who don't support non-retained mode would simply not
implement that.

And I'd rename them a bit, for example:

AL_FLIP - al_flip_display will make changes visible. I guess this is
better than "retained", since we probably won't implement a real
retained mode (where only a list of primitives is stored, and then
executed for al_flip_display).

AL_UPDATE - the non-retained mode. The user would respond to update
events with calls to al_update_rectangle, after redrawing only part of
the window. This would have been most useful in the past for X11, which
always was very slow (with XGL it probably won't matter anymore though).

Both of which could probably be combined with a "direct access" mode,
where Allegro maintains an additional memory cache. So maybe an
AL_DIRECT which can be combined with both?

-- 
Elias Pschernig