Re: [AD] acquire_bitmap weirdness

[Chris <chris.kcat@xxxxxxxxxx>]

On Monday 02 January 2006 05:15, Elias Pschernig wrote:
> 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.

Huh? Without the acquire/release_bitmap pair there, blit() would lock/unlock 
the bitmap for every sprite shown, if it's a memory bitmap. By doing it 
outside the loop, it only locks once, and would therefor be faster. If the 
sources are video bitmaps and HW blitting is available, it'll lock once at 
the acquire call, then unlock once at the first blit call, and stay unlocked.

> 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..

You sure? If the source is a memory bitmap, that's as fast as you'll get. 
Instead of locking and unlocking once for the blit, and then locking again 
for all the putpixels. If it's a video bitmap, it'll lock/unlock twice. It'll 
lock at the acquire call, unlock at blit, lock at putpixel, and stay locked 
untill release_bitmap.

And you can't assume acquire/release is needed only on unaccelerated 
functions. Under X it does a mutex lock to avoid Xlib async errors. The 
"video" vtables call the X functions to draw to the window directly, for some 
functions, and they may or not be accelerated.. but they still need to be 
locked for the mutex. Without the explicit lock/unlock call outside all the 
to-screen functions, that'd be a lot of mutex locks (very slow).