[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
http://bugs.winehq.org/show_bug.cgi?id=16281
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
first.
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