We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

while it's true that you can directly overwrite the pointer on the display buffer, it's also true that you can draw your own cursor...better than SDL can.  Also SDL has no way of being told to update the pointer on the screen after you use direct single buffered pixel pushing, except telling it to update the whole screen, whic may redraw the cursor.  In the end it flashes and looks ugly anyway.

I propose a WONTFIX status.
The workarounds are better than bothering to fix this basically "beginner friendly" function.

The second point is probably a WONTFIX, but the first might be a legitimate bug. I'm still considering it.

--ryan.

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

The right way to handle this is to create the software cursor as three surfaces in the format of the video mode, in video memory and accelerated if possible:
1. The cursor surface itself, colorkeyed
2. The saved surface, used to erase the cursor
3. The mixing surface, used to handle blended blits

Then we no longer blit to the shadow surface, we instead use this algorithm for all blits to the video surface:
1. See if the blit intersects the cursor, if not just do it.
2. Create an intersection of the blit and the cursor, and generate up to 4 subrects:  top, left, right, bottom around the cursor
3. Blit the subrects around the cursor area
4. Blit the saved surface to the mixing surface.
5. Blit the original blit cursor intersection to the mixing surface
6. Blit the mixing surface back to the saved surface
7. Blit the cursor to the mixing surface
8. Blit the mixing surface to the video surface.
This results in flicker-free blits to the video surface in all cases, and properly handles colorkey and alpha blits.

Moving the cursor uses this algorithm:
1. Blit the saved surface to the video surface at the old location.
2. Blit the video surface to the saved surface at the new location.
3. Blit the cursor to the video surface at the new location.
This will result in slight flicker while moving the cursor.

An alternate algorithm, using a fourth surface twice as big as the cursor follows.
If the old and new areas overlap:
1. Blit the union of the old and new areas from the video surface to the large surface.
2. Blit the saved surface to the large surface at the old location.
3. Blit the large surface to the saved surface at the new location.
3. Blit the cursor to the large surface at the new location.
4. Blit the union of the old and new areas from the large surface to the video surface.
If the areas don't overlap:
1. Blit the video surface from the new location to the mixing surface.
2. Blit the cursor to the video surface in the new location.
3. Blit the saved surface to the video surface in the old location.
4. Blit the mixing surface to the saved surface.
This will result in flicker-free cursor motion in all cases.

If the application needs to do non-blit drawing on the video surface, it will have to hide and show the cursor manually if the drawing intersects the cursor.

This change would require significantly changing the cursor data structure, which is public for some reason, so this change would probably have to go into 1.3, if implemented.

Note that the algorithm for flicker-free cursor blitting is only relevant for cases where the application is drawing directly to visible video memory.  In the shadow buffer case, SDL currently handles the software cursor behind the scenes, and in the page flipped case, the cursor is drawn onto the ... wait, it's not.

In the page flipped case, ideally the cursor should be drawn onto the video surface immediately before the flip, and then erased after the flip.  This is probably better done in the video drivers, as they control access to the video memory before and after the flip.

(In reply to comment #5)

At this point probably the best thing to do is identify cases where this needs to be fixed, and implement hardware cursors in the video drivers that need them.

The cursor subsystem is going to be completely re-implemented in SDL 1.3.