Re: [AD] Recent 4.3 change?

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

> I can't see any reason where Allegro would decide to do DRS on its
own,
> given
> that the user would have to supply a full buffer (back buffer
retention is
> not gauranteed everywhere and potentially comes with penalties where
it
> is),


Indeed. Similar to the current system, Allegro will need to tell apps
that they need to do a full redraw if the backbuffer is lost. However,
in 99% of the cases it's not and you can just get the app to draw into
the portions of the screen that it changes without touching the rest.
After that, it's up to Allegro to decide if it needs a backbuffer or if
it can do without one.

I'd much rather have the smarts in one place, where it's easy to fix or
influence algorithm policies, than distributed among thousands of
applications.




> -----Original Message-----
> From: alleg-developers-bounces@xxxxxxxxxx [mailto:alleg-
> developers-bounces@xxxxxxxxxx] On Behalf Of Chris Robinson
> Sent: Tuesday, August 01, 2006 9:37 PM
> To: Coordination of admins/developers of the game programming library
> Allegro
> Subject: Re: [AD] Recent 4.3 change?
> 
> On Tuesday 01 August 2006 18:17, Robert Ohannessian wrote:
> > Just let Allegro pick the best method. If DRS is best in X, then
that's
> > what the X driver should do by default. DRS, after all, can be
reduced
> > to double buffering.
> 
> Well, what I was thinking of with DRS would be that the app could
update
> any
> part of the screen when it wanted however often it wanted (much like
now),
> instead of being forced to update a preserved off-screen buffer then
flip
> (of
> course, this may still be preferable depending on the app, but still).
> 
> I'm talking like a GUI. You draw the widgets once, then don't touch
them
> again
> until they get dirty. The idea being that /you/ only draw the updated
> areas.
> If you let Allegro decide to do DRS for you, you'd have to redraw
> everything
> to the back buffer (incase it doesn't want to do DRS and/or back
buffer
> retention is not available), flip, and have Allegro only update the
parts
> of
> the screen that are different. Instead of just drawing to the front
buffer
> yourself.
> 
> I can't see any reason where Allegro would decide to do DRS on its
own,
> given
> that the user would have to supply a full buffer (back buffer
retention is
> not gauranteed everywhere and potentially comes with penalties where
it
> is),
> have Allegro read and compare it to the front buffer, then only update
> where
> it's different. It'd be faster to have just copied it all over to
begin
> with.
> To get the most speed benefits from DRS, the programmer himself would
have
> to
> draw just the updates (and even still, it can be iffy that DRS may be
> faster)
> and be in control of how it's copied to the front buffer.
> 
>
------------------------------------------------------------------------
-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
share
> your
> opinions on IT & business topics through brief surveys -- and earn
cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
> --
> 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.
-----------------------------------------------------------------------------------