GNU bug report logs - #21473
24.5; very slow tooltip display to sort-of-slow remote display

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 21473 <at> debbugs.gnu.org
Subject: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
Date: Tue, 15 Sep 2015 17:32:07 +0300

> From: Ken Raeburn <raeburn <at> permabit.com>
> Date: Mon, 14 Sep 2015 04:13:41 -0400
> 
> I’ve noticed that when I’m using a “slow” network link — high bandwidth but a round-trip time of 30-40 milliseconds (remember when that was fast?) — the tooltip window that pops up when I move the mouse, say, over the buffer name in the mode line, takes much longer to come up than when I’m running Emacs on a local display. And if I keep moving the mouse around, I’m likely to get the tooltip for the buffer-name part of the mode line, but displayed somewhere else entirely, depending where the mouse has moved to.
> 
> Based on some earlier investigations, I used gdb to look at calls to _XReply in the Xlib library; this is the routine that flushes the outgoing buffer to the X server and then waits for a response, which contains color info or font info or whatever else is wanted by the caller. It’s of interest because each such call is going to require a round trip to the X server, and on a connection like mine, will add 30ms of delay that cannot be removed without eliminating some of the synchronous Xlib calls — e.g., fewer font queries or whatever. Of course they can’t all be removed, but if some are pointless or redundant we may be able to reduce the time spent waiting.

Is there something new in what you discovered, given the fact that a
tooltip is just a special kind of frame, and so everything that you
reported which causes slow creation of a new frame pertains also to
tooltips?

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.