From: David Reitter <david.reitter@gmail.com>
To: Adrian Robert <adrian.b.robert@gmail.com>
Cc: 2530@emacsbugs.donarmstrong.com, Ian Eure <ian@digg.com>,
Emacs-Devel devel <emacs-devel@gnu.org>
Subject: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Mon, 4 May 2009 18:55:09 -0400 [thread overview]
Message-ID: <B31667CB-C4A4-48A4-A1E0-7D81AD6880A3__36419.7101364427$1241478736$gmane$org@gmail.com> (raw)
In-Reply-To: <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]
On Apr 23, 2009, at 11:27 PM, Adrian Robert wrote:
>> Does anyone have an idea how to fix issue 2530? I think this
>> slowness is quite painful. In my case, it is the tabbar.el variant
>> that I'm using that causes this - I'm using several overlays (for a
>> tab-close button, for instance) that get redrawn one by one. I
>> would imagine that this will annoy users in other use cases as well.
>
> Or to ask it another way, is there any reason anyone can think of
> that redisplay would force calls through the x_draw_glyph_string
> pathway once for every character when overlays are present?
OK, my observation from tracing this is that it doesn't draw every
glyph separately, but that it identifies regions of a common face, at
best a full row of course. In the case of mouse-face, in the load-
history-C-j example, we still have a lot of separate strings because
without the mouse-face, there are still a lot of separate regions.
The distinction between them may be lost (which is very unfortunate
from an UI point of view), but the region identification algorithm
(BUILD_GLYPH_STRINGS I suppose) doesn't see that.
Now, in NS (or at least in Cocoa), there seem to be screen updates
every time we draw a glyph string. If we wrap the code in
show_mouse_face in NS[Dis|En]ableScreen, the problem goes away for me
(and it's not just delayed).
Same for the header-line/overlay issues I reported in #2530.
Note that I'm not claiming that the patch below is the right fix...:
Moving the mouse a bit causes the whole mouse highlight to flicker.
I suspect that it's the same underlying problem. I wonder if we need
to wrap more code in NSDisableScreenUpdates.
diff --git a/src/xdisp.c b/src/xdisp.c
index ac989d3..fc319ca 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -22790,6 +22790,10 @@ show_mouse_face (dpyinfo, draw)
struct window *w = XWINDOW (dpyinfo->mouse_face_window);
struct frame *f = XFRAME (WINDOW_FRAME (w));
+#ifdef NS_IMPL_COCOA
+ NSDisableScreenUpdates ();
+#endif
+
if (/* If window is in the process of being destroyed, don't bother
to do anything. */
w->current_matrix != NULL
@@ -22852,6 +22856,9 @@ show_mouse_face (dpyinfo, draw)
UNBLOCK_INPUT;
}
}
+#ifdef NS_IMPL_COCOA
+ NSEnableScreenUpdates ();
+#endif
/* Change the mouse cursor. */
if (draw == DRAW_NORMAL_TEXT && !EQ (dpyinfo->mouse_face_window, f-
>tool_bar_window))
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
next prev parent reply other threads:[~2009-05-04 22:55 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 21:29 bug#2530: 23/NS: redraws according to mouse-face are slow Adrian Robert
2009-04-20 18:01 ` David Reitter
2009-04-24 3:27 ` Adrian Robert
2009-05-04 22:55 ` David Reitter
2009-05-04 23:24 ` Leo
2009-05-05 1:53 ` bug#2530: " Chong Yidong
2009-05-05 1:53 ` Chong Yidong
2009-05-05 3:37 ` bug#2530: " David Reitter
2009-05-05 3:37 ` David Reitter
2009-05-05 10:36 ` Adrian Robert
2009-05-05 14:13 ` bug#2530: " Chong Yidong
2009-05-05 14:13 ` Chong Yidong
2009-05-05 17:32 ` David Reitter
2016-01-14 5:08 ` bug#2530: " Andrew Hyatt
2016-01-14 5:08 ` Andrew Hyatt
2016-01-14 20:34 ` Alan J Third
2016-01-14 21:00 ` David Reitter
2016-01-14 21:00 ` David Reitter
2016-01-14 21:39 ` Christian Kruse
2016-01-15 7:38 ` Eli Zaretskii
2016-01-15 7:38 ` Eli Zaretskii
2016-01-16 4:15 ` Andrew Hyatt
2016-01-16 4:15 ` Andrew Hyatt
2016-01-14 21:39 ` Christian Kruse
2009-05-05 17:32 ` David Reitter
2009-05-06 1:47 ` Stefan Monnier
2009-05-06 1:47 ` Stefan Monnier
2009-05-06 7:40 ` YAMAMOTO Mitsuharu
2009-05-06 7:40 ` bug#2530: " YAMAMOTO Mitsuharu
2009-05-06 0:50 ` YAMAMOTO Mitsuharu
2009-05-06 0:50 ` YAMAMOTO Mitsuharu
2009-05-06 1:55 ` bug#2530: " Adrian Robert
2009-05-06 1:55 ` Adrian Robert
2009-05-06 2:25 ` bug#2530: " YAMAMOTO Mitsuharu
2009-05-06 2:25 ` YAMAMOTO Mitsuharu
2009-05-05 10:36 ` bug#2530: " Adrian Robert
2009-05-04 22:55 ` David Reitter [this message]
2009-04-24 3:27 ` Adrian Robert
2009-04-20 18:01 ` David Reitter
-- strict thread matches above, loose matches on Subject: below --
2009-03-01 22:34 David Reitter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='B31667CB-C4A4-48A4-A1E0-7D81AD6880A3__36419.7101364427$1241478736$gmane$org@gmail.com' \
--to=david.reitter@gmail.com \
--cc=2530@emacsbugs.donarmstrong.com \
--cc=adrian.b.robert@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ian@digg.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.