Package: emacs;
Reported by: Ken Raeburn <raeburn <at> permabit.com>
Date: Mon, 14 Sep 2015 08:22:01 UTC
Severity: normal
Tags: moreinfo
Found in version 24.5
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21473 in the body.
You can then email your comments to 21473 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Mon, 14 Sep 2015 08:22:02 GMT) Full text and rfc822 format available.Ken Raeburn <raeburn <at> permabit.com>
:bug-gnu-emacs <at> gnu.org
.
(Mon, 14 Sep 2015 08:22:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org> Subject: 24.5; very slow tooltip display to sort-of-slow remote display Date: Mon, 14 Sep 2015 04:13:41 -0400
(“spun off” from discussion in bug #11822 that was wandering off topic) I’ve noticed that when I’m using a “slow” network link — high bandwidth but a round-trip time of 30-40 milliseconds (remember when that was fast?) — the tooltip window that pops up when I move the mouse, say, over the buffer name in the mode line, takes much longer to come up than when I’m running Emacs on a local display. And if I keep moving the mouse around, I’m likely to get the tooltip for the buffer-name part of the mode line, but displayed somewhere else entirely, depending where the mouse has moved to. Based on some earlier investigations, I used gdb to look at calls to _XReply in the Xlib library; this is the routine that flushes the outgoing buffer to the X server and then waits for a response, which contains color info or font info or whatever else is wanted by the caller. It’s of interest because each such call is going to require a round trip to the X server, and on a connection like mine, will add 30ms of delay that cannot be removed without eliminating some of the synchronous Xlib calls — e.g., fewer font queries or whatever. Of course they can’t all be removed, but if some are pointless or redundant we may be able to reduce the time spent waiting. I ran such a test (“emacs -Q”, moving mouse over the buffer name; emacs 24.5, X11, lucid toolkit) over a fast connection just to sort out what calls are being made and from where. I found 160 calls to _XReply. Whatever else Emacs is doing to display a tooltip window, on a connection with a 30ms RTT, that’ll account for almost 4.8 seconds of delay. (“Almost", because I think a few of those 160 calls are after the tooltip window was up, and I moved the mouse away.) And, indeed, when I do the test without gdb but over the slower connection, by eyeball I’d say it took about 5 seconds for the tooltip window to pop up (including the normal tooltip delay), and the text didn’t all fill in immediately. In all, there were about 50 calls to XParseColor, slightly more to XAllocColor, 31 to XSync (used in error handling), and a handful of assorted other synchronous calls. The first thing that should’ve occurred to me is that the tooltip window is treated like a frame; realize_basic_faces is called to realize 15 faces, the default plus 14 named ones, each with foreground and background colors, and each color needs XParseColor and XAllocColor both to make round trips to the X server. Emacs looks up the color “lightyellow” for the background of the default face, and for the background of the mode-line face, and for the background of the mode-line-inactive face, etc., and “black” for foreground as well. So there are 60 round trips (1.8s) right there. Some of the other synchronous calls can be attributed to these operations: 12 x_create_tip_frame calls x_decode_color("black") 6 times (XParseColor+XAllocColor) to initialize the foreground etc colors, just to keep ref count management simpler 11 via various paths from x_set_mouse_color 10 via various paths from realize_face from lookup_face from face_at_string_position from note_mode_line_or_margin_highlight from note_mouse_highlight from note_mouse_movement 8 via various paths from realize_face from lookup_face from face_at_buffer_position from handle_face_prop from handle_stop from start_display from try_window from Fx_show_tip 8 via various paths from Fdisplay_supports_face_attributes_p realizing a face 6 via x_set_{foreground,background,border}_color when x_create_tip_frame sets defaults 4 via x_set_cursor_color when x_create_tip_frame sets defaults 4 via x_set_cursor_color when face-set-after-frame-default updates parameters 16 via various paths from x_real_positions handling events during x_write_glyphs 12 via xfont_list_pattern called eventually from x_default_font_parameter twice and face_at_string_position once xfont_list_pattern, x_set_mouse_color, and x_real_position catch X errors using x_catch_errors and friends, which keep invoking XSync and then looking to see if any errors have been reported. In x_set_mouse_color, at least, we might be able to use smarter X error handling to match request serial numbers against errors and only sync once at the end, or something like that. But given that 2/3 of the round trips are for XParseColor and XAllocColor, I think they’re the place to start. I threw in a couple of simple caches (mapping name=>RGB and RGB=>pixel) and wrapped the XParseColor call in x_defined_color and the x_alloc_nearest_color_1 call in x_alloc_nearest_color with code to use them; made x_copy_color an identity operation; and disabled freeing of colors (my caches are really simple and don’t include reference counts). That proof-of-concept version seems to have shaved a couple of seconds off the time to pop up the tooltip, but it still takes around three seconds, and the text still doesn’t fill in quickly. I’m including below a summary of the stack traces I got from another run (list of function names and number of times that call stack was seen), using the sources from git as of September 9. The counts are a little different from the previous run (total 176 round trips) but it looks largely similar. Another test with those caches added in used only 72 round trips, of which 41 were XSync calls, and all but one of those were about error checking; of the other 31, the most frequent call was XQueryColors, which probably also could’ve been satisfied from the caches. Ken 28 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « realize_named_face « realize_basic_faces « init_frame_faces « 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 28 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « realize_named_face « realize_basic_faces « init_frame_faces « 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 6 _XReply « XParseColor « x_defined_color « x_decode_color « 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 « detect_input_pending_run_timers « wait_reading_process_output 6 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « x_decode_color « 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 « detect_input_pending_run_timers 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 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 « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XTranslateCoordinates « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 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 « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 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 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 « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XSync « x_had_errors_p « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XSync « x_had_errors_p « 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 2 _XReply « XSync « x_catch_errors « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XSync « x_catch_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 2 _XReply « XSync « x_catch_errors « get_current_wm_state « x_net_wm_state « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XQueryTree « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « realize_default_face « realize_basic_faces « init_frame_faces « 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 2 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda 2 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop 2 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 2 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « Finternal_merge_in_global_face « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « 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 2 _XReply « XListFonts « 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 « call1 2 _XReply « XGetWindowProperty « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XGetWindowProperty « get_current_wm_state « x_net_wm_state « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XGetGeometry « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 2 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « realize_default_face « realize_basic_faces « init_frame_faces « 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 2 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code 2 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch 2 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 2 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_face_colors « realize_x_face « realize_face « Finternal_merge_in_global_face « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « 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 2 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_alloc_lighter_color « x_setup_relief_color « x_setup_relief_colors « x_draw_glyph_string_box « x_draw_glyph_string « draw_glyphs « draw_row_with_mouse_face « show_mouse_face « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch 2 _XReply « 0x00007ffff62c9df0 « XQueryColors « x_query_colors « x_query_color « 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 2 _XReply « 0x00007ffff62c9df0 « XQueryColors « x_query_colors « x_query_color « x_alloc_lighter_color « x_setup_relief_color « x_setup_relief_colors « x_draw_glyph_string_box « x_draw_glyph_string « draw_glyphs « draw_row_with_mouse_face « show_mouse_face « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case 2 _XReply « 0x00007ffff62c9df0 « XQueryColors « xftfont_get_colors « xftfont_prepare_face « prepare_face_for_display « get_glyph_face_and_encoding « fill_glyph_string « draw_glyphs « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 1 _XReply « XSync « x_uncatch_errors « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 1 _XReply « XSync « x_uncatch_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 1 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall 1 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XSync « x_uncatch_errors « get_current_wm_state « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 1 _XReply « XSync « x_sync « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 1 _XReply « XSync « x_had_errors_p « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall 1 _XReply « XSync « x_had_errors_p « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « XSync « x_had_errors_p « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XSync « x_catch_errors « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 1 _XReply « XSync « x_catch_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 1 _XReply « XSync « x_catch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall 1 _XReply « XSync « x_catch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « XSync « x_catch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XSync « x_catch_errors « get_current_wm_state « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 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 1 _XReply « XParseColor « x_defined_color « x_decode_color « 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 1 _XReply « XParseColor « x_defined_color « x_decode_color « x_set_foreground_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 1 _XReply « XParseColor « x_defined_color « x_decode_color « x_set_cursor_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 1 _XReply « XParseColor « x_defined_color « x_decode_color « x_set_cursor_color « x_set_frame_parameters « Fmodify_frame_parameters « Finternal_set_lisp_face_attribute « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall 1 _XReply « XParseColor « x_defined_color « x_decode_color « x_set_border_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 1 _XReply « XParseColor « 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 « readable_events 1 _XReply « XParseColor « x_defined_color « defined_color « load_color2 « load_color « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop 1 _XReply « XListFonts « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code 1 _XReply « XListFonts « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch 1 _XReply « XListFonts « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XGetWindowProperty « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 1 _XReply « XGetWindowProperty « get_current_wm_state « do_ewmh_fullscreen « x_check_fullscreen « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « x_write_glyphs « update_text_area « update_window_line « update_window « update_single_window « 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 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 « detect_input_pending_run_timers « wait_reading_process_output « sit_for 1 _XReply « XAllocColor « x_copy_color « x_set_cursor_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 1 _XReply « XAllocColor « x_copy_color « x_set_cursor_color « x_set_frame_parameters « Fmodify_frame_parameters « Finternal_set_lisp_face_attribute « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « x_decode_color « 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 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « x_decode_color « x_set_foreground_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 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « x_decode_color « x_set_cursor_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 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « x_decode_color « x_set_cursor_color « x_set_frame_parameters « Fmodify_frame_parameters « Finternal_set_lisp_face_attribute « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « x_decode_color « x_set_border_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 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « 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 1 _XReply « XAllocColor « x_alloc_nearest_color_1 « x_defined_color « defined_color « load_color2 « load_color « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch 1 _XReply « 0x00007ffff62c9df0 « XQueryColors « x_query_colors « x_query_color « x_copy_color « x_set_cursor_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 1 _XReply « 0x00007ffff62c9df0 « XQueryColors « x_query_colors « x_query_color « x_copy_color « x_set_cursor_color « x_set_frame_parameters « Fmodify_frame_parameters « Finternal_set_lisp_face_attribute « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code 1 _XReply « 0x00007ffff62c9df0 « XQueryColors « xftfont_get_colors « xftfont_prepare_face « prepare_face_for_display « x_set_mouse_face_gc « x_set_glyph_string_gc « x_draw_glyph_string « draw_glyphs « draw_row_with_mouse_face « show_mouse_face « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « 0x00007ffff62c9df0 « XQueryColors « xftfont_get_colors « xftfont_draw « x_draw_glyph_string_foreground « x_draw_glyph_string « draw_glyphs « draw_row_with_mouse_face « show_mouse_face « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 15 Sep 2015 14:33:01 GMT) Full text and rfc822 format available.Message #8 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Tue, 15 Sep 2015 17:32:07 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Mon, 14 Sep 2015 04:13:41 -0400 > > I’ve noticed that when I’m using a “slow” network link — high bandwidth but a round-trip time of 30-40 milliseconds (remember when that was fast?) — the tooltip window that pops up when I move the mouse, say, over the buffer name in the mode line, takes much longer to come up than when I’m running Emacs on a local display. And if I keep moving the mouse around, I’m likely to get the tooltip for the buffer-name part of the mode line, but displayed somewhere else entirely, depending where the mouse has moved to. > > Based on some earlier investigations, I used gdb to look at calls to _XReply in the Xlib library; this is the routine that flushes the outgoing buffer to the X server and then waits for a response, which contains color info or font info or whatever else is wanted by the caller. It’s of interest because each such call is going to require a round trip to the X server, and on a connection like mine, will add 30ms of delay that cannot be removed without eliminating some of the synchronous Xlib calls — e.g., fewer font queries or whatever. Of course they can’t all be removed, but if some are pointless or redundant we may be able to reduce the time spent waiting. Is there something new in what you discovered, given the fact that a tooltip is just a special kind of frame, and so everything that you reported which causes slow creation of a new frame pertains also to tooltips? Thanks.
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 15 Sep 2015 22:04:02 GMT) Full text and rfc822 format available.Message #11 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Tue, 15 Sep 2015 18:03:01 -0400
Eli Zaretskii <eliz <at> gnu.org> writes: > Is there something new in what you discovered, given the fact that a > tooltip is just a special kind of frame, and so everything that you > reported which causes slow creation of a new frame pertains also to > tooltips? Some of it, yes. Some of this is similar to stuff that I dug up looking into #11822, but which wasn't the "unneeded work on other frames" issue where I thought we wanted to keep the focus for #11822, hence the separate filing. But in this case, most of the X network exchanges appear to be just about the new frame, so the fix for #11822 Stefan proposed doesn't look like it should affect this. While the tooltip is a kind of frame, its creation is handled differently from a regular X frame, which may be why it seems to side-step the additional other-frame work seen in #11822. The heavy use of XSync calls are something I hadn't looked into before, also. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sat, 26 Sep 2015 07:04:01 GMT) Full text and rfc822 format available.Message #14 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sat, 26 Sep 2015 10:03:47 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Mon, 14 Sep 2015 04:13:41 -0400 > > (“spun off” from discussion in bug #11822 that was wandering off topic) Given the latest changes wrt face realization, does this bug still need attention? If so, could you provide an update regarding the portions that take the most time? Thanks.
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 27 Sep 2015 10:36:01 GMT) Full text and rfc822 format available.Message #17 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 27 Sep 2015 06:35:30 -0400
> On Sep 26, 2015, at 03:03, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Ken Raeburn <raeburn <at> permabit.com> >> Date: Mon, 14 Sep 2015 04:13:41 -0400 >> >> (“spun off” from discussion in bug #11822 that was wandering off topic) > > Given the latest changes wrt face realization, does this bug still > need attention? If so, could you provide an update regarding the > portions that take the most time? This one’s still basically unchanged. I just got 165 _XReply round-trip delays, with face realization color requests accounting for 60 of those, x_create_tip_frame initialization using “black” and “white” accounting for a dozen more, and other XParseColor or XAllocColor calls bringing it up to around 100 (maybe fewer than last time, by just a few); 38 XSync calls, almost all for error catching. The other ~20% is XQueryColors, XListFonts, XGetWindowProperty, and a few other calls that need responses. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 27 Sep 2015 10:39:02 GMT) Full text and rfc822 format available.Message #20 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 27 Sep 2015 13:38:24 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Sun, 27 Sep 2015 06:35:30 -0400 > Cc: 21473 <at> debbugs.gnu.org > > This one’s still basically unchanged. I just got 165 _XReply round-trip delays, with face realization color requests accounting for 60 of those, x_create_tip_frame initialization using “black” and “white” accounting for a dozen more, and other XParseColor or XAllocColor calls bringing it up to around 100 (maybe fewer than last time, by just a few); 38 XSync calls, almost all for error catching. The other ~20% is XQueryColors, XListFonts, XGetWindowProperty, and a few other calls that need responses. So you are saying that creating a tip frame is significantly different in this regard from creating any "regular" frame? If so, where are the differences, wrt face realization and color allocation?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 27 Sep 2015 13:30:04 GMT) Full text and rfc822 format available.Message #23 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 27 Sep 2015 09:29:11 -0400
> On Sep 27, 2015, at 06:38, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Ken Raeburn <raeburn <at> permabit.com> >> Date: Sun, 27 Sep 2015 06:35:30 -0400 >> Cc: 21473 <at> debbugs.gnu.org >> >> This one’s still basically unchanged. I just got 165 _XReply round-trip delays, with face realization color requests accounting for 60 of those, x_create_tip_frame initialization using “black” and “white” accounting for a dozen more, and other XParseColor or XAllocColor calls bringing it up to around 100 (maybe fewer than last time, by just a few); 38 XSync calls, almost all for error catching. The other ~20% is XQueryColors, XListFonts, XGetWindowProperty, and a few other calls that need responses. > > So you are saying that creating a tip frame is significantly different > in this regard from creating any "regular" frame? If so, where are > the differences, wrt face realization and color allocation? Some of the creation process is different, yes, though Fx_create_frame and x_create_tip_frame do a lot of the same work; both cause basic face realization on the new frame, but x_create_tip_frame doesn’t seem to have had the issue that triggered it on other frames. (For example, it doesn’t set a default gamma value, while Fx_create_frame does.) The face realization happening here is all about the new frame. This traffic was also present when I was looking into #11822, but as I was using a local display for the new frame, those round trips were fast and thus weren’t a problem. In this case, though, my one and only normal frame is displayed remotely, as is the tip frame, so now the excessive round trips slow it down a lot. Some of it’s going to be necessary, of course, but we’re making repetitive queries for colors we’ve looked up before, probably more XSync calls than are really necessary, etc. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 29 Sep 2015 20:17:02 GMT) Full text and rfc822 format available.Message #26 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Tue, 29 Sep 2015 16:15:59 -0400
[Message part 1 (text/plain, inline)]
I'm working on some experimental patches to implement caching of color-name lookups and color-cell allocations. Along the way I noticed that for visual class TrueColor, we never free color cells on the server, and we can (and do, but only in image.c) synthesize pixel values from RGB values instead of calling XAllocColor and making the round trip to the server. TrueColor is all my laptop display supports, and I gather it's supported on most hardware these days, so it may be worth taking advantage of these to cut out the extra traffic, and I can probably drop the color-cell allocation cache work... Ken
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Wed, 30 Sep 2015 07:25:02 GMT) Full text and rfc822 format available.Message #29 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Wed, 30 Sep 2015 10:23:42 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Sun, 27 Sep 2015 09:29:11 -0400 > Cc: 21473 <at> debbugs.gnu.org > > > > On Sep 27, 2015, at 06:38, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > >> From: Ken Raeburn <raeburn <at> permabit.com> > >> Date: Sun, 27 Sep 2015 06:35:30 -0400 > >> Cc: 21473 <at> debbugs.gnu.org > >> > >> This one’s still basically unchanged. I just got 165 _XReply round-trip delays, with face realization color requests accounting for 60 of those, x_create_tip_frame initialization using “black” and “white” accounting for a dozen more, and other XParseColor or XAllocColor calls bringing it up to around 100 (maybe fewer than last time, by just a few); 38 XSync calls, almost all for error catching. The other ~20% is XQueryColors, XListFonts, XGetWindowProperty, and a few other calls that need responses. > > > > So you are saying that creating a tip frame is significantly different > > in this regard from creating any "regular" frame? If so, where are > > the differences, wrt face realization and color allocation? > > Some of the creation process is different, yes, though Fx_create_frame and x_create_tip_frame do a lot of the same work; both cause basic face realization on the new frame, but x_create_tip_frame doesn’t seem to have had the issue that triggered it on other frames. (For example, it doesn’t set a default gamma value, while Fx_create_frame does.) The face realization happening here is all about the new frame. > > This traffic was also present when I was looking into #11822, but as I was using a local display for the new frame, those round trips were fast and thus weren’t a problem. In this case, though, my one and only normal frame is displayed remotely, as is the tip frame, so now the excessive round trips slow it down a lot. Some of it’s going to be necessary, of course, but we’re making repetitive queries for colors we’ve looked up before, probably more XSync calls than are really necessary, etc. Let me be sure I understand: these XSync calls in the case of popping up a tooltip, are mostly due to color allocation? Or is there other unnecessary face-related traffic that needs to be addressed?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Thu, 01 Oct 2015 10:02:02 GMT) Full text and rfc822 format available.Message #32 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Thu, 01 Oct 2015 06:01:35 -0400
Eli Zaretskii <eliz <at> gnu.org> writes: > Let me be sure I understand: these XSync calls in the case of popping > up a tooltip, are mostly due to color allocation? Or is there other > unnecessary face-related traffic that needs to be addressed? No, the color allocations and XSync calls are two separate causes of delay, each contributing round trips to the server. The XSync calls are mostly due to error-trapping code (not in color lookup or allocation). To pick one example, x_set_mouse_color does a sequence like this: x_catch_errors Calls XSync to make sure we've processed errors from previously sent requests, then pushes an x_error_message_stack structure onto a stack. XCreateFontCursor(x-pointer-shape or XC_xterm) Returns a value but this is a locally-assigned number, not an indication of success. x_check_errors("bad text pointer cursor") Calls XSync to make sure any error from XCreateFontCursor is received and processed. XCreateFontCursor(x-nontext-pointer-shape or XC_left_ptr) x_check_errors("bad nontext pointer cursor") XCreateFontCursor(x-hourglass-pointer-shape or XC_watch) x_check_errors(...etc...) XCreateFontCursor(x-mode-pointer-shape or XC_xterm) x_check_errors(...etc...) Several more XCreateFontCursor calls in a row. x_check_errors(...more generic message...) x_uncatch_errors Calls XSync to make sure we've received errors from any request sent since the last x_catch_errors or x_check_errors, and pops it off the stack. 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. So that's seven XSync calls, seven round trips, to make sure we catch any X server errors returned for this code and turn them into appropriate error messages. (Fun fact: Setting x-hourglass-pointer-shape to a bad value like 999 or "asdf" will prevent the tooltip frame from being created. Or any other X frame.) It's possible to look up the serial number of the next request to be sent to the server (XNextRequest), and the error handler gets a data structure that includes the serial number of the failing request (error_event->serial). So with some more work we could correlate one or more received errors with the requests we sent and pick which one we wanted to report on. (We'd have to deal with XCreateFontCursor potentially sending more than one X protocol request.) We'd still need an XSync at the end of the sequence to flush any pending errors. It occurs to me that maybe we can get rid of the XSync in x_catch_errors, if we record in the x_error_message_stack structure the serial number for the first request for which errors should be recorded there, using XNextRequest. If the error handler sees an older serial number in the error-event structure, then it looks at the next entry in the stack and tries again. Something similar may work for x_uncatch_errors too. Getting back to the trace from my test run, another case I see is x_real_pos_and_offsets. (Called when handle_one_xevent gets ConfigureNotify, presumably for the tooltip window.) It uses XQueryTree to walk up the window hierarchy to the root; the loop uses x_had_errors_p (which calls XSync) each time. It also calls XTranslateCoordinates and then x_had_errors_p. And XGetWindowProperty followed by x_had_errors_p. Since these routines normally return data from the server, if they get errors back, is it ever possible for them to return to their caller without having invoked the error handler on the error event structure? Have the error callback delayed somehow? Looking at some old xfree86 sources online (the first I found), I don't think so, and I have a tough time imagining how a robust package could be built otherwise. If we can rely on it, then in x_real_pos_and_offsets, immediately after functions like XQueryTree, XTranslateCoordinates, XGetWindowProperty, and XGetGeometry, we shouldn't need to call XSync to check whether errors happened. I don't know if there would be a better way to convey that information than extra arguments to the error-trapping routines, though. 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 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 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 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 2 _XReply « XSync « x_had_errors_p « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « 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_had_errors_p « 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 2 _XReply « XSync « x_catch_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 2 _XReply « XSync « x_catch_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 2 _XReply « XSync « x_catch_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 2 _XReply « XQueryTree « 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 « XListFonts « 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 « call1 2 _XReply « XGetWindowProperty « 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 « XGetWindowProperty « 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 2 _XReply « XGetGeometry « 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 1 _XReply « XSync « x_uncatch_errors « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « 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 1 _XReply « XSync « x_uncatch_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 1 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall 1 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XSync « x_uncatch_errors « get_current_wm_state « do_ewmh_fullscreen « x_check_fullscreen « 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 1 _XReply « XSync « x_sync « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « 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 1 _XReply « XSync « x_had_errors_p « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall 1 _XReply « XSync « x_had_errors_p « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « XSync « x_had_errors_p « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XSync « x_catch_errors « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « 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 1 _XReply « XSync « x_catch_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 1 _XReply « XSync « x_catch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall 1 _XReply « XSync « x_catch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 1 _XReply « XSync « x_catch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XSync « x_catch_errors « get_current_wm_state « do_ewmh_fullscreen « x_check_fullscreen « 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 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 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 1 _XReply « XListFonts « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « x_supports_face_attributes_p « Fdisplay_supports_face_attributes_p « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call2 « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code 1 _XReply « XListFonts « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_string_position « note_mode_line_or_margin_highlight « note_mouse_highlight « note_mouse_movement « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « kbd_buffer_get_event « read_event_from_main_queue « read_decoded_event_from_main_queue « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch 1 _XReply « XListFonts « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « realize_x_face « realize_face « lookup_face « face_at_buffer_position « handle_face_prop « handle_stop « start_display « try_window « 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 1 _XReply « XGetWindowProperty « x_wm_supports « do_ewmh_fullscreen « x_check_fullscreen « 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 1 _XReply « XGetWindowProperty « get_current_wm_state « do_ewmh_fullscreen « x_check_fullscreen « 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 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
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Thu, 01 Oct 2015 16:52:01 GMT) Full text and rfc822 format available.Message #35 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Thu, 01 Oct 2015 12:51:14 -0400
Ken Raeburn <raeburn <at> permabit.com> writes: > It occurs to me that maybe we can get rid of the XSync in > x_catch_errors, if we record in the x_error_message_stack structure the > serial number for the first request for which errors should be recorded > there, using XNextRequest. If the error handler sees an older serial > number in the error-event structure, then it looks at the next entry in > the stack and tries again. Something similar may work for > x_uncatch_errors too. Ah...can the stacked entries refer to different displays? That would make things more complicated.
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 04 Oct 2015 09:46:01 GMT) Full text and rfc822 format available.Message #38 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 04 Oct 2015 12:45:42 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Cc: 21473 <at> 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.
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 04 Oct 2015 18:03:02 GMT) Full text and rfc822 format available.Message #41 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 4 Oct 2015 14:02:18 -0400
> On Oct 4, 2015, at 05:45, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Ken Raeburn <raeburn <at> permabit.com> >> Cc: 21473 <at> 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? Yes, the mouse pointer. “Cursor” is the term used in the code (and in X docs) for the shape and color of the mouse pointer. > >> 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. Coordinate translation we presumably can’t avoid. The XSync calls all seem to be about making sure we’re receiving any error events at the points in the code where we want to check for them… and in some cases, I think that’s only because the Xlib interfaces are kind of fuzzy about how to detect if a query for information worked or not. I’ve been experimenting with using XCB interfaces to work around this. With the XCB interfaces I can indeed send a GetGeometry request and a TranslateCoordinates request and a couple more, and then flush the output buffer, and then wait for all the results to come in, and find out whether I got a reply back or an error. So I think in some of these cases the XSync calls can eventually go away, if XCB is available. > >> 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. The XListFonts call we need (though I think once again there are cases where we ask for the same info more than once), but the XSync call here is again about synchronizing error event handling. >> 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). I’ve been working on a set of patches relating to speeding this up: - Cache XParseColor results. - Avoid most direct XAllocColor calls for TrueColor displays. Turns out the TrueColor visual type uses pixel values that encode the RGB values directly, so we don’t actually have to send a message to the server to allocate a color cell. This already was happening in image.c, I mostly just expanded on it. (I think those two made the biggest difference.) - 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. - Use XCB calls in x_real_pos_and_offsets and get_current_wm_state to manage the error handling more directly, so we don’t need to call XSync at all. This one still needs a lot of work. The font-listing code is next on my list. - Try to defer garbage collection while running commands like x-create-frame. With these changes I’ve been able to shave the 5+ second delay for creating the tooltip on my remote connection down to about 2 seconds (including the tooltip delay). Normal frame creation is also faster. But there’s still room for improvement. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 04 Oct 2015 19:41:02 GMT) Full text and rfc822 format available.Message #44 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 04 Oct 2015 22:40:10 +0300
> 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? > - 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.
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Mon, 05 Oct 2015 05:39:02 GMT) Full text and rfc822 format available.Message #47 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: 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
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Mon, 05 Oct 2015 06:26:02 GMT) Full text and rfc822 format available.Message #50 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Mon, 05 Oct 2015 09:25:38 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Mon, 5 Oct 2015 01:38:26 -0400 > Cc: 21473 <at> debbugs.gnu.org > > > 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. Is that black arrow mouse pointer different from what you see if the call to x_set_mouse_color is retained?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 06 Oct 2015 02:16:02 GMT) Full text and rfc822 format available.Message #53 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Mon, 5 Oct 2015 22:15:44 -0400
>> 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. > > Is that black arrow mouse pointer different from what you see if the > call to x_set_mouse_color is retained? No, it appears to be the same. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 06 Oct 2015 02:45:03 GMT) Full text and rfc822 format available.Message #56 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Tue, 06 Oct 2015 05:44:04 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Mon, 5 Oct 2015 22:15:44 -0400 > Cc: 21473 <at> debbugs.gnu.org > > >> 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. > > > > Is that black arrow mouse pointer different from what you see if the > > call to x_set_mouse_color is retained? > > No, it appears to be the same. So I suggest to install such a change. Do you have a patch that can be used?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 06 Oct 2015 09:31:02 GMT) Full text and rfc822 format available.Message #59 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Tue, 6 Oct 2015 05:30:42 -0400
> On Oct 5, 2015, at 22:44, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Ken Raeburn <raeburn <at> permabit.com> >> Date: Mon, 5 Oct 2015 22:15:44 -0400 >> Cc: 21473 <at> debbugs.gnu.org >> >>>> 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. >>> >>> Is that black arrow mouse pointer different from what you see if the >>> call to x_set_mouse_color is retained? >> >> No, it appears to be the same. > > So I suggest to install such a change. Do you have a patch that can > be used? It looks like I was mistaken. It appears that it was using the arrow only because that’s the default pointer shape for the X root window. According to some of the X docs I was reading, if the “cursor” (pointer shape) is never defined for a window, then the window uses the value from the parent window. If I change the root window’s default pointer shape, then when the mouse is in the tooltip window it also uses that shape. I doubt that’s what we want; one of the shapes used by Emacs would be better, even if we only allow one to be used for that frame. Then again, if the window is supposed to go away quickly, maybe we don’t care at all? On a slow, remote link, there can be enough lag for the pointer to be visible in the tooltip window for a good half second at least. The odd part: It appears that it’s already broken, even with the call to x_set_mouse_color being applied to the tooltip frame. I’m still getting whatever odd cursor shape I installed for the root window. This is with the Xquartz server on OS X; I’ll try later with the X.org server. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Tue, 06 Oct 2015 14:47:02 GMT) Full text and rfc822 format available.Message #62 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Tue, 06 Oct 2015 17:46:34 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Tue, 6 Oct 2015 05:30:42 -0400 > Cc: 21473 <at> debbugs.gnu.org > > It looks like I was mistaken. It appears that it was using the arrow only because that’s the default pointer shape for the X root window. According to some of the X docs I was reading, if the “cursor” (pointer shape) is never defined for a window, then the window uses the value from the parent window. > > If I change the root window’s default pointer shape, then when the mouse is in the tooltip window it also uses that shape. I doubt that’s what we want; one of the shapes used by Emacs would be better, even if we only allow one to be used for that frame. Then again, if the window is supposed to go away quickly, maybe we don’t care at all? On a slow, remote link, there can be enough lag for the pointer to be visible in the tooltip window for a good half second at least. > > The odd part: It appears that it’s already broken, even with the call to x_set_mouse_color being applied to the tooltip frame. I’m still getting whatever odd cursor shape I installed for the root window. This is with the Xquartz server on OS X; I’ll try later with the X.org server. I suggest to make that call conditional on a user variable, by default off. Most users, certainly on fast networks, will never see that pointer anyway. WDYT?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Wed, 07 Oct 2015 06:11:02 GMT) Full text and rfc822 format available.Message #65 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Wed, 7 Oct 2015 02:09:47 -0400
> On Oct 6, 2015, at 10:46, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Ken Raeburn <raeburn <at> permabit.com> >> Date: Tue, 6 Oct 2015 05:30:42 -0400 >> Cc: 21473 <at> debbugs.gnu.org >> >> It looks like I was mistaken. It appears that it was using the arrow only because that’s the default pointer shape for the X root window. According to some of the X docs I was reading, if the “cursor” (pointer shape) is never defined for a window, then the window uses the value from the parent window. >> >> If I change the root window’s default pointer shape, then when the mouse is in the tooltip window it also uses that shape. I doubt that’s what we want; one of the shapes used by Emacs would be better, even if we only allow one to be used for that frame. Then again, if the window is supposed to go away quickly, maybe we don’t care at all? On a slow, remote link, there can be enough lag for the pointer to be visible in the tooltip window for a good half second at least. >> >> The odd part: It appears that it’s already broken, even with the call to x_set_mouse_color being applied to the tooltip frame. I’m still getting whatever odd cursor shape I installed for the root window. This is with the Xquartz server on OS X; I’ll try later with the X.org server. It behaves the same on the x.org server. The default root-window mouse cursor is a big “X”, and the same is true for the tooltip window. > > I suggest to make that call conditional on a user variable, by > default off. Most users, certainly on fast networks, will never see > that pointer anyway. > > WDYT? They can see it if any CPU-intensive work keeps Emacs busy right after the tooltip is displayed — garbage collection, auto-revert of large files, processing of data received from the net, etc. Then Emacs may not be able to make the X window disappear right away when the user moves the mouse. I wonder if it might be better to change x_set_mouse_color to check some new field “f->tooltip_p” that makes it define just one cursor. (The arrow we use for non-text areas, or the vertical-bar xterm cursor we use for text?) For users on fast networks, the extra traffic I’m worrying over — which I think would then be reduced to three XSync exchanges, if we also do color-name caching and TrueColor optimizations — wouldn’t be a big deal. A tiny price for getting the display right in a minor case, if we can, and I think I can reduce that count. I think that’s probably better than a new Lisp variable to control low-level protocol details that should usually be invisible, to deal with a problem that we could fix reasonably well in the C code. Of course, there’s also the little matter of making the cursor-setting actually work. Until (unless?) that happens, we might as well disable it for everyone. I can check that in if you'd like. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Wed, 07 Oct 2015 15:33:02 GMT) Full text and rfc822 format available.Message #68 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Wed, 07 Oct 2015 18:31:56 +0300
> From: Ken Raeburn <raeburn <at> permabit.com> > Date: Wed, 7 Oct 2015 02:09:47 -0400 > Cc: 21473 <at> debbugs.gnu.org > > I wonder if it might be better to change x_set_mouse_color to check some new field “f->tooltip_p” that makes it define just one cursor. (The arrow we use for non-text areas, or the vertical-bar xterm cursor we use for text?) Fine, let's do it this way. Can you prepare a patch along these lines? > Of course, there’s also the little matter of making the cursor-setting actually work. Until (unless?) that happens, we might as well disable it for everyone. I can check that in if you'd like. Please do, and thanks.
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Thu, 08 Oct 2015 06:05:02 GMT) Full text and rfc822 format available.Message #71 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Thu, 8 Oct 2015 02:04:46 -0400
> On Oct 7, 2015, at 11:31, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Ken Raeburn <raeburn <at> permabit.com> >> Date: Wed, 7 Oct 2015 02:09:47 -0400 >> Cc: 21473 <at> debbugs.gnu.org >> >> I wonder if it might be better to change x_set_mouse_color to check some new field “f->tooltip_p” that makes it define just one cursor. (The arrow we use for non-text areas, or the vertical-bar xterm cursor we use for text?) > > Fine, let's do it this way. Can you prepare a patch along these > lines? I’ll start working on it, but it’ll be pointless (pointer-less?) unless I can figure out why the settings aren’t taking effect for tooltip frames. >> Of course, there’s also the little matter of making the cursor-setting actually work. Until (unless?) that happens, we might as well disable it for everyone. I can check that in if you'd like. > > Please do, and thanks. I’ve checked this in, and some of the other optimizations I’ve been working on. That still leaves us calling XSync a bit more than necessary, but I need to work on the error-trapping changes a bit more before I’m happy with them. Still, this should be a good improvement over the previous remote performance. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Thu, 08 Oct 2015 08:13:01 GMT) Full text and rfc822 format available.Message #74 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Ken Raeburn <raeburn <at> permabit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21473 <at> debbugs.gnu.org Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Thu, 8 Oct 2015 04:12:21 -0400
> I’ll start working on it, but it’ll be pointless (pointer-less?) unless I can figure out why the settings aren’t taking effect for tooltip frames. That turned out to be much easier than I expected. New commit coming soon. Ken
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 19 Sep 2021 22:30:02 GMT) Full text and rfc822 format available.Message #77 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Kangas <stefan <at> marxist.se> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 19 Sep 2021 15:29:39 -0700
Ken Raeburn <raeburn <at> permabit.com> writes: >> I’ll start working on it, but it’ll be pointless (pointer-less?) unless I can figure out why the settings aren’t taking effect for tooltip frames. > > That turned out to be much easier than I expected. New commit coming soon. (This was last discussed in October 2015.) I see several commits from you in the time since then. Did any of them fix the bug under discussion here, or is this still an issue?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Sun, 24 Apr 2022 13:20:02 GMT) Full text and rfc822 format available.Message #80 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Stefan Kangas <stefan <at> marxist.se> Cc: Ken Raeburn <raeburn <at> permabit.com>, 21473 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 24 Apr 2022 15:19:30 +0200
Stefan Kangas <stefan <at> marxist.se> writes: > (This was last discussed in October 2015.) > > I see several commits from you in the time since then. Did any of them > fix the bug under discussion here, or is this still an issue? This was half a year ago, and there wasn't any response. Does anybody know whether the issues discussed here are still a problem in recent Emacs versions? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org
.
(Sun, 24 Apr 2022 13:21:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Mon, 25 Apr 2022 02:10:01 GMT) Full text and rfc822 format available.Message #85 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Ken Raeburn <raeburn <at> permabit.com> Cc: 21473 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Mon, 25 Apr 2022 10:09:12 +0800
There is now a local cache for colors previously looked up on the X server, and pixels are computed locally without going through color allocation routines on TrueColor visuals. Do you still see this problem?
bug-gnu-emacs <at> gnu.org
:bug#21473
; Package emacs
.
(Mon, 23 May 2022 08:04:02 GMT) Full text and rfc822 format available.Message #88 received at 21473 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Po Lu <luangruo <at> yahoo.com> Cc: Ken Raeburn <raeburn <at> permabit.com>, 21473 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Mon, 23 May 2022 10:02:59 +0200
Po Lu <luangruo <at> yahoo.com> writes: > There is now a local cache for colors previously looked up on the X > server, and pixels are computed locally without going through color > allocation routines on TrueColor visuals. > > Do you still see this problem? More information was requested, but no response was given within a month, so I'm closing this bug report. If the problem still exists, please respond to this email and we'll reopen the bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org
.
(Mon, 23 May 2022 08:04:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Mon, 20 Jun 2022 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.