Re: [AD] 4.3 display update methods

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2006-08-09 at 11:42 +0100, Peter Hull wrote:
> On 7/24/06, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> > 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?
> Does everyone agree with the principle of Elias's suggestion? I'm not
> as happy with the actual names as they don't seem intuitive to me - I
> would prefer something like RETAINED/NON_RETAINED, but then I wasn't
> aware that "retained" refers specifically to storing a list of
> primitives.
> 

Well, the RETAINED or FLIP mode probably needs no special name. Every
driver will be required to support that mode, and it would always be
default. So it means, if I do an al_blit(), nothing can be seen on the
screen at all, until the next al_flip() is called (which usually would
somehow be vsynced by driver or system settings). For most games that
should be all that's needed.

Now, my motivation for the UPDATE mode (i'm not sure it's completely
identical to your NON_RETAINED) is that e.g. the X11 driver can get much
better performance if the user has more control about the update
rectangle, and also about when the updates happen (e.g. when the window
was obscured). The obscured parts redrawing right now is handled in a
weird way by updating it line-by-line from an internal back buffer I
think, and not handled at all with AllegroGL (window stays black until
the next flip). Here, it really would be nice to have a mode where I can
update only the changed parts, and also respond directly to redraw
requests from the window manager.

In this latter mode, it would not be a problem if graphics commands
would work on the front buffer, but also not a requirement. A mode where
updates are required to go only to the front buffer (like when drawing
to 'screen' in 4.2) seems unneeded to me.

Anyway, for actually implementing the first new reference driver, I
think it will be enough to have the normal/retained mode and nothing
else. Drivers also should not be expected to offer additional modes - so
maybe the NON_RETAINED would only be sort of a hint, and after the
window was created you can query if the driver honors it or not.

-- 
Elias Pschernig