bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
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@permabit.com>
> Date: Sun, 27 Sep 2015 09:29:11 -0400
> Cc: 21473@debbugs.gnu.org
> 
> 
> > On Sep 27, 2015, at 06:38, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Ken Raeburn <raeburn@permabit.com>
> >> Date: Sun, 27 Sep 2015 06:35:30 -0400
> >> Cc: 21473@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]