RE: [AD] acquire_bitmap weirdness |
[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]
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/ |