Dealing with color cursors in a thread-safe way is really tricky.
Effectively, you have to obtain a lock on every refresh, to prevent
the mouse from moving while you’re updating the screen.
I don’t think it’s worth it to put that kind of overhead into the SDL
code. While cool, it’s alot easier for the application to keep track
of that kind of thing than add strict locking into every SDL mouse and
refresh call.
I’m thinking seriously about removing color cursor support.
Opinions?
[problems with cursors]
I’m thinking seriously about removing color cursor support.
Opinions?
I’d say “kill it”. I always had a problem fitting automatic handling
of color mouse cursors into “simple direct media”. 
For the
category of applications that rebuild their display from sratch every
frame (like mine:), SDL can’t possibly manage the cursor more
efficiently than the application programmer. Basically, the cursor is
just another blit, then.
Then again, I’m sure there are other applications where having the
library handle the cursor for you saves some (complex, boring?) work.
/EmilOn Thu, 23 Apr 1998, Sam Lantinga wrote:
I’d say “kill it”. I always had a problem fitting automatic handling
of color mouse cursors into “simple direct media”.
I would agree, unfortunately X11 DGA and SVGAlib support both require
the application to draw the mouse. (I forgot about that)
So, color cursors are here to stay.
The good news! I cleaned up the blitting and color cursor code so it’s
relatively simple and now completely thread-safe. You can bypass multiple
levels of the blit code if you know what you’re doing, or you can let SDL
do all the work of keeping track of clipping and so on.
The only time you’ll run into problems is when you set a color cursor,
and you write directly to the framebuffer, and you don’t call SDL_UpdateRects()
All other times, the cursor is flawlessly updated.
A very nice side effect of the new cursor code is you can now have cursors
with special effects… like alpha blending grin
For the category of applications that rebuild their display from sratch
every frame (like mine:), SDL can’t possibly manage the cursor more
efficiently than the application programmer. Basically, the cursor is
just another blit, then.
True. And if you call SDL_UpdateRect(0,0,0,0) once per frame, then the
cursor will be blitted at the end of the update. How more efficient can
you get? The blit also takes advantage of any hardware acceleration
available. … this isn’t tested yet as the DirectX layer still has to
be brought up to speed.
Then again, if you want to handle the cursor yourself, go for it!
Don’t forget that if you set a mouse motion callback for smooth cursor
position updates that it will run in a separate thread, and you’ll have
to deal with the gnarly locking and coordination that SDL takes care of.
Then again, I’m sure there are other applications where having the
library handle the cursor for you saves some (complex, boring?) work.
Yep.
For the category of applications that rebuild their display from sratch
every frame (like mine:), SDL can’t possibly manage the cursor more
efficiently than the application programmer. Basically, the cursor is
just another blit, then.True. And if you call SDL_UpdateRect(0,0,0,0) once per frame, then the
cursor will be blitted at the end of the update. How more efficient can
you get?
available. … this isn’t tested yet as the DirectX layer still has to
be brought up to speed.
Seems like DirectX is causing you a great deal of trouble. Is it just
bad luck, or was there more evil in there than you’d expected?
Then again, if you want to handle the cursor yourself, go for it!
Don’t forget that if you set a mouse motion callback for smooth cursor
position updates that it will run in a separate thread, and you’ll have
to deal with the gnarly locking and coordination that SDL takes care of.
Hm… That’s a good reason to think twice about handling the mouse
myself. I still haven’t gotten around to thinking that dealing
with the down side of concurrency is much fun… 
But, hey, I could
just poll the mouse position every frame, right? Perhaps not so
smooth, but simpler.
/EmilOn Fri, 24 Apr 1998, Sam Lantinga wrote:
I’m thinking seriously about removing color cursor support.
Opinions?
I’d say “kill it”. I always had a problem fitting automatic handling
of color mouse cursors into “simple direct media”.
category of applications that rebuild their display from sratch every
frame (like mine:), SDL can’t possibly manage the cursor more
efficiently than the application programmer. Basically, the cursor is
just another blit, then.Then again, I’m sure there are other applications where having the
library handle the cursor for you saves some (complex, boring?) work.
Yeah perhaps what we need is a (boring old) sprite engine for people to
overlay sprites (and cursors) if they can’t handle it themselves?
Although it’d be nice to support hardware sprites/cursors if they are
available…
njhOn Fri, 24 Apr 1998, Emil Brink wrote:
Seems like DirectX is causing you a great deal of trouble. Is it just
bad luck, or was there more evil in there than you’d expected?
My debugger works under X11.
I prefer to get as much of the code working using X11 and gdb as possible,
until I start having to do fprintf under DirectX.
It trains you to look long and carefully at your code, most of the time.
Hm… That’s a good reason to think twice about handling the mouse
myself.
with the down side of concurrency is much fun…
just poll the mouse position every frame, right? Perhaps not so
smooth, but simpler.
Great idea.
What you would end up doing is:
if ( SDL_MUSTLOCK(screen) ) {
if ( SDL_LockSurface(screen) < 0 )
return;
}
write write write a frame
if ( SDL_MUSTLOCK(screen) ) {
SDL_UnlockSurface(screen);
}
SDL_GetMouseState(&x, &y);
blit mouse sprite
SDL_UpdateRect(0, 0, 0, 0);
Actually, it would be faster just to let SDL handle it.
You either have to clip the cursor yourself or let SDL clip it in which
case it’s just as easy to let SDL do the work. I dunno. The gains don’t
seem very high, especially when SDL can do it for you, and the codepaths
are designed to do so.
If you have a black and white cursor, the window manager cursor is used
whenever possible, though in constant-refresh conditions there’s usually
a lot of flicker.
[doing my own mouse cursor]
What you would end up doing is:
if ( SDL_MUSTLOCK(screen) ) {
if ( SDL_LockSurface(screen) < 0 )
return;
}
write write write a frame
if ( SDL_MUSTLOCK(screen) ) {
SDL_UnlockSurface(screen);
}
SDL_GetMouseState(&x, &y);
blit mouse sprite
SDL_UpdateRect(0, 0, 0, 0);Actually, it would be faster just to let SDL handle it.
You either have to clip the cursor yourself or let SDL clip it in which
case it’s just as easy to let SDL do the work. I dunno. The gains don’t
seem very high, especially when SDL can do it for you, and the codepaths
are designed to do so.
OK, OK, OK! I give up! I will never, ever again contemplate doing the
mouse cursor myself! Happy? :^) Umm… This SDL_MUSTLOCK()-talk, does
it mean that I must lock a surface even if I’m only going to do
SDL_BlitSurface() on it when I write my frame?
If you have a black and white cursor, the window manager cursor is used
whenever possible, though in constant-refresh conditions there’s usually
a lot of flicker.
Seen that. Didn’t like it much. Turned the cursor off.
/EmilOn Fri, 24 Apr 1998, Sam Lantinga wrote:
OK, OK, OK! I give up! I will never, ever again contemplate doing the
mouse cursor myself! Happy? :^) Umm… This SDL_MUSTLOCK()-talk, does
it mean that I must lock a surface even if I’m only going to do
SDL_BlitSurface() on it when I write my frame?
Nope. You only need to lock the surface if you’re writing directly to it,
and then only if the surface resides in hardware (or other odd conditions
checked by the SDL_MUSTLOCK macro.)
If you lock the surface and don’t unlock it before you blit, you can deadlock
your application. (Notably on thread-safe surfaces or DirectX surfaces)
Seen that. Didn’t like it much. Turned the cursor off.
Yep.
OK, OK, OK! I give up! I will never, ever again contemplate doing the
mouse cursor myself! Happy? :^) Umm… This SDL_MUSTLOCK()-talk, does
it mean that I must lock a surface even if I’m only going to do
SDL_BlitSurface() on it when I write my frame?Nope. You only need to lock the surface if you’re writing directly to it,
and then only if the surface resides in hardware (or other odd conditions
checked by the SDL_MUSTLOCK macro.)
Aha. I always did that. Coming from a DirectX world, locking a
surface before banging on its bits with the CPU seemed a natural
thing to do (it’s required in DX, you know).
/EmilOn Fri, 24 Apr 1998, Sam Lantinga wrote: