Re: make-pointer-invisible on Windows

[Eli Zaretskii]

> Date: Thu, 25 Jun 2015 08:36:06 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > There are less radical ways of triggering more thorough redisplay,
>  > than redrawing the whole frame.  I will look into this when I have
>  > time, if no one beats me to it.
> 
> Please do that.

It turns out this has nothing to do with redisplay.  Inserting a
single character is enough to turn off the mouse pointer with your
original patch, after removing the call to SET_FRAME_GARBAGED.  The
problem is that sometimes the effect is far from immediate, you need
to wait for a second or so.

Looking into this, I concluded that calling SetCursor from the main
(a.k.a. "Lisp") thread has no effect whatsoever.  For some reason,
only the input thread can do that.  And it already does, whenever it
gets an appropriate message.  So all we have to do in the main thread
is send that message to the input thread.  This is what the first hunk
below, to be applied on top of your patch, does.

>  >>   > Also, what about the equivalent of the X code that makes the pointer
>  >>   > visible on focus-in events -- don't we need that on MS-Windows?
>  >>
>  >> I don't know.  It's certainly not necessary on XP here.  People would
>  >> have to try though.  In general, it seems that X and Windows differ
>  >> quite substantially in their respective behaviors.  For example, on X,
>  >> when a synchronous shell operation is active, the cursor becomes visible
>  >> as soon as the mouse is moved.  On Windows, the cursor remains invisible
>  >> until the shell operation terminates and the frame gets redrawn
>  >> (obviously, the frame doesn't look very decent in that period either, so
>  >> there are worse problems).
>  >
>  > I don't think this is related to the issue at hand.
> 
> I don't think so either.  My point was that X and Windows run into
> different problems when trying to make the pointer invisible.

Well, actually, it _is_ related, albeit to a different aspect of this.
The code that turns the mouse pointer back on when mouse moves also
runs in the main thread.  So whenever the main thread is busy with
some long calculation, or waits for some synchronous system call, we
cannot rely on this mechanism to timely turn the pointer back on.  But
the input thread can very well do that, so the second hunk of changes
below makes that happen.

So please install your changes, followed by mine (or tell me to do the
latter).  Thanks for working on this.

As for not redrawing the frame during these synchronous operations, I
will try to see why it happens (strangely, I only see it on XP, but
not on Windows 7).

--- src/w32term.c~0     2015-06-25 12:10:25 +0300
+++ src/w32term.c       2015-06-25 17:52:04 +0300
@@ -6613,14 +6613,10 @@ w32_toggle_invisible_pointer (struct fra
   if (f->pointer_invisible != invisible)
     {
       f->pointer_invisible = invisible;
-      SET_FRAME_GARBAGED (f);
+      w32_define_cursor (FRAME_W32_WINDOW (f),
+                        f->output_data.w32->current_cursor);
     }
 
-  if (invisible)
-    SetCursor (NULL);
-  else
-    SetCursor (f->output_data.w32->current_cursor);
-
   unblock_input ();
 }
 
--- src/w32fns.c~0      2015-06-25 12:29:41 +0300
+++ src/w32fns.c        2015-06-25 17:50:19 +0300
@@ -73,6 +73,7 @@ along with GNU Emacs.  If not, see <http
 
 #include <dlgs.h>
 #include <imm.h>
+#include <windowsx.h>
 
 #include "font.h"
 #include "w32font.h"
@@ -3492,13 +3493,31 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA
       return (msg == WM_XBUTTONDOWN || msg == WM_XBUTTONUP);
 
     case WM_MOUSEMOVE:
-      /* Ignore mouse movements as long as the menu is active.  These
-        movements are processed by the window manager anyway, and
-        it's wrong to handle them as if they happened on the
-        underlying frame.  */
       f = x_window_to_frame (dpyinfo, hwnd);
-      if (f && f->output_data.w32->menubar_active)
-       return 0;
+      if (f)
+       {
+         /* Ignore mouse movements as long as the menu is active.
+            These movements are processed by the window manager
+            anyway, and it's wrong to handle them as if they happened
+            on the underlying frame.  */
+         if (f->output_data.w32->menubar_active)
+           return 0;
+
+         /* If the mouse moved, and the mouse pointer is invisible,
+            make it visible again.  We do this here so as to be able
+            to show the mouse pointer even when the main
+            (a.k.a. "Lisp") thread is busy doing something.  */
+         static int last_x, last_y;
+         int x = GET_X_LPARAM (lParam);
+         int y = GET_Y_LPARAM (lParam);
+
+         if (f->pointer_invisible
+             && (x != last_x || y != last_y))
+           f->pointer_invisible = false;
+
+         last_x = x;
+         last_y = y;
+       }
 
       /* If the mouse has just moved into the frame, start tracking
         it, so we will be notified when it leaves the frame.  Mouse