Surface locks (was Re: Re: When will there be blitting support when using OpenGL)

vining at pacificcoast.net wrote:

… not a bad idea (a pain in the ass for users, but not a bad idea…) however
I doubt you could do this without breaking applications which used an older
SDL. Sam?

Nicholas

thatswhy i believe in a design philosophy of that a 2.0 version will not
necesarily be backwards compatile with 1.0. make it known that that is your policy
and then you can redisgn whatever you want inbetween major version numbers and
keep the lib the best it can be. only my opinion though

vining at pacificcoast.net wrote:

Actually, I already suggested to Sam that forcing people to use a
Lock/Unlock kind of operation would be a nice idea and would enable some
drivers to accelerate cases like these (for exemple, in raw Xlib,
Pixmaps can be faster than shared memory with XF86 4.0, and just as fast
with pre-4.0).

… not a bad idea (a pain in the ass for users, but not a bad idea…)
however I doubt you could do this without breaking applications which
used an older SDL. Sam?

Yes, this would break older apps. The porting would be quite simple,
though, just wrapping surface buffer read/writes with Lock/Unlock… To
do it in the most efficient manner is another thing, but as things
stands now, it would still improve things.

By the way, I heard some awful things about using DirectDraw Lock/Unlock
on video memory surfaces with nVidia TNT/TNT2 cards (maybe it also
applies to GeForce, no confirmation)… Apparently, DDraw stores
surfaces in a special “compressed” format (along the lines of RLE I
think) which is better for the accelerator. Doing a Lock supposedly has
to copy everything in system memory, then the Unlock copies everything
back to the video memory (in the special format)!

That should give AWFUL Lock/Unlock performance, even if you don’t touch
the surface memory!–
Pierre Phaneuf
Systems Exorcist