RE: [AD] acquire_bitmap weirdness

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


Title: RE: [AD] acquire_bitmap weirdness
This is the wrong approach. What happens when putpixel() becomes hardware accelerated and needs an unlocked bitmap? The same question applied to any and all Allegro functions that we might have recommended users to put in between acquire/release pair.
 
Secondly, for the last 5 years or so, the docs and the community have always recommended writing the code I had below, even when hardware accelerated blits were used. Changing this behavior to make it slower will negatively affect hundreds (if not more) of Allegro applications.

 

From: alleg-developers-admin@xxxxxxxxxx on behalf of Elias Pschernig
Sent: Mon 1/2/2006 5:15 AM
To: alleg-developers@xxxxxxxxxx
Subject: RE: [AD] acquire_bitmap weirdness

On Sun, 2006-01-01 at 20:51 -0800, Robert Ohannessian wrote:

>
> That's a bad idea. Most apps do things like:
>
>
> acquire_bitmap(my_video_backbuffer);
>
> for (i = my_sprites.begin(); i != my_sprites.end(); i++) {
>
>     blit(i->bitmap, my_video_bitmap, ...);
>
> }
>
> release_bitmap(my_video_backbuffer);
>

I would consider this broken code.. you are not supposed to use
acquire_bitmap here, under no platform. It can be sped up by simply not
using acquire_bitmap.

But what if code looks like this:

acquire_bitmap(my_video_backbuffer);
blit(i->bitmap, my_video_bitmap, ...);
for (i = 0; i < 640 * 480; i++) {
    pupixel(my_video_bitmap...)
}
release_bitmap(my_video_backbuffer);

Right now, this will be very slow, and if you move the blit one line up,
suddenly gets fast.. I find it just unaceptable from an API semantics
point of view.

> If blit() unlocks the bitmap (as it tends to do under Windows) and you
> reloc it right after, then you'll spend all the time in your loop just
> locking and unlocking the bitmap. Locks are really really slow.
> They're measured in tens of millisecond. You really don't want to do
> more than 1-2 lock/frame.

Yes. So that's the one big drawback of my proposed solution, existing
code which uses acquire_bitmap in the way of your example above will get
very slow.

Well, attached is a rework of my old acquire_bitmap patch, merely
extended with stating some of the facts about the DX driver, for now.
That should probably get applied in any case. And personally, I'm still
(slightly) in favor of changing the semantics to not have functions
(like your blit above) auto-unlock.

--
Elias Pschernig



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