Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug, e.g. steps how to "animate Windows cursors theme" and on which WIndows version.

Created attachment 240927 [details]
test for animated cursor

In windows xp you can choose an animated mouse cursor theme in "control panel" -> "mouse"; in vista the default theme is animated.

If i set an animated mouse cursor theme if i set the GdkCursor to GDK_WATCH it isn't animated (the sand in the hourglass doesn't go down, and the hourglass doesn't turn).

You can try with the sample code that i attached before.

*** Bug 657884 has been marked as a duplicate of this bug. ***

Just to add a note, GIMP use GTK+, same as Dia, but does not exhibit such issues.

I can't reproduce make GIMP show animated cursors, so i can't confirm or deny that GIMP has no issues with animated cursors. Do note that GIMP mostly draws its own cursors too, at least over its canvas.

The bug with lack of animation is related to the fact that GDK calls sets cursor from a result of a CopyCursor() API call (the comments mention that up the stack GdkCursor can be destroyed while in use by other windows, copying protects from that; ironically, it refers to gimp_change_win_cursor(), which doesn't exist anymore).

I've made a small Hello World W32 windowed application that did only one thing - loaded an animated cursor (i've tried various functions - LoadCursor, LoadCursorFromFile, LoadImage; various ways - from an .ani file, from a resource within the executable that was created from the same .ani file) and sets it in response to WM_SETCURSOR after copying it (tried CopyCursor and CopyImage with various arguments). No animation (except when CopyImage is called with LR_COPYDELETEORG, but that just means that no copying takes place).

At this point i can only conclude that animated cursors cannot ever be copied using Copy{Image,Cursor}.

I see two ways of fixing this:
1) Don't copy cursors, use them as they come. This may require introducing some kind of reference counting to GdkWin32Cursor (related to the HCURSOR it holds, not to the object itself; i'm assuming that GdkWin32Cursor can change HCURSOR value without being destroyed and created anew).

2) Don't copy cursors, load them on the spot. GdkWin32Cursor will be modified to hold all the information necessary for loading a cursor, and will do so when needed. This might come with a performance penalty, and removing that penalty will probably bring the code closer to (1) (load once, keep around with some kind of refcount?).

Unrelated: MSDN tells us that DestroyCursor() should not be used on shared cursors. This is not related to the lack of animations (i've confirmed that much), but seems like a separate bug.

Thank for your interest in the issue.

I think I've found something relevant.

In recent GIMP versions, it seems they've gone away with custom cursors at the image canvas area even in places, where there's no image context present, which overshadow the change and can't be used as reference point any longer.

Over other areas (controls, menus and toolbox backgrounds) the animation is played normally, so does it in Dia, when you move cursor from diagram canvas area to the ruler, for example.

I see two possible solutions in this case:

1. Research deeper in the path you touched to get expected cursor behavior over all areas equal.

2. Introduce custom, mode-dependent cursor. This will supersede the issue, and may add overall better responsibility to the application.
Suggested modes(indications) are "Place object", "Select object", "Enter text". May be some other modes. I'm not familiar with Dia internals.

Created attachment 302823 [details] [review]
GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR

Note that this patch is against GTK+-3.x git master.

If it does work for GTK+-2.x - fine. If it doesn't - not my problem.
(Felt the need to clarify that, since this is a GTK+-2.x bug, technically,
although GDK didn't evolve much between 2 and 3).

Hi,

For records...

(In reply to LRN from comment #8)

> If it does work for GTK+-2.x - fine. If it doesn't - not my problem.

Another patch will be needed for GTK+-2.x, so I will try to look into that later.

Will try out this patch on GTK+-3.x myself in a bit.

With blessings.

You can make GTK show a busy cursor by opening up the filechooser dialog from the widget factory, changing into a directory with lots of subdirectories and files, then pressing alt+S to activate the search function and typing something in the search field. While searching, GTK will show the "busy" cursor (i will eventually file another, related, bug about the cursor being a full-blown busy watch, not a pointer-and-watch, despite the fact that the dialog remains 100% responsive during the search).

(In reply to LRN from comment #10)
> You can make GTK show a busy cursor by opening up the filechooser dialog
> from the widget factory, changing into a directory with lots of
> subdirectories and files, then pressing alt+S to activate the search
> function and typing something in the search field. While searching, GTK will
> show the "busy" cursor (i will eventually file another, related, bug about
> the cursor being a full-blown busy watch, not a pointer-and-watch, despite
> the fact that the dialog remains 100% responsive during the search).

No need for another bug. I've changed it to use a better cursor last week - it may need some adjustment to actually get you a better cursor on windows.

Created attachment 303289 [details] [review]
GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR

v2:
* Fixed casting in one of the corner-cases

Review of attachment 303289 [details] [review]:

Hi LRN,

I am sorry, as things popped up and got in the way of getting back to you to this bug earlier.  I think your patch looks good to me, and should be ready to go, for gtk+ master, given that this is ok for Matthias (and perhaps Nacho).  Tested it by a quick forward port of the reporter's test program to be 3.x-compatible.

p.s. Let's keep this bug open, as the reporter was talking about GTK+-2.x, although clearly this hits 3.x as well.

With blessings, thank you!

Comment on attachment 303289 [details] [review]
GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR

Attachment 303289 [details] pushed as 641fbd8 - GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR

Seems unlikely that we would add a new feature like this in gtk2 at this point

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new