[SDL] CVS Update (March 5, 2002 - please test!)

[Sam Lantinga]

> > Here's the entry from the WhatsNew file:
> >     Added SDL_LockRect() and SDL_UnlockRect() to lock a portion of a
> >     surface.  This may be more efficient than a full lock if you are
> >     using a hardware surface and plan to make a few changes to small
> >     areas in the surface.
> > I have mixed feelings about introducing this API, so feedback is
> > welcome!

> Well, I think your version might be more explicit about the "special 
> case" nature than required...

I'm not sure what you mean by this.
The implementation looks for a hardware accelerated call, and if there
is none, then locks the entire surface and returns the appropriate section
of the pixel data.  Therefore, it isn't efficient on most targets.

Maybe the call should just fail if it's not hardware accelerated?

> The corresponding extension in glSDL doesn't need anything but an extra 
> rect, and apart from that call (it's actually a separate "invalidate" 
> call, as I didn't consider the screen issue from the start), there are 
> no API differences.

> What I'm suggesting is adding only an SDL_LockRect() call 
> (SDL_UnlockSurface() is still used for unlocking) that takes an SDL_Rect. 
> 'pixels' and 'pitch' would be set up so that the application thinks it's 
> looking at the fullsized image. (That is, pixel address calculations are 
> still based on (0, 0) being in the top left corner.)

I felt it was wrong to overwrite the members of the surface structure,
which would require saving the original values somewhere, and then restoring
them on the unlock.

> In the case of the current glSDL implementation, there is always a full 
> size software representation of the surface, so my version of 
> SDL_LockRect() would be identical to SDL_LockSurface() in all respects 
> expect that only the arean inside the rect will be sent to the video card 
> upon calling SDL_UnlockRect.


> Would that work for the other situations you have in mind (maybe targets 
> that actually won't have pixel data outside the locked area), or am I 
> missing something?

DirectX doesn't have pixel data outside the locked area.

See ya,
	-Sam Lantinga, Software Engineer, Blizzard Entertainment