Re: [AD] Locking Behaviour

[Milan Mimica <milan.mimica@xxxxxxxxxx>]

Paul Suntsov wrote:
> Thirdly, if the second point is implemented, both the destination and the source bitmaps should remain
> locked, I think.
> More generally, here's how I'd imagine myself these things working: memory routines and such that
> require locked bitmaps will first check to see if the regions they want to 
draw to are locked, locking
> them if they are not. When they are done, they leave them locked. Now, the 
routines that require unlocked
> bitmaps (all hardware accelerated ones, at least) check if their required 
bitmaps are locked or not, and
> unlock them themselves if they are. al_flip_display, for example, will make 
sure to unlock the back and
> front buffers. I think this sort of behaviour would be optimal in terms of 
the number of required
> locks/unlocks (I believe this is the sort of strategy A4 used for 
release/acquire functions). Now,
> I know this violates the leave-global-state-as-it-was-when-you-got-it 
strategy, but I think it makes
> sense in this situation. Right now the functions are too fail-happy for my 
liking.

Routines don't require locked or unlocked bitmaps - drawing method is chosen 
based on the locked state of a bitmap. You are proposing to make it the other 
way around. I'm not saying that your proposal is flawed, just want to make it 
clear that things are how they are because someone has designed them this way.

This way the user gets to choose whether to use SW or HW routines, by locking or 
not locking the bitmap. If you are going to perform many al_get_pixel() 
operations on a bitmap you'd better lock that bitmap because reading single 
pixels from (display) bitmaps is slow is most cases.

One thing I don't understand though, if we have both hardware and software 
implementation for each drawing routine, what do you mean by "routines that 
require locked/unlocked bitmap"?

> Now, about al_lock_bitmap_region itself, right now it fails if the bitmap is locked already:
>
> if (bitmap->locked)
>    return NULL;
>
> Would it perhaps be better to unlock the bitmap in this case, and re-lock it as usual? Just seems like less
> of a hassle this way (I can't imagine any situation when you wouldn't want to 
do that upon failure anyway,
> that couldn't be handled via al_is_bitmap_locked check).

Yeah, I would like that. It could be further optimized to not perform full 
unlock/lock if the regions overlap. We don't need bitmap_is_locked() then.


--
Milan Mimica
http://sparklet.sf.net