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