[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?
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display,
Eli Zaretskii <=
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08