bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display

[Ken Raeburn <raeburn@permabit.com>]

> On Oct 6, 2015, at 10:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Tue, 6 Oct 2015 05:30:42 -0400
>> Cc: 21473@debbugs.gnu.org
>> 
>> It looks like I was mistaken. It appears that it was using the arrow only because that’s the default pointer shape for the X root window. According to some of the X docs I was reading, if the “cursor” (pointer shape) is never defined for a window, then the window uses the value from the parent window.
>> 
>> If I change the root window’s default pointer shape, then when the mouse is in the tooltip window it also uses that shape. I doubt that’s what we want; one of the shapes used by Emacs would be better, even if we only allow one to be used for that frame. Then again, if the window is supposed to go away quickly, maybe we don’t care at all? On a slow, remote link, there can be enough lag for the pointer to be visible in the tooltip window for a good half second at least.
>> 
>> The odd part: It appears that it’s already broken, even with the call to x_set_mouse_color being applied to the tooltip frame. I’m still getting whatever odd cursor shape I installed for the root window. This is with the Xquartz server on OS X; I’ll try later with the X.org server.

It behaves the same on the x.org server.  The default root-window mouse cursor is a big “X”, and the same is true for the tooltip window.

> 
> I suggest to make that call conditional on a user variable, by
> default off.  Most users, certainly on fast networks, will never see
> that pointer anyway.
> 
> WDYT?

They can see it if any CPU-intensive work keeps Emacs busy right after the tooltip is displayed — garbage collection, auto-revert of large files, processing of data received from the net, etc.  Then Emacs may not be able to make the X window disappear right away when the user moves the mouse.

I wonder if it might be better to change x_set_mouse_color to check some new field “f->tooltip_p” that makes it define just one cursor.  (The arrow we use for non-text areas, or the vertical-bar xterm cursor we use for text?)

For users on fast networks, the extra traffic I’m worrying over — which I think would then be reduced to three XSync exchanges, if we also do color-name caching and TrueColor optimizations — wouldn’t be a big deal.  A tiny price for getting the display right in a minor case, if we can, and I think I can reduce that count.

I think that’s probably better than a new Lisp variable to control low-level protocol details that should usually be invisible, to deal with a problem that we could fix reasonably well in the C code.

Of course, there’s also the little matter of making the cursor-setting actually work.  Until (unless?) that happens, we might as well disable it for everyone.  I can check that in if you'd like.

Ken