Re: [AD] 4.3 display update methods

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/