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

[Ken Raeburn <raeburn@permabit.com>]

> 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.

Ken