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

The latest CVS snapshot is available:
http://www.libsdl.org/cvs.html

Please test this CVS release!
In particular, I’m hoping that the inclusion of the XFree86 extension
libraries will fix the problems with Debian on non-x86 architectures,
as well as fix the remote X11 video hang. An added benefit of this is
binaries built on systems that do not use XFree86 can use the extensions
anyway. :slight_smile:

I also added SDL_LockRect() and SDL_UnlockRect().
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!

Here are the details of what’s new since the last update:

  • Added SDL_LockRect() and SDL_UnlockRect()
  • Incorporated XFree86 extension libraries into the source
  • More QNX cleanups (including OpenGL support) from Mike Gorchak
  • Fixed “short jump out of range” error in MMX code (thanks Steven)
  • Updated for Watcom C++ and LCC compilers (thanks Jean-Pierre)
  • Updated DirectFB video driver for DirectFB 0.9.9
  • More QNX photon/nto-audio improvements by Julian Kinraid
  • Fixed SDL_OPENGLBLIT with OpenGL API newer than 1.2
  • Added initial support for Atari (thanks Patrice!)
  • Updated the Project Builder archives (thanks Darrell)

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

[…]

I also added SDL_LockRect() and SDL_UnlockRect().
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…

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

Of course, if the application does SDL_LockRect() and then “forgets” the
rect and touches pixels outside of it, those changes will be ignored, and
segfaults or other Bad Things may occur.

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?

//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 Tuesday 05 March 2002 21:10, Sam Lantinga wrote:

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

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! :slight_smile:

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! :wink:

//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: