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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Sun, 4 Oct 2015 14:02:18 -0400
> Cc: 21473@debbugs.gnu.org
> 
> >>      5 _XReply « XSync « x_check_errors « x_set_mouse_color « x_set_frame_parameters « x_default_parameter « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call1 « timer_check_2 « timer_check « readable_events « get_input_pending
> > 
> > Any idea why we need to call
> > 
> >  x_default_parameter (f, parms, Qmouse_color, build_string ("black"),
> > 		       "pointerColor", "Foreground", RES_TYPE_STRING);
> > 
> > when creating a tip frame?  Do we want the tip frames to be able to
> > support mouse highlight or something?  If so, we could make this
> > conditional on some option, because the absolute majority of tooltips
> > don't use that.
> [...]
>  - Make x_set_mouse_color record serial numbers and use a new error handling routine to check them, reducing the number of XSync calls but not getting rid of them entirely.

You didn't answer my question about the possibility to remove the call
to x_set_mouse_color (and anything mouse-related) altogether in a tip
frame.  Is that feasible?  Could you try that and see if it has any
adverse effects?

>  - Try to defer garbage collection while running commands like x-create-frame.

I'd recommend against that, or at most make it optional behavior.
IME, deferring GC is produces net loss in most situations.  Your
situation is clearly rare, so skewing the behavior for all the rest of
the users sounds unwise.