unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
@ 2015-09-14  8:13 Ken Raeburn
  2015-09-15 14:32 ` Eli Zaretskii
  2015-09-26  7:03 ` Eli Zaretskii
  0 siblings, 2 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-09-14  8:13 UTC (permalink / raw)
  To: 21473

(“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






^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-14  8:13 bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Ken Raeburn
@ 2015-09-15 14:32 ` Eli Zaretskii
  2015-09-15 22:03   ` Ken Raeburn
  2015-09-26  7:03 ` Eli Zaretskii
  1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-09-15 14:32 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@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.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-15 14:32 ` Eli Zaretskii
@ 2015-09-15 22:03   ` Ken Raeburn
  0 siblings, 0 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-09-15 22:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473

Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-14  8:13 bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Ken Raeburn
  2015-09-15 14:32 ` Eli Zaretskii
@ 2015-09-26  7:03 ` Eli Zaretskii
  2015-09-27 10:35   ` Ken Raeburn
  1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-09-26  7:03 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@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.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-26  7:03 ` Eli Zaretskii
@ 2015-09-27 10:35   ` Ken Raeburn
  2015-09-27 10:38     ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-09-27 10:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Sep 26, 2015, at 03:03, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-27 10:35   ` Ken Raeburn
@ 2015-09-27 10:38     ` Eli Zaretskii
  2015-09-27 13:29       ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-09-27 10:38 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Sun, 27 Sep 2015 06:35:30 -0400
> Cc: 21473@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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-27 10:38     ` Eli Zaretskii
@ 2015-09-27 13:29       ` Ken Raeburn
  2015-09-29 20:15         ` Ken Raeburn
  2015-09-30  7:23         ` Eli Zaretskii
  0 siblings, 2 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-09-27 13:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Sep 27, 2015, at 06:38, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Sun, 27 Sep 2015 06:35:30 -0400
>> Cc: 21473@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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-27 13:29       ` Ken Raeburn
@ 2015-09-29 20:15         ` Ken Raeburn
  2015-09-30  7:23         ` Eli Zaretskii
  1 sibling, 0 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-09-29 20:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 688 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-27 13:29       ` Ken Raeburn
  2015-09-29 20:15         ` Ken Raeburn
@ 2015-09-30  7:23         ` Eli Zaretskii
  2015-10-01 10:01           ` Ken Raeburn
  1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-09-30  7:23 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Sun, 27 Sep 2015 09:29:11 -0400
> Cc: 21473@debbugs.gnu.org
> 
> 
> > On Sep 27, 2015, at 06:38, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Ken Raeburn <raeburn@permabit.com>
> >> Date: Sun, 27 Sep 2015 06:35:30 -0400
> >> Cc: 21473@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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-09-30  7:23         ` Eli Zaretskii
@ 2015-10-01 10:01           ` Ken Raeburn
  2015-10-01 16:51             ` Ken Raeburn
  2015-10-04  9:45             ` Eli Zaretskii
  0 siblings, 2 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-10-01 10:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-01 10:01           ` Ken Raeburn
@ 2015-10-01 16:51             ` Ken Raeburn
  2015-10-04  9:45             ` Eli Zaretskii
  1 sibling, 0 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-10-01 16:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473

Ken Raeburn <raeburn@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.






^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-01 10:01           ` Ken Raeburn
  2015-10-01 16:51             ` Ken Raeburn
@ 2015-10-04  9:45             ` Eli Zaretskii
  2015-10-04 18:02               ` Ken Raeburn
  1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-10-04  9:45 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Cc: 21473@debbugs.gnu.org
> Date: Thu, 01 Oct 2015 06:01:35 -0400
> 
> We do all of this in "x_set_mouse_color" because the cursor color is a
> property of the cursor object, so we create new cursors, set their
> colors, and then start using them in place of the old ones.

Sorry, I don't understand: by "cursor" here do you mean the mouse
pointer?  If not, i.e. if this is the text cursor, then how is it
related to x_set_mouse_color?

> Below are the _XReply call stacks (with counts) I found once I worked up
> my color handling changes. There were 61 XSync calls in all, this time.
> This was for moving the mouse into the frame to the mode line (with
> focus elsewhere), and waiting for the tooltip to pop up.
> 
>       5 _XReply « XSync « x_check_errors « x_set_mouse_color « x_set_frame_parameters « x_default_parameter « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call1 « timer_check_2 « timer_check « readable_events « get_input_pending

Any idea why we need to call

  x_default_parameter (f, parms, Qmouse_color, build_string ("black"),
		       "pointerColor", "Foreground", RES_TYPE_STRING);

when creating a tip frame?  Do we want the tip frames to be able to
support mouse highlight or something?  If so, we could make this
conditional on some option, because the absolute majority of tooltips
don't use that.

>       4 _XReply « XSync « x_had_errors_p « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main
>       2 _XReply « XTranslateCoordinates « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main
>       2 _XReply « XSync « x_uncatch_errors « x_real_pos_and_offsets « x_real_positions « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main

These are X events that come through the socket, so I don't see how we
can avoid them.  I don't know enough about X to answer your questions
about the possible way of avoiding these XSync calls.

>       2 _XReply « XSync « x_uncatch_errors « xfont_list_pattern « xfont_list « font_list_entities « font_find_for_lface « font_load_for_lface « font_open_by_spec « font_open_by_name « x_default_font_parameter « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall

This loads fonts for the tip frame, so I don't think we can avoid
them.  The font parameter in the tip-frame parameter alist can be
changed by the caller.

>       2 _XReply « XSync « x_uncatch_errors « get_current_wm_state « x_net_wm_state « handle_one_xevent « XTread_socket « gobble_input « handle_async_input « process_pending_signals « xg_select « wait_reading_process_output « sit_for « read_char « read_key_sequence « command_loop_1 « internal_condition_case « command_loop_2 « internal_catch « command_loop « recursive_edit_1 « Frecursive_edit « main

AFAIU, this is where we query the X server about fullscreen, whose
response in case of tip frames is probably known in advance, right?
Perhaps we could handle tip frames specially here, and avoid querying
the server?

>       1 _XReply « XQueryPointer « compute_tip_xy « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call1 « timer_check_2 « timer_check « readable_events « get_input_pending « detect_input_pending_run_timers « wait_reading_process_output « sit_for « read_char

Here we query the server about the mouse pointer position, so we could
position the tip frame.  I don't think we can avoid this one.

>       1 _XReply « XParseColor « x_parse_color « x_defined_color « x_decode_color « x_set_background_color « x_set_frame_parameters « x_default_parameter « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call1 « timer_check_2 « timer_check

Colors for the tip frame; looks unavoidable (modulo some color
caching).

>       1 _XReply « XGetSelectionOwner « Fx_selection_exists_p « Ffuncall « exec_byte_code « Ffuncall « Fapply « Ffuncall « exec_byte_code « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « eval_sub « Feval « internal_condition_case_1 « menu_item_eval_property « parse_tool_bar_item « process_tool_bar_item « map_keymap_item « map_keymap_internal « map_keymap « tool_bar_items « update_tool_bar « prepare_menu_bars « redisplay_internal « redisplay_preserve_echo_area « read_char « read_key_sequence « command_loop_1

That's unrelated to popping up a tooltip.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-04  9:45             ` Eli Zaretskii
@ 2015-10-04 18:02               ` Ken Raeburn
  2015-10-04 19:40                 ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-10-04 18:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Oct 4, 2015, at 05:45, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Cc: 21473@debbugs.gnu.org
>> Date: Thu, 01 Oct 2015 06:01:35 -0400
>> 
>> We do all of this in "x_set_mouse_color" because the cursor color is a
>> property of the cursor object, so we create new cursors, set their
>> colors, and then start using them in place of the old ones.
> 
> Sorry, I don't understand: by "cursor" here do you mean the mouse
> pointer?  If not, i.e. if this is the text cursor, then how is it
> related to x_set_mouse_color?

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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-04 18:02               ` Ken Raeburn
@ 2015-10-04 19:40                 ` Eli Zaretskii
  2015-10-05  5:38                   ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-10-04 19:40 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Sun, 4 Oct 2015 14:02:18 -0400
> Cc: 21473@debbugs.gnu.org
> 
> >>      5 _XReply « XSync « x_check_errors « x_set_mouse_color « x_set_frame_parameters « x_default_parameter « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call1 « timer_check_2 « timer_check « readable_events « get_input_pending
> > 
> > Any idea why we need to call
> > 
> >  x_default_parameter (f, parms, Qmouse_color, build_string ("black"),
> > 		       "pointerColor", "Foreground", RES_TYPE_STRING);
> > 
> > when creating a tip frame?  Do we want the tip frames to be able to
> > support mouse highlight or something?  If so, we could make this
> > conditional on some option, because the absolute majority of tooltips
> > don't use that.
> [...]
>  - Make x_set_mouse_color record serial numbers and use a new error handling routine to check them, reducing the number of XSync calls but not getting rid of them entirely.

You didn't answer my question about the possibility to remove the call
to x_set_mouse_color (and anything mouse-related) altogether in a tip
frame.  Is that feasible?  Could you try that and see if it has any
adverse effects?

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





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-04 19:40                 ` Eli Zaretskii
@ 2015-10-05  5:38                   ` Ken Raeburn
  2015-10-05  6:25                     ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-10-05  5:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Oct 4, 2015, at 15:40, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Sun, 4 Oct 2015 14:02:18 -0400
>> Cc: 21473@debbugs.gnu.org
>> 
>>>>     5 _XReply « XSync « x_check_errors « x_set_mouse_color « x_set_frame_parameters « x_default_parameter « x_create_tip_frame « Fx_show_tip « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « run_hook_with_args « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « Fapply « Ffuncall « exec_byte_code « funcall_lambda « Ffuncall « call1 « timer_check_2 « timer_check « readable_events « get_input_pending
>>> 
>>> Any idea why we need to call
>>> 
>>> x_default_parameter (f, parms, Qmouse_color, build_string ("black"),
>>> 		       "pointerColor", "Foreground", RES_TYPE_STRING);
>>> 
>>> when creating a tip frame?  Do we want the tip frames to be able to
>>> support mouse highlight or something?  If so, we could make this
>>> conditional on some option, because the absolute majority of tooltips
>>> don't use that.
>> [...]
>> - Make x_set_mouse_color record serial numbers and use a new error handling routine to check them, reducing the number of XSync calls but not getting rid of them entirely.
> 
> You didn't answer my question about the possibility to remove the call
> to x_set_mouse_color (and anything mouse-related) altogether in a tip
> frame.  Is that feasible?  Could you try that and see if it has any
> adverse effects?

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

> 
>> - Try to defer garbage collection while running commands like x-create-frame.
> 
> I'd recommend against that, or at most make it optional behavior.
> IME, deferring GC is produces net loss in most situations.  Your
> situation is clearly rare, so skewing the behavior for all the rest of
> the users sounds unwise.

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

Ken




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-05  5:38                   ` Ken Raeburn
@ 2015-10-05  6:25                     ` Eli Zaretskii
  2015-10-06  2:15                       ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-10-05  6:25 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Mon, 5 Oct 2015 01:38:26 -0400
> Cc: 21473@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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-05  6:25                     ` Eli Zaretskii
@ 2015-10-06  2:15                       ` Ken Raeburn
  2015-10-06  2:44                         ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-10-06  2:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473

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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-06  2:15                       ` Ken Raeburn
@ 2015-10-06  2:44                         ` Eli Zaretskii
  2015-10-06  9:30                           ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-10-06  2:44 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Mon, 5 Oct 2015 22:15:44 -0400
> Cc: 21473@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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-06  2:44                         ` Eli Zaretskii
@ 2015-10-06  9:30                           ` Ken Raeburn
  2015-10-06 14:46                             ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-10-06  9:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Oct 5, 2015, at 22:44, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Mon, 5 Oct 2015 22:15:44 -0400
>> Cc: 21473@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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-06  9:30                           ` Ken Raeburn
@ 2015-10-06 14:46                             ` Eli Zaretskii
  2015-10-07  6:09                               ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-10-06 14:46 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Tue, 6 Oct 2015 05:30:42 -0400
> Cc: 21473@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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-06 14:46                             ` Eli Zaretskii
@ 2015-10-07  6:09                               ` Ken Raeburn
  2015-10-07 15:31                                 ` Eli Zaretskii
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-10-07  6:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Oct 6, 2015, at 10:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Tue, 6 Oct 2015 05:30:42 -0400
>> Cc: 21473@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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-07  6:09                               ` Ken Raeburn
@ 2015-10-07 15:31                                 ` Eli Zaretskii
  2015-10-08  6:04                                   ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2015-10-07 15:31 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Wed, 7 Oct 2015 02:09:47 -0400
> Cc: 21473@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.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-07 15:31                                 ` Eli Zaretskii
@ 2015-10-08  6:04                                   ` Ken Raeburn
  2015-10-08  8:12                                     ` Ken Raeburn
  0 siblings, 1 reply; 28+ messages in thread
From: Ken Raeburn @ 2015-10-08  6:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> On Oct 7, 2015, at 11:31, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Wed, 7 Oct 2015 02:09:47 -0400
>> Cc: 21473@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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-08  6:04                                   ` Ken Raeburn
@ 2015-10-08  8:12                                     ` Ken Raeburn
  2021-09-19 22:29                                       ` Stefan Kangas
  2022-04-25  2:09                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 28+ messages in thread
From: Ken Raeburn @ 2015-10-08  8:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 21473


> 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






^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-08  8:12                                     ` Ken Raeburn
@ 2021-09-19 22:29                                       ` Stefan Kangas
  2022-04-24 13:19                                         ` Lars Ingebrigtsen
  2022-04-25  2:09                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 28+ messages in thread
From: Stefan Kangas @ 2021-09-19 22:29 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473

Ken Raeburn <raeburn@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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2021-09-19 22:29                                       ` Stefan Kangas
@ 2022-04-24 13:19                                         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 28+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-24 13:19 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Ken Raeburn, 21473

Stefan Kangas <stefan@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





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2015-10-08  8:12                                     ` Ken Raeburn
  2021-09-19 22:29                                       ` Stefan Kangas
@ 2022-04-25  2:09                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-05-23  8:02                                         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 28+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-25  2:09 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: 21473, Eli Zaretskii

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?





^ permalink raw reply	[flat|nested] 28+ messages in thread

* bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display
  2022-04-25  2:09                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-05-23  8:02                                         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 28+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-23  8:02 UTC (permalink / raw)
  To: Po Lu; +Cc: Ken Raeburn, 21473, Eli Zaretskii

Po Lu <luangruo@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





^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2022-05-23  8:02 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-14  8:13 bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Ken Raeburn
2015-09-15 14:32 ` Eli Zaretskii
2015-09-15 22:03   ` Ken Raeburn
2015-09-26  7:03 ` Eli Zaretskii
2015-09-27 10:35   ` Ken Raeburn
2015-09-27 10:38     ` Eli Zaretskii
2015-09-27 13:29       ` Ken Raeburn
2015-09-29 20:15         ` Ken Raeburn
2015-09-30  7:23         ` Eli Zaretskii
2015-10-01 10:01           ` Ken Raeburn
2015-10-01 16:51             ` Ken Raeburn
2015-10-04  9:45             ` Eli Zaretskii
2015-10-04 18:02               ` Ken Raeburn
2015-10-04 19:40                 ` Eli Zaretskii
2015-10-05  5:38                   ` Ken Raeburn
2015-10-05  6:25                     ` Eli Zaretskii
2015-10-06  2:15                       ` Ken Raeburn
2015-10-06  2:44                         ` Eli Zaretskii
2015-10-06  9:30                           ` Ken Raeburn
2015-10-06 14:46                             ` Eli Zaretskii
2015-10-07  6:09                               ` Ken Raeburn
2015-10-07 15:31                                 ` Eli Zaretskii
2015-10-08  6:04                                   ` Ken Raeburn
2015-10-08  8:12                                     ` Ken Raeburn
2021-09-19 22:29                                       ` Stefan Kangas
2022-04-24 13:19                                         ` Lars Ingebrigtsen
2022-04-25  2:09                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-23  8:02                                         ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).