From: Ken Raeburn <raeburn@permabit.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 21473@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 [thread overview]
Message-ID: <9CBD7FEC-C4BC-4FD8-8FE1-9760C2113DAC@permabit.com> (raw)
In-Reply-To: <83a8ry1kyt.fsf@gnu.org>
> 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
next prev parent reply other threads:[~2015-10-05 5:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 8:13 bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Ken Raeburn
2015-09-15 14:32 ` Eli Zaretskii
2015-09-15 22:03 ` Ken Raeburn
2015-09-26 7:03 ` Eli Zaretskii
2015-09-27 10:35 ` Ken Raeburn
2015-09-27 10:38 ` Eli Zaretskii
2015-09-27 13:29 ` Ken Raeburn
2015-09-29 20:15 ` Ken Raeburn
2015-09-30 7:23 ` Eli Zaretskii
2015-10-01 10:01 ` Ken Raeburn
2015-10-01 16:51 ` Ken Raeburn
2015-10-04 9:45 ` Eli Zaretskii
2015-10-04 18:02 ` Ken Raeburn
2015-10-04 19:40 ` Eli Zaretskii
2015-10-05 5:38 ` Ken Raeburn [this message]
2015-10-05 6:25 ` Eli Zaretskii
2015-10-06 2:15 ` Ken Raeburn
2015-10-06 2:44 ` Eli Zaretskii
2015-10-06 9:30 ` Ken Raeburn
2015-10-06 14:46 ` Eli Zaretskii
2015-10-07 6:09 ` Ken Raeburn
2015-10-07 15:31 ` Eli Zaretskii
2015-10-08 6:04 ` Ken Raeburn
2015-10-08 8:12 ` Ken Raeburn
2021-09-19 22:29 ` Stefan Kangas
2022-04-24 13:19 ` Lars Ingebrigtsen
2022-04-25 2:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-23 8:02 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9CBD7FEC-C4BC-4FD8-8FE1-9760C2113DAC@permabit.com \
--to=raeburn@permabit.com \
--cc=21473@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.