From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Sun, 4 Oct 2015 14:02:18 -0400 Message-ID: <5AFBFA9B-153C-4CFB-8864-BAB733413B11@permabit.com> References: <9F31D581-6B5A-42B7-8031-6920089AFFF4@permabit.com> <83pp15hdbg.fsf@gnu.org> <59C0A752-87BB-4467-9A3F-DC1E5A278842@permabit.com> <83612wf8pr.fsf@gnu.org> <83si5wbcap.fsf@gnu.org> <6ebnci3o1s.fsf@just-testing.permabit.com> <83oagf0xx5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443981804 11593 80.91.229.3 (4 Oct 2015 18:03:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 18:03:24 +0000 (UTC) Cc: 21473@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 04 20:03:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zincu-0005SD-Br for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Oct 2015 20:03:12 +0200 Original-Received: from localhost ([::1]:43297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zinct-0007Qa-J3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Oct 2015 14:03:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zincp-0007QP-Oq for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 14:03:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zincl-0000Vr-6Z for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 14:03:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zincl-0000Vn-2v for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 14:03:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zinck-0002mJ-Gb for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2015 14:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Oct 2015 18:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21473 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21473-submit@debbugs.gnu.org id=B21473.144398174610632 (code B ref 21473); Sun, 04 Oct 2015 18:03:02 +0000 Original-Received: (at 21473) by debbugs.gnu.org; 4 Oct 2015 18:02:26 +0000 Original-Received: from localhost ([127.0.0.1]:54553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zinc9-0002lP-Nn for submit@debbugs.gnu.org; Sun, 04 Oct 2015 14:02:26 -0400 Original-Received: from mail-qg0-f47.google.com ([209.85.192.47]:35732) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zinc7-0002lH-L3 for 21473@debbugs.gnu.org; Sun, 04 Oct 2015 14:02:24 -0400 Original-Received: by qgt47 with SMTP id 47so132694317qgt.2 for <21473@debbugs.gnu.org>; Sun, 04 Oct 2015 11:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JZAmqNz+Zy2mcpFxQtwJzvzX4V6CEuM0KmPEjGwV58s=; b=evqTmBNugZeW2bhOWvFSgkQnanAGENeygFqHgrgtu8K/RVFlrwnmEI2z9fz79yh5vp D2cj5wfVYzhu6wVXKF/iM7vqjECp4awQByjcfsDg0/UfS90N6+CjLvWpB+4JWShGJjo+ 9JUoN3oXJlxZ801+AxYkRJYVpPedY2gv6SCOw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JZAmqNz+Zy2mcpFxQtwJzvzX4V6CEuM0KmPEjGwV58s=; b=I+DW5uwQfhYXkysCt9VSJ4ggxEica5+gH01kUK9ni53yFfkxGCdrf3l7zA5xlaNcV5 ypPi8VynQ7VFOYOBMQeMIUy6+ybJvKyu/qf7LNiRkwNUkJIjQ2lle8ffD/xn12kOZFs6 rjI86yaMVGVyZzf2/Zc9uo0/OTgpr67NPh2nHbACHp7qYFWiROj61RPHWyz4+zlPvWl7 DenFfTXP1DdsbPBPnjesPJSFIngYFWhw7fHoYuifGnVb9Pq5B7nruExNJ3Tm6daKOehz hyoJQfr/wsIN1xABZ8P9zbqN0cZWgSvvOenK6OcQD8JWKH9wyTwyMKUkoqWI7/CP7iTc bGGQ== X-Gm-Message-State: ALoCoQlqnm4uKoqbX6Hll9tLJWVWn79gjSBmtm/owk8e4NH46b5INNPIWpNpH5dBRPsCsCGAV25W X-Received: by 10.140.150.139 with SMTP id 133mr36892235qhw.58.1443981742990; Sun, 04 Oct 2015 11:02:22 -0700 (PDT) Original-Received: from [192.168.17.111] (c-66-31-203-101.hsd1.ma.comcast.net. [66.31.203.101]) by smtp.gmail.com with ESMTPSA id s12sm9469878qkl.2.2015.10.04.11.02.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 Oct 2015 11:02:20 -0700 (PDT) In-Reply-To: <83oagf0xx5.fsf@gnu.org> X-Mailer: Apple Mail (2.2104) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107292 Archived-At: > On Oct 4, 2015, at 05:45, Eli Zaretskii wrote: >=20 >> From: Ken Raeburn >> Cc: 21473@debbugs.gnu.org >> Date: Thu, 01 Oct 2015 06:01:35 -0400 >>=20 >> 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. >=20 > 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. =E2=80=9CCursor=E2=80=9D is the term used in the = code (and in X docs) for the shape and color of the mouse pointer. >=20 >> 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. >>=20 >> 5 _XReply =C2=AB XSync =C2=AB x_check_errors =C2=AB = x_set_mouse_color =C2=AB x_set_frame_parameters =C2=AB = x_default_parameter =C2=AB x_create_tip_frame =C2=AB Fx_show_tip =C2=AB = Ffuncall =C2=AB exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB= exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB = run_hook_with_args =C2=AB Ffuncall =C2=AB exec_byte_code =C2=AB = funcall_lambda =C2=AB Ffuncall =C2=AB Fapply =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB call1 =C2=AB = timer_check_2 =C2=AB timer_check =C2=AB readable_events =C2=AB = get_input_pending >=20 > Any idea why we need to call >=20 > x_default_parameter (f, parms, Qmouse_color, build_string ("black"), > "pointerColor", "Foreground", RES_TYPE_STRING); >=20 > 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. >=20 >> 4 _XReply =C2=AB XSync =C2=AB x_had_errors_p =C2=AB = x_real_pos_and_offsets =C2=AB x_real_positions =C2=AB handle_one_xevent = =C2=AB XTread_socket =C2=AB gobble_input =C2=AB handle_async_input =C2=AB = process_pending_signals =C2=AB xg_select =C2=AB = wait_reading_process_output =C2=AB sit_for =C2=AB read_char =C2=AB = read_key_sequence =C2=AB command_loop_1 =C2=AB internal_condition_case = =C2=AB command_loop_2 =C2=AB internal_catch =C2=AB command_loop =C2=AB = recursive_edit_1 =C2=AB Frecursive_edit =C2=AB main >> 2 _XReply =C2=AB XTranslateCoordinates =C2=AB = x_real_pos_and_offsets =C2=AB x_real_positions =C2=AB handle_one_xevent = =C2=AB XTread_socket =C2=AB gobble_input =C2=AB handle_async_input =C2=AB = process_pending_signals =C2=AB xg_select =C2=AB = wait_reading_process_output =C2=AB sit_for =C2=AB read_char =C2=AB = read_key_sequence =C2=AB command_loop_1 =C2=AB internal_condition_case = =C2=AB command_loop_2 =C2=AB internal_catch =C2=AB command_loop =C2=AB = recursive_edit_1 =C2=AB Frecursive_edit =C2=AB main >> 2 _XReply =C2=AB XSync =C2=AB x_uncatch_errors =C2=AB = x_real_pos_and_offsets =C2=AB x_real_positions =C2=AB handle_one_xevent = =C2=AB XTread_socket =C2=AB gobble_input =C2=AB handle_async_input =C2=AB = process_pending_signals =C2=AB xg_select =C2=AB = wait_reading_process_output =C2=AB sit_for =C2=AB read_char =C2=AB = read_key_sequence =C2=AB command_loop_1 =C2=AB internal_condition_case = =C2=AB command_loop_2 =C2=AB internal_catch =C2=AB command_loop =C2=AB = recursive_edit_1 =C2=AB Frecursive_edit =C2=AB main >=20 > 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=E2=80=99t avoid. The XSync = calls all seem to be about making sure we=E2=80=99re receiving any error = events at the points in the code where we want to check for them=E2=80=A6 = and in some cases, I think that=E2=80=99s only because the Xlib = interfaces are kind of fuzzy about how to detect if a query for = information worked or not. I=E2=80=99ve 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. >=20 >> 2 _XReply =C2=AB XSync =C2=AB x_uncatch_errors =C2=AB = xfont_list_pattern =C2=AB xfont_list =C2=AB font_list_entities =C2=AB = font_find_for_lface =C2=AB font_load_for_lface =C2=AB font_open_by_spec = =C2=AB font_open_by_name =C2=AB x_default_font_parameter =C2=AB = x_create_tip_frame =C2=AB Fx_show_tip =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB = run_hook_with_args =C2=AB Ffuncall =C2=AB exec_byte_code =C2=AB = funcall_lambda =C2=AB Ffuncall =C2=AB Fapply =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall >=20 > 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 =C2=AB XParseColor =C2=AB x_parse_color =C2=AB = x_defined_color =C2=AB x_decode_color =C2=AB x_set_background_color =C2=AB= x_set_frame_parameters =C2=AB x_default_parameter =C2=AB = x_create_tip_frame =C2=AB Fx_show_tip =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB = run_hook_with_args =C2=AB Ffuncall =C2=AB exec_byte_code =C2=AB = funcall_lambda =C2=AB Ffuncall =C2=AB Fapply =C2=AB Ffuncall =C2=AB = exec_byte_code =C2=AB funcall_lambda =C2=AB Ffuncall =C2=AB call1 =C2=AB = timer_check_2 =C2=AB timer_check >=20 > Colors for the tip frame; looks unavoidable (modulo some color > caching). I=E2=80=99ve 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=E2=80=99t 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=E2=80=99t 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=E2=80=99ve 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=E2=80=99s still room for improvement. Ken=