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