bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display

[Eli Zaretskii <eliz@gnu.org>]

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