[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21473: 24.5; very slow tooltip display to sort-of-slow remote displa
From: |
Eli Zaretskii |
Subject: |
bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display |
Date: |
Sun, 04 Oct 2015 12:45:42 +0300 |
> From: Ken Raeburn <raeburn@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.
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display,
Eli Zaretskii <=
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Ken Raeburn, 2015/10/08
- bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display, Eli Zaretskii, 2015/10/08