Re: make-pointer-invisible on Windows

[Eli Zaretskii]

> Date: Wed, 24 Jun 2015 19:40:29 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  >> +static void
>  >> +w32_toggle_invisible_pointer (struct frame *f, bool invisible)
>  >> +{
>  >> +  block_input ();
>  >> +
>  >> +  if (f->pointer_invisible != invisible)
>  >> +    {
>  >> +      f->pointer_invisible = invisible;
>  >> +      SET_FRAME_GARBAGED (f); <<<<<<<<<<<<<<<<<<<<<<<
>  >> +    }
>  >
>  > That sounds excessive: I think it means that every self-inserting
>  > character will trigger thorough redisplay of the frame.
> 
> Hopefully only for the first self-inserting character typed.  After that
> the f->pointer_invisible != invisible fails until the mouse is moved.

In theory, yes.  But doing this makes me nervous, since inserting a
single character is something the display engine knows how to optimize
very well.  This disables all those optimizations.

>  > Why do you
>  > need this?  Is there any problem without marking the frame garbaged?
> 
> Yes, unfortunately (this was the only time-consuming part of the patch).
> If I don't mark the frame garbaged, the cursor sometimes disappears only
> after typing at least two or maybe a couple of characters which is quite
> distracting.  There must be some redisplay optimization which gets into
> the way.

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.

>  > 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.