[Bug 16281] Wine lacks support for fully animated cursors

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Nov 5 21:55:16 CST 2009


Andrew Riedi <andrewriedi at gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |andrewriedi at gmail.com

--- Comment #13 from Andrew Riedi <andrewriedi at gmail.com>  2009-11-05 21:55:15 ---
> At least when I was poking around a while back (and still true today) I didn't
> get anything when I tried to visit the link in your comment.  Was there any
> reasoning given on why the previous patches have not been accepted?

Just looked over your patch briefly.  The main difficulty is not to break any
16-bit applications, such as Paint, that like to modify the cursor data
directly.  A true CURSORICONINFO followed by the (single) frame *must* be
passed to at least the 16-bit cursor functions.  The 16-bit cursor(/icon)
handles *must* not have any change in the cursor struct, which obviously
complicates things.

So, maybe work should be focused on unwrapping the 16/32-bit mess we have now
with cursors.  Currently, cursor code uses the old 16-bit memory alloc
functions.  It would be better to use them only when needed, and have the main
32-bit version of the cursor be whatever struct we want.  We could make a table
to convert between 16<->32 bit cursors.  We would then convert 16->32 right
before a draw, just in case the 16-bit form had been altered, and 32->16
whenever we need to alter a cursor.  We would then be able to make Wine use a
struct like your WINECURSORICONINFO internally, since the 16-bit application
would have its own regular CURSORICONINFO to alter.  But that work must be done

I suppose that placing .ani info right after the first frame might also work,
but that is just hacky.  The only thing real fix I can think of is to make a
table to convert between 16<->32 bit cursors and have 2 versions for the 16-bit
case, and ignore 16-bit stuff in the 32-bit (and 64-bit) case.  What do you
guys think?

Note: Another potential issue is how Windows acts when one process decides to
use a cursor handle that another process made.  Since Wine isn't correct here
now (see user32 cursoricon tests), this shouldn't be of immediate concern.

Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the wine-bugs mailing list