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

[Ken Raeburn <raeburn@permabit.com>]

> On Oct 5, 2015, at 22:44, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Mon, 5 Oct 2015 22:15:44 -0400
>> Cc: 21473@debbugs.gnu.org
>> 
>>>> Ah, sorry.  Yes, it seems to work okay, as far as I can tell, and cuts out 11 round trips.  With a remote display I’m able to move the mouse into the tooltip window for a few seconds before it goes away, and (at least on my display) it’s showing a basic black arrow pointer.
>>> 
>>> Is that black arrow mouse pointer different from what you see if the
>>> call to x_set_mouse_color is retained?
>> 
>> No, it appears to be the same.
> 
> So I suggest to install such a change.  Do you have a patch that can
> be used?

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.

Ken