Re: [AD] Locking Behaviour

[Paul Suntsov <siegelords_abode@xxxxxxxxxx>]

> 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.

First of all, yes, I forgot that bit. I no longer suggest having the routines receive an unlocked bitmap, lock it, and leave it that way. That, as you said, breaks the 'hinting' mechanism already in place. My bad.

> 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"?

As for that, what I mean by those routines are the render-to-texture routines when such an extension is not available, and rendering to memory bitmaps (they have to be locked too, I'd imagine, as a formality). These two types have to go via the software rendering method, and thus have to have the bitmaps they are operating on to be locked. Likewise, there are routines that necessarily have to operate on unlocked bitmaps, such as flipping the display. I'm just saying that just in case a certain lock state is required by a routine, then it will apply that required state itself without the user explicitly applying it for it. If the routine does not require any particular state, it will branch out and use the software/hardware method as appropriate. Right now, I believe the first kind simply fails.

This does have the issue that Trentg mentioned, that the state of the user's lock won't be preserved after any drawing routine, if that routine somehow needs to modify it.

For consistency's sake, however, if these functions start modifying the locked region, thus becoming virtual fail-proof, so should become the rest of the drawing routines, which would require the flexible lock region function below.

> 
> > 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.
> 

Yes, that's what I had in mind. Again, we have the Trentg's issue here, that user's lock might be modified by any internal routine that calls al_lock_bitmap_region. Another problem is when the user herself calls the routine. She might end up with a larger locked region than expected if we have the overlap test. Now, this isn't necessarily bad, but the direct memory access, like the one in ex_threads2, will have to be done with greater care.

Another ambiguity that arises from this is what to do if a routine needs a lock on a bitmap, but finds the region already locked too small. Does it resize the region using the flexible lock_region function? Or, perhaps this lock was accidental, and instead it be better to unlock the bitmap completely and use the hardware accelerated routine?

So, I don't know. Naturally, the modification of making the blitting routines use the same lock-preservation techniques as al_put/get_pixel makes sense and we can all agree to that. Making the routines auto-lock/unlock if needed and have the flexible lock_region function sounds requires making a decision of how much do we want to hold the user's hand in this. We either force the user to match all locks with unlocks as per the current API, or we don't, instead matching them via implementation of al_lock_region. The first is simpler to code and document, but harder to use by the user, while the latter is harder to code and document, but potentially easier to use (given the above gotcha's).

Just to be clear about the dichotomy involved, here's the two ways of how this could work:

Current A5 way (with the bug fix):
-If we want unlocked but it isn't, we fail
-If we want locked, but region locked is too small/wrong, we fail
-If we want locked, received unlocked, we lock, do stuff, and unlock
-Overall, functions fail if conditions are not just right

Hand-holding way
-If we want unlocked but it isn't, we unlock it
-If we want locked, but region locked is too small/wrong, we resize region
-If we want locked, received unlocked, we lock, do stuff, and unlock
-Overall, functions fail only if you simply can't do something (basically never)

SiegeLord

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