RE: [AD] acquire_bitmap weirdness

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


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





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