GNU bug report logs - #21473
24.5; very slow tooltip display to sort-of-slow remote display

Previous Next

Full log

View this message in rfc822 format

From: Ken Raeburn <raeburn <at> permabit.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21473 <at> debbugs.gnu.org
Subject: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
Date: Mon, 5 Oct 2015 01:38:26 -0400

> On Oct 4, 2015, at 15:40, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn <at> permabit.com>
>> Date: Sun, 4 Oct 2015 14:02:18 -0400
>> Cc: 21473 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.