Re: [AD] Locking Behaviour

[Paul Suntsov <siegelords_abode@xxxxxxxxxx>]

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

Sounds good to me. I'll submit the bug report for the memblit functions, and everything will be good. I was just trying to hone my vertex buffer locking API to be the same as the bitmap locking API, so I wanted to make sure everything was as it was meant to be. Thanks for the comments.

SiegeLord

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