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

[Ken Raeburn]

> 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