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: Wed, 30 Sep 2015 10:23:42 +0300

> From: Ken Raeburn <raeburn <at> permabit.com>
> Date: Sun, 27 Sep 2015 09:29:11 -0400
> Cc: 21473 <at> debbugs.gnu.org
> 
> 
> > On Sep 27, 2015, at 06:38, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> From: Ken Raeburn <raeburn <at> permabit.com>
> >> Date: Sun, 27 Sep 2015 06:35:30 -0400
> >> Cc: 21473 <at> debbugs.gnu.org
> >> 
> >> This one’s still basically unchanged. I just got 165 _XReply round-trip delays, with face realization color requests accounting for 60 of those, x_create_tip_frame initialization using “black” and “white” accounting for a dozen more, and other XParseColor or XAllocColor calls bringing it up to around 100 (maybe fewer than last time, by just a few); 38 XSync calls, almost all for error catching. The other ~20% is XQueryColors, XListFonts, XGetWindowProperty, and a few other calls that need responses.
> > 
> > So you are saying that creating a tip frame is significantly different
> > in this regard from creating any "regular" frame?  If so, where are
> > the differences, wrt face realization and color allocation?
> 
> Some of the creation process is different, yes, though Fx_create_frame and x_create_tip_frame do a lot of the same work; both cause basic face realization on the new frame, but x_create_tip_frame doesn’t seem to have had the issue that triggered it on other frames. (For example, it doesn’t set a default gamma value, while Fx_create_frame does.) The face realization happening here is all about the new frame.
> 
> This traffic was also present when I was looking into #11822, but as I was using a local display for the new frame, those round trips were fast and thus weren’t a problem. In this case, though, my one and only normal frame is displayed remotely, as is the tip frame, so now the excessive round trips slow it down a lot. Some of it’s going to be necessary, of course, but we’re making repetitive queries for colors we’ve looked up before, probably more XSync calls than are really necessary, etc.

Let me be sure I understand: these XSync calls in the case of popping
up a tooltip, are mostly due to color allocation?  Or is there other
unnecessary face-related traffic that needs to be addressed?

Previous Next

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