Re: [AD] Recent 4.3 change?

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

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.


> -----Original Message-----
> From: alleg-developers-bounces@xxxxxxxxxx [mailto:alleg-
> developers-bounces@xxxxxxxxxx] On Behalf Of Chris Robinson
> Sent: Tuesday, August 01, 2006 4:51 PM
> To: alleg-developers@xxxxxxxxxx
> Subject: [AD] Recent 4.3 change?
> 
> I recently woke up, so I don't know how old this is, but one of the
bots
> alerted to a commit:
> 
> <juvbotz> Allegro updated, r7433 [peterhull90]
> <juvbotz> Simulation of video bitmaps, so that page flipping will work
> 
> Assuming this change was for 4.3, I really think this should be
reverted
> and
> properly discuessed.
> 
> I don't think it is Allegro's place to be emulating video bitmaps when
the
> driver doesn't support them (let alone to allow page flipping, which
is
> supposed to be abstracted away in the new API anyway so Allegro can
pick
> the
> best update method). It's a big cause of slowdown in the X11 driver as
it
> makes twice the work (attempt to draw to the actual screen as well as
the
> memory bitmap emulating a video surface every time you draw to
"VRAM"),
> and
> can lead to odd little errors when what's drawn to the screen is
slightly
> different than what Allegro draws to the video emulation bitmap.
> 
> In 4.2 we can't really get away without making a "backup" of the
screen,
> since
> screen updates are completely arbitrary by the user (though even
still, I
> don't support extending the screen backup bitmap to behave like a
larger
> VRAM
> surface; I've argued to remove this ability from the X11 driver).
However,
> as
> I've mentioned in the OpenGL thread, using the new API there's no
direct
> need
> for Allegro to keep a backup of the screen. With the new API, you'll
have
> basically two update methods: double buffered (draw to an off-screen
> buffer,
> which is later made visible), and dirty rectangles (draw directly to
the
> visible screen buffer based on what's been dirtied). For the latter,
the
> user
> can watch for screen-invalidation events and add the sections to a
list of
> rectangles to draw. For the former, the user will supply a complete
buffer
> on
> the next update which would clear up any dirty spot. This would allow
for
> a
> nice all-around increase in speed (or retention of speed, in OpenGL's
> case),
> which would be negated by emulating a VRAM surface.
> 
>
------------------------------------------------------------------------
-
> 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.
-----------------------------------------------------------------------------------