From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 04 Oct 2015 12:45:42 +0300 Message-ID: <83oagf0xx5.fsf@gnu.org> References: <9F31D581-6B5A-42B7-8031-6920089AFFF4@permabit.com> <83pp15hdbg.fsf@gnu.org> <59C0A752-87BB-4467-9A3F-DC1E5A278842@permabit.com> <83612wf8pr.fsf@gnu.org> <83si5wbcap.fsf@gnu.org> <6ebnci3o1s.fsf@just-testing.permabit.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1443951981 5616 80.91.229.3 (4 Oct 2015 09:46:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 09:46:21 +0000 (UTC) Cc: 21473@debbugs.gnu.org To: Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 04 11:46:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zifru-0005F8-G2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Oct 2015 11:46:10 +0200 Original-Received: from localhost ([::1]:41810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zifrt-0007LL-NZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Oct 2015 05:46:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zifrp-0007LE-Ht for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 05:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zifrm-0001WH-9d for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 05:46:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zifrm-0001WC-5L for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 05:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zifrl-0006gO-Vs for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 05:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Oct 2015 09:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21473 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21473-submit@debbugs.gnu.org id=B21473.144395195125670 (code B ref 21473); Sun, 04 Oct 2015 09:46:01 +0000 Original-Received: (at 21473) by debbugs.gnu.org; 4 Oct 2015 09:45:51 +0000 Original-Received: from localhost ([127.0.0.1]:54213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zifra-0006fx-R4 for submit@debbugs.gnu.org; Sun, 04 Oct 2015 05:45:51 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:49366) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZifrX-0006fn-Jt for 21473@debbugs.gnu.org; Sun, 04 Oct 2015 05:45:49 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NVO00G00VYASM00@a-mtaout21.012.net.il> for 21473@debbugs.gnu.org; Sun, 04 Oct 2015 12:45:46 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVO00G27WG9QE70@a-mtaout21.012.net.il>; Sun, 04 Oct 2015 12:45:46 +0300 (IDT) In-reply-to: <6ebnci3o1s.fsf@just-testing.permabit.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107285 Archived-At: > From: Ken Raeburn > Cc: 21473@debbugs.gnu.org > Date: Thu, 01 Oct 2015 06:01:35 -0400 > > We do all of this in "x_set_mouse_color" because the cursor color is a > property of the cursor object, so we create new cursors, set their > colors, and then start using them in place of the old ones. Sorry, I don't understand: by "cursor" here do you mean the mouse pointer? If not, i.e. if this is the text cursor, then how is it related to x_set_mouse_color? > Below are the _XReply call stacks (with counts) I found once I worked up > my color handling changes. There were 61 XSync calls in all, this time. > This was for moving the mouse into the frame to the mode line (with > focus elsewhere), and waiting for the tooltip to pop up. > > 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. > 4 _XReply « XSync « x_had_errors_p « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main > 2 _XReply « XTranslateCoordinates « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main > 2 _XReply « XSync « x_uncatch_errors « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main These are X events that come through the socket, so I don't see how we can avoid them. I don't know enough about X to answer your questions about the possible way of avoiding these XSync calls. > 2 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « font_open_by_spec « font_open_by_name « x_default_font_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 This loads fonts for the tip frame, so I don't think we can avoid them. The font parameter in the tip-frame parameter alist can be changed by the caller. > 2 _XReply « XSync « x_uncatch_errors « get_current_wm_state « x_net_wm_state « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main AFAIU, this is where we query the X server about fullscreen, whose response in case of tip frames is probably known in advance, right? Perhaps we could handle tip frames specially here, and avoid querying the server? > 1 _XReply « XQueryPointer « compute_tip_xy « 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 « detect_input_pending_run_timers « wait_reading_process_output « sit_for « read_char Here we query the server about the mouse pointer position, so we could position the tip frame. I don't think we can avoid this one. > 1 _XReply « XParseColor « x_parse_color « x_defined_color « x_decode_color « x_set_background_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 Colors for the tip frame; looks unavoidable (modulo some color caching). > 1 _XReply « XGetSelectionOwner « Fx_selection_exists_p « Ffuncall « exec_byte_code « Ffuncall « Fapply « Ffuncall « exec_byte_code « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « eval_sub « Feval « internal_condition_case_1 « menu_item_eval_property « parse_tool_bar_item « process_tool_bar_item « map_keymap_item « map_keymap_internal « map_keymap « tool_bar_items « update_tool_bar « prepare_menu_bars « redisplay_internal « redisplay_preserve_echo_area « read_char « read_key_sequence « command_loop_1 That's unrelated to popping up a tooltip.