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?
No, that’s not what I meant - the implementation does just what I’d like
that far.
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.
…but targets that actually use ‘pixels’ and ‘pitch’ to keep track of
the real surface data all the time (like software surfaces w/o RLE, I
believe) wouldn’t require any changes at all! 
Using SDL_LockRect() instead of SDL_LockSurface() should only require
that you know where you’ll be drawing - not that you change your
rendering code to account for a “window” rectangle. Actually getting a
’pixels’ pointer that corresponds to the locked rectangle, rather than
the whole surface would be illogical IMHO, and would probably also cause
extra coordinate translation overhead in the rendering code. The
SDL_Surface struct still represents the surface, right?
As to targets that will actually have to go and get the pixel data for
you, SDL_LockRect() would have to adjust ‘pixels’ like this, before
returning:
pixels -= rect.x * BytesPerPixel + rect.y * pitch;
This is to “hide” the fact that only part of the surface is locked, from
the rendering code, so that only the code that calculates the lock rect
will have to be aware of the “performance hack” that this actually is.
If ‘pixel’ is used by SDL_UnlockRect(), this will have to be undone. If
it isn’t used, ‘pixel’ can just be ignored, as I would assume is already
the case.
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.
Yeah, I know - but I don’t really see why you cannot just set the pitch
to reflect the actual pitch, and then offset ‘pixels’ to compensate (as
described above), if the top-left corners of the rect isn’t at (0,0) on
the surface…
Indeed, you’d get a segfault if you access pixels outside the locked
rectangle, but IMHO, that’s not all that different from trying to access
a surface that isn’t locked at all. Telling SDL one thing and then doing
another is Bad, and it’s only fair if you’re punished for it! 
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 March 2002 00:16, Sam Lantinga wrote: