Re: [AD] 4.3 display update methods

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

I was referring to NOT IMMEDIATE, FRONT BUFFER NOT RETAINED, BACK BUFFER
NOT REATAINED by default. If some drivers can do something else, then
good for them. However, apps should not depend on retaining anything
and/or immediate drawing.

You can always implement the above system on top of a system that does
retain buffers or shows immediately, but it's really difficult to do it
the other way around.

AllegroGL violates the Allegro semantics here by basically having a NOT
IMMEDIATE, FRONT BUFFER NOT RETAINED, BACK BUFFER NOT REATAINED system
(even when you use Allegro functions) so it's sometimes very difficult
to port some existing Allegro apps to AGL.

Having AGL somehow retain everything and draw immediately would be very
difficult and/or very slow.


> -----Original Message-----
> From: alleg-developers-bounces@xxxxxxxxxx [mailto:alleg-
> developers-bounces@xxxxxxxxxx] On Behalf Of Peter Hull
> Sent: Thursday, August 10, 2006 4:51 AM
> To: Coordination of admins/developers of the game programming library
> Allegro
> Subject: Re: [AD] 4.3 display update methods
> 
> Right, I think we need to nail this one before we can proceed, for my
> benefit at least...
> 
> How about this:
> 
> FRONT BUFFER: the visible window being shown
> BACK BUFFER: the destination for all drawing operations.
> (this doesn't imply any implementation, they could be the same thing,
> as it is now for the 4.2 'screen' bitmap)
> 
> IMMEDIATE: means that drawing appears straight away
> NOT IMMEDIATE: no drawing is visible until al_flip is called.
> 
> FRONT BUFFER RETAINED: Whatever is visible will remain even if the
> window is covered and uncovered. You will never receive repaint events
> from the OS.
> FRONT BUFFER NOT RETAINED: The app will receive repaint events from
> the OS, which may be the whole buffer or just a sub-region.
> 
> BACK BUFFER RETAINED: After a flip, whatever had been drawn remains so
> you can draw on top of it
> BACK BUFFER NOT RETAINED: After a flip, you need to redraw everything.
> 
> So the mode you are talking about, Bob, is "not immediate, front
> buffer retained, back buffer not retained."?
> 
> And the problem for Linux is that X does not retain the front buffer?
> 
> Is that any clearer?
> 
> Pete
> 
> 
> On 8/9/06, Robert Ohannessian <ROhannessian@xxxxxxxxxx> wrote:
> > I meant FLIP aka RETAINED. We can always implement one as the other,
if
> > ever that would be needed.
> >
> > > -----Original Message-----
> > > From: alleg-developers-bounces@xxxxxxxxxx
[mailto:alleg-
> > > developers-bounces@xxxxxxxxxx] On Behalf Of Peter Hull
> > > Sent: Wednesday, August 09, 2006 1:26 PM
> > > To: Coordination of admins/developers of the game programming
library
> > > Allegro
> > > Subject: Re: [AD] 4.3 display update methods
> > >
> > > Bob, sorry, can you just explain exactly what you mean by
> > > FLIP/RETAINED and FLIP/UPDATE?
> > >
> > > Pete
> > >
> > >
> > > On 8/9/06, Robert Ohannessian <ROhannessian@xxxxxxxxxx> wrote:
> > > > Double-buffering isn't the only update mode. When you "flip",
the
> > > > current render buffer content should be undefined. In debug
mode, we
> > can
> > > > even clear it to some garbage (random?) value to catch apps that
do
> > the
> > > > wrong thing.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: alleg-developers-bounces@xxxxxxxxxx
> > [mailto:alleg-
> > > > > developers-bounces@xxxxxxxxxx] On Behalf Of Chris
> > Robinson
> > > > > Sent: Wednesday, August 09, 2006 11:55 AM
> > > > > To: Coordination of admins/developers of the game programming
> > library
> > > > > Allegro
> > > > > Subject: Re: [AD] 4.3 display update methods
> > > > >
> > > > > On Wednesday 09 August 2006 08:59, Peter Hull wrote:
> > > > > > When I say retained, I mean that 'the system' (i.e Allegro +
the
> > OS)
> > > > > > will keep whatever you drew on the screen forever. This is
like
> > > > > > current Allegro.
> > > > >
> > > > > Which is a flaw, IMO. It's currently needed because on DOS you
> > could
> > > > > assume
> > > > > that nothing would interfere with the graphics memory, so when
you
> > > > drew
> > > > > to 'screen', it would stay. There was no need for a talk-back
> > > > mechanism.
> > > > > Then
> > > > > X and Windows came along, where your 'screen' could be dirtied
by
> > > > other
> > > > > processes at any time, but Allegro had no way of letting you
know,
> > and
> > > > > apps
> > > > > that aren't aware of such a thing would become problematic, so
it
> > had
> > > > to
> > > > > keep
> > > > > a backup copy of what you did.
> > > > >
> > > > > Now that we have a chance to design the API to be nice with
> > resource
> > > > > sharing,
> > > > > we shouldn't try to emulate what is essentially a hack that
kept
> > older
> > > > > programs working. Let it be known that if you're not double
> > buffering
> > > > and
> > > > > updating regularly, that the screen may be invalidated, and
for
> > such,
> > > > they
> > > > > should watch for screen invalidation events. This won't be a
> > problem
> > > > for
> > > > > most
> > > > > people as they'll be hapilly double-buffering at 'ZOMG 1000
FPS',
> > but
> > > > the
> > > > > corner cases need to be handled properly by the user. Keeping
> > Allegro
> > > > > clean
> > > > > of this responsibilty directly will help make sure that users
get
> > the
> > > > > performance benefits from accelerated drivers that they
expect,
> > along
> > > > with
> > > > > the control to do it how they want.
> > > > >
> > > > > > For example you can make a simple drawing program
> > > > > > just by calling
> > > > > > if (mouse_b) putpixel(screen, mouse_x, mouse_y, color);
> > > > > > in a loop. The app doesn't need to remember which pixels are
> > > > supposed
> > > > > > to be lit. Maybe 'maintained' is a better word?
> > > > >
> > > > > Examples using the current API to describe new API behavior
don't
> > > > really
> > > > > work,
> > > > > as the semantics are different and what is currently normal
> > operations
> > > > can
> > > > > become corner cases (or simply not possible). But still, if
> > 'screen'
> > > > is
> > > > > the
> > > > > front buffer, then I don't believe it should be Allegro's job
to
> > > > maintain
> > > > > the
> > > > > screen's cleanliness for you. The back buffer, sure, but the
front
> > > > buffer
> > > > > should be considered potentially volatile.
> > > > >
> > > > > > However, this can give you a
> > > > > > performance boost (or that's what's suggested in the D3D
docs
> > > > anyway,
> > > > > > and I know that on my iMac, specifying a retained (my
> > definitition)
> > > > > > OpenGL context makes it use the software renderer)
> > > > >
> > > > > Makes sense, since the only way to efficiently retain the back
> > buffer
> > > > and
> > > > > show
> > > > > it on the front buffer is to copy it instead of the faster way
of
> > page
> > > > > flipping. Accelerated OpenGL implementions don't gaurantee the
> > state
> > > > of
> > > > > the
> > > > > back buffer after a flip (since they don't need to and it
provides
> > > > > potential
> > > > > performance benefits), so you'd have to use a specialized
> > (software)
> > > > > implementation to get otherwise undefined behavior.
> > > > >
> > > > > > In  both cases you need to call al_flip to make sure the
screen
> > is
> > > > up
> > > > > > to date with what you've drawn.
> > > > >
> > > > > If you draw to the front buffer, you should not call al_flip,
as
> > that
> > > > will
> > > > > overwrite the front buffer with with whatever was in the back
> > buffer.
> > > > An
> > > > > al_flush command would be more suited to making sure the
display
> > > > target is
> > > > > up
> > > > > to date (in both the front and back buffers) without changing
> > them.
> > > > > al_flip
> > > > > should just make the back buffer contents visible on the front
> > buffer,
> > > > and
> > > > > leave the back buffer's contents undefined.
> > > > >
> > > > > > What I think would be a major benefit for Allegro is if
concepts
> > > > like
> > > > > > 'double buffered' , 'dirty rectangles' and 'video bitmap'
became
> > > > > > irrelevant to the end user - Allegro optimises itself to
give
> > the
> > > > best
> > > > > > performance for what the user is doing.
> > > > >
> > > > > Proper dirty rectangles is very different from double
buffering,
> > and
> > > > you
> > > > > can't
> > > > > really abstract the two away in an efficient manner. The best
way
> > to
> > > > go
> > > > > would
> > > > > be to support double buffering (interacting with the back
buffer),
> > but
> > > > > allow
> > > > > the user to interact with the front buffer at their own peril.
> > > > >
> > > > >
> > > >
> >
------------------------------------------------------------------------
> > > > -
> > > > > Using Tomcat but need to do more? Need to support web
services,
> > > > security?
> > > > > Get stuff done quickly with pre-integrated technology to make
your
> > job
> > > > > easier
> > > > > Download IBM WebSphere Application Server v.1.0.1 based on
Apache
> > > > Geronimo
> > > > >
> > > >
> >
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > > > --
> > > > > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> > > >
> >
------------------------------------------------------------------------
> > > -----------
> > > > This email message is for the sole use of the intended
recipient(s)
> > and
> > > may contain
> > > > confidential information.  Any unauthorized review, use,
disclosure
> > or
> > > distribution
> > > > is prohibited.  If you are not the intended recipient, please
> > contact
> > > the sender by
> > > > reply email and destroy all copies of the original message.
> > > >
> >
------------------------------------------------------------------------
> > > -----------
> > > >
> > > >
> >
------------------------------------------------------------------------
> > > -
> > > > Using Tomcat but need to do more? Need to support web services,
> > > security?
> > > > Get stuff done quickly with pre-integrated technology to make
your
> > job
> > > easier
> > > > Download IBM WebSphere Application Server v.1.0.1 based on
Apache
> > > Geronimo
> > > >
> >
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > > --
> > > > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> > > >
> > >
> > >
> >
------------------------------------------------------------------------
> > -
> > > Using Tomcat but need to do more? Need to support web services,
> > security?
> > > Get stuff done quickly with pre-integrated technology to make your
job
> > > easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > >
> >
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > --
> > > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> >
> >
------------------------------------------------------------------------
> -
> > Using Tomcat but need to do more? Need to support web services,
> security?
> > Get stuff done quickly with pre-integrated technology to make your
job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> >
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > --
> > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> >
> 
>
------------------------------------------------------------------------
-
> Using Tomcat but need to do more? Need to support web services,
security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers