RE: [AD] acquire_bitmap weirdness |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sun, 2006-01-01 at 12:06 -0800, Robert Ohannessian wrote:
> This will likely have very negative performance repercussions if all
> functions between acquire/release are hardware accelerated.
Yes, but in that case, acquire_bitmap simply is used wrong.
> Allegro apps can't know if the functions they'll call will be
> accelerated or not, and they certainly can't know it for all platforms
> that Allegro can and might support. In addition, some operations may not
> be hardware accelerated yet require the bitmap to be unlocked (DDraw's
> BltFast is one of them).
Ah, that's bad. I was assuming you could use gfx_capabilities to know if
a function needs locking or not.
> The real solution is d): deprecate acquire/release_bitmap, make them do
> nothing in Windows (what about on X11?), then implement all the Allegro
> functions using the DDraw portion of the API that does not require
> locking.
Would that API also work for putpixel? I mean, right now, if I fill the
screen with putpixel() without acquire_bitmap, it will take much much
longer.. and you say we simply are using the wrong way to place a pixel
with DX?
Also, do you mean we should completely deprecate acquire_bitmap for
4.2.1 - i.e. remove it from the docs? 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.
--
Elias Pschernig