RE: [AD] acquire_bitmap weirdness

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


Title: RE: [AD] acquire_bitmap weirdness
> But with #1, acquire_bitmap gives a big speed advantage when grouping
many putpixel calls, right?
 
Yup. #3 won't change that much, though.
 
> A question would now be, is #3 faster even
in that case..
Why should it matter? Any app that depends on putpixel being fast is broken. I don't think we should be optimizing for the uncommon case. Besides, having apps not have to worry about which operations need or don't need locking under which OS / hardware combinations is a Good Thing(tm), and a better goal than making putpixel some % faster (or not slower).
 
> So "normal" users never would use
> acquire_bitmap, and we never would lock the DX surface implicitly
> either.
That would be the idea. That said, I don't know how DOS/X11/other platforms' needs affect this. It would be far better to have one simple rule that can be applied to most/all apps, rather than the current horribly tedious set of complicated rules and exceptions.
 
 
> And if you use other drawing operations on a locked bitmap, they are slow,
> since either they need to do temporal un-locking, or can't be done
> accelerated.
 
Correct.
 
> The only problem is, existing code might run slower, since
> acquire_bitmap might be used in a wrong way.
 
That's fine. Most Allegro apps tend to surround varieties of blit with acquire_bitmap and not much more.

 

> Anyway, I would change the DX port for now to re-lock a bitmap if one of
the accelerated drawing functions unlocks it (my suggestion "c"). If
acquire_bitmap is used properly, that will work on all platforms without
slowdown. And especially, this would make the semantics clear for all
platforms - unlike now, where some random DX functions simply unlock the
surface.

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);

 

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.


 
 


From: alleg-developers-admin@xxxxxxxxxx on behalf of Elias Pschernig
Sent: Sun 1/1/2006 5:58 PM
To: alleg-developers@xxxxxxxxxx
Subject: RE: [AD] acquire_bitmap weirdness

On Sun, 2006-01-01 at 17:07 -0800, Robert Ohannessian wrote:

> There are basically three ways of drawing a single pixel on screen: 1)
> Locking the bitmap, writing 1 to 4 bytes, then unlocking the bitmap.
> 2) Creating a 1x1 bitmap containing the color you want, and then
> BltFast() it. 3) Use a rectangle clear. All of the above are pitifully
> slow, but at least, #3 is the least sucky of all of those (if we can
> avoid locking).

But with #1, acquire_bitmap gives a big speed advantage when grouping
many putpixel calls, right? A question would now be, is #3 faster even
in that case..

> If locking can't be avoided, we could have putpixel select to either
> copy the bytes itself (if the bitmap is already locked), or use a
> clear rectangle (if the bitmap is unlocked).


Sounds like a good idea. So "normal" users never would use
acquire_bitmap, and we never would lock the DX surface implicitly
either.


> > Otherwise, we still need to update
> > those docs and state how it works, I guess it would be my proposed
> a)
> > then, simply state how it works under DX and does auto-unlocking,
> and
> > also list all the affected functions.

> Ok, then how do you write portable Allegro code that also performs
> descently on the big 2 platforms?


Well, my idea was, acquire_bitmap in 4.2 should be used only when you do
lots of putpixel or need to access the line pointers.

The normal operation should always be to not use acquire_bitmap. And if
you use other drawing operations on a locked bitmap, they are slow,
since either they need to do temporal un-locking, or can't be done
accelerated. The only problem is, existing code might run slower, since
acquire_bitmap might be used in a wrong way.

Anyway, I would change the DX port for now to re-lock a bitmap if one of
the accelerated drawing functions unlocks it (my suggestion "c"). If
acquire_bitmap is used properly, that will work on all platforms without
slowdown. And especially, this would make the semantics clear for all
platforms - unlike now, where some random DX functions simply unlock the
surface.

Then independent of that, all implicit locking under DX could be
replaced as you said initially - so there would be even less need to use
acquire_bitmap.

About X11, I don't think acquire_bitmap makes lots of difference there.
I certainly never use it. And in X11, there's also the issue of the
auto-line-updater running in the background all the time - but that's
for another time.

--
Elias Pschernig



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers



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