| Re: [AD] Locking Behaviour |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Paul Suntsov wrote:
As for that, what I mean by those routines are the render-to-texture routines when such an extension is not available,
User is not supposed to care if render-to-texture is available or not, so he
should not be bothered to lock the bitmap for this specific case. This is why we
have internal locking in OGL driver. I don't think we should spend too much
energy on optimizing this. Graphic cards without render-to-texture are almost
extinct.
and rendering to memory bitmaps (they have to be locked too, I'd imagine, as a formality).
Right, this also means that locking memory bitmap is non-expensive. Also nothing
to care to optimize.
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.
...
Right now, I believe the first kind simply fails.
Fails how? I can see it only fail to utilize the existing lock, which should be
fixed, yes.
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
I think it's OK to fail if the user dares to lock the bitmap himself.
--
Milan Mimica
http://sparklet.sf.net