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

[Ken Raeburn]

> On Oct 4, 2015, at 15:40, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> 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?

Ah, sorry.  Yes, it seems to work okay, as far as I can tell, and cuts out 11 
round trips.  With a remote display I’m able to move the mouse into the tooltip 
window for a few seconds before it goes away, and (at least on my display) it’s 
showing a basic black arrow pointer. I’m not sure how to get it to stick around 
past my moving the mouse into the window; the next thing Emacs does seems to be 
to delete the window.  The frame deletion code protects against calling 
XFreeCursor on a zero value, so I don’t expect any problems there.

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

I can imagine that.  Most commands aren’t likely to allocate nearly as much as 
I’m seeing during normal frame creation.  But that’s a separate issue….

Ken