GNU bug report logs - #2530
23/NS: redraws according to mouse-face are slow

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2530 in the body.
You can then email your comments to 2530 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23/NS: redraws according to mouse-face are slow
Date: Sun, 1 Mar 2009 17:34:24 -0500

[Message part 1 (text/plain, inline)]

I find that the redisplay of overlays that happens when the mouse is  
moved into an overlay with a mouse-face property are much slower in  
Emacs 23 (NS, under Cocoa/OS X).  It is pretty much a nasty animation  
- every layer is redrawn from left to right, it seems, and every step  
is visible.  It seems that background is drawn first, and then the  
text over it.

The overlays I am working with are in the header-line; I'm using (an  
adapted version of) tabbar.el for this.  The resulting package is a  
not stand-alone and I'd have a hard time turning it into a small test  
case; before I work on this, I'd rather ask here if this problem is a  
known one.

I have experimented with calls to NSDisableScreenUpdates () in  
ns_update_begin, ns_update_window_begin and ns_focus, but that didn't  
help at all.

[smime.p7s (application/pkcs7-signature, attachment)]

Message #12 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 2530 <at> debbugs.gnu.org
Cc: David Reitter <david.reitter <at> gmail.com>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 4 Mar 2009 23:29:48 +0200

> I find that the redisplay of overlays that happens when the mouse is
> moved into an overlay with a mouse-face property are much slower in
> Emacs 23 (NS, under Cocoa/OS X).  It is pretty much a nasty animation
> - every layer is redrawn from left to right, it seems, and every step
> is visible.  It seems that background is drawn first, and then the
> text over it.

Yes, this has been an issue for years from Emacs on Aqua on and it  
completely baffles me.  The NS code for handling mouse face is  
identical to other platforms as far as I can tell, so I don't know  
why the issue occurs only here.  And the animation is far slower than  
any code on the NS side could be taking.  It must be a bug somewhere  
on the core display side that is exposed because (guessing here) the  
event loop under NS is done slightly differently.

Message #17 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Mon, 20 Apr 2009 14:01:17 -0400

[Message part 1 (text/plain, inline)]

On Mar 4, 2009, at 4:29 PM, Adrian Robert wrote:

>> I find that the redisplay of overlays that happens when the mouse is
>> moved into an overlay with a mouse-face property are much slower in
>> Emacs 23 (NS, under Cocoa/OS X).  It is pretty much a nasty animation
>> - every layer is redrawn from left to right, it seems, and every step
>> is visible.  It seems that background is drawn first, and then the
>> text over it.
>
> Yes, this has been an issue for years from Emacs on Aqua on and it  
> completely baffles me.  The NS code for handling mouse face is  
> identical to other platforms as far as I can tell, so I don't know  
> why the issue occurs only here.  And the animation is far slower  
> than any code on the NS side could be taking.  It must be a bug  
> somewhere on the core display side that is exposed because (guessing  
> here) the event loop under NS is done slightly differently.

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.

[smime.p7s (application/pkcs7-signature, attachment)]

Message #22 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Fri, 24 Apr 2009 09:12:46 +0545

On Apr 20, 2009, at 11:46 PM, David Reitter wrote:

> On Mar 4, 2009, at 4:29 PM, Adrian Robert wrote:
>
>>> I find that the redisplay of overlays that happens when the mouse is
>>> moved into an overlay with a mouse-face property are much slower in
>>> Emacs 23 (NS, under Cocoa/OS X).  It is pretty much a nasty  
>>> animation
>>> - every layer is redrawn from left to right, it seems, and every  
>>> step
>>> is visible.  It seems that background is drawn first, and then the
>>> text over it.
>>
>> Yes, this has been an issue for years from Emacs on Aqua on and it  
>> completely baffles me.  The NS code for handling mouse face is  
>> identical to other platforms as far as I can tell, so I don't know  
>> why the issue occurs only here.  And the animation is far slower  
>> than any code on the NS side could be taking.  It must be a bug  
>> somewhere on the core display side that is exposed because  
>> (guessing here) the event loop under NS is done slightly differently.
>
> 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?

Message #27 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Ian Eure <ian <at> digg.com>
Cc: Emacs-Devel devel <emacs-devel <at> gnu.org>, 2530 <at> debbugs.gnu.org
Subject: Re: NextStep port is in bad shape
Date: Mon, 4 May 2009 17:58:32 -0400

[Message part 1 (text/plain, inline)]

Hi Ian,

On May 4, 2009, at 4:06 PM, Ian Eure wrote:
> The main issue is performance. It's _really_ slow. In particular,  
> using Flyspell makes it really horrible to use (#2056). There also  
> seem to be problems with slow redrawing. If you highlight a URL in  
> ERC with the mouse, then move point across it, you can see it lag  
> and redraw the entire highlighted region. Drawing a highlight over a  
> multi-line area is so slow that you can watch it draw.
>
> In general, it just doesn't feel like it's ready for a stable  
> release. Are these issues known and is someone working on them?

Yes, the issue has been known for a long time.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2530

To reproduce:

Emacs -Q
type:  load-history
C-j
move mouse cursor over output.

The last message about this come from Adrian Roberts, on Apr 23:

>> On Apr 20, 2009, at 11:46 PM, David Reitter 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?

[smime.p7s (application/pkcs7-signature, attachment)]

Message #32 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Emacs-Devel devel <emacs-devel <at> gnu.org>,
        Ian Eure <ian <at> digg.com>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Mon, 4 May 2009 18:55:09 -0400

[Message part 1 (text/plain, inline)]

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

[smime.p7s (application/pkcs7-signature, attachment)]

Message #37 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        Ian Eure <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Mon, 04 May 2009 21:53:10 -0400

Thanks for debugging this.

> Now, in NS (or at least in Cocoa), there seem to be screen updates
> every time we draw a glyph string.

I see.  It seems ns_draw_glyph_string is a lot more expensive that
x_draw_glyph_string.  The show_mouse_face function assumes that the
*_draw_glyph_string operation is relatively cheap, which is why it's
called inside a loop.

My guess is that the problem lies in the calls to ns_focus and
ns_unfocus in ns_draw_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.

If possible, we should minimize the amount of platform-dependent code
inside xdisp.c.  Could you experiment with putting these calls somewhere
in nsterm.m, say surrounding the calls to note_mouse_highlight?

Also, could it be ns_update_begin and ns_update_end that you want to
call, instead of NSDisableScreen and NSEnableScreen?

Message #42 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        Ian Eure <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Mon, 4 May 2009 23:37:22 -0400

[Message part 1 (text/plain, inline)]

On May 4, 2009, at 9:53 PM, Chong Yidong wrote:

> I see.  It seems ns_draw_glyph_string is a lot more expensive that
> x_draw_glyph_string.  The show_mouse_face function assumes that the
> *_draw_glyph_string operation is relatively cheap, which is why it's
> called inside a loop.
>
> My guess is that the problem lies in the calls to ns_focus and
> ns_unfocus in ns_draw_glyph_string.

Right - but we still need them, at least for clipping.
That said, because of the clipping, calls to ns_focus may be more  
expensive than desirable. We have multiple calls to  
ns_draw_glyph_string, often more than one for each row, but we only  
need one clipping for the whole frame.  So, ideally we'd call ns_focus  
outside the loops that call ns_draw_glyph_string, but the architecture  
won't allow that.

>> 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.
>
> If possible, we should minimize the amount of platform-dependent code
> inside xdisp.c.  Could you experiment with putting these calls  
> somewhere
> in nsterm.m, say surrounding the calls to note_mouse_highlight?
>
> Also, could it be ns_update_begin and ns_update_end that you want to
> call, instead of NSDisableScreen and NSEnableScreen?

Yes, sure, this variant works well, and it takes care of the ugly  
flicker as well.
(However, when moving the mouse over a piece of text with (common)  
mouse-face property, we shouldn't need to redraw in the first place,  
and that should be addressed at some point, perhaps after 23.1.)

http://github.com/davidswelt/aquamacs-emacs/commit/9e98aaff17dd24ffa45743163df553938815498f

There are further places where we need it, e.g. when scrolling.  Also,  
scrolling with the mouse wheel doesn't always work when the mouse is  
over a highlighted (mouse-faced) piece of text.  Will look into this  
again.

[smime.p7s (application/pkcs7-signature, attachment)]

Message #47 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 2530 <at> debbugs.gnu.org,
        Ian Eure <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Tue, 5 May 2009 17:36:31 +0700

On May 5, 2009, at 10:37 AM, David Reitter wrote:

> On May 4, 2009, at 9:53 PM, Chong Yidong wrote:
>
>> I see.  It seems ns_draw_glyph_string is a lot more expensive that
>> x_draw_glyph_string.  The show_mouse_face function assumes that the
>> *_draw_glyph_string operation is relatively cheap, which is why it's
>> called inside a loop.
>>
>> My guess is that the problem lies in the calls to ns_focus and
>> ns_unfocus in ns_draw_glyph_string.
>
> Right - but we still need them, at least for clipping.
> That said, because of the clipping, calls to ns_focus may be more  
> expensive than desirable. We have multiple calls to  
> ns_draw_glyph_string, often more than one for each row, but we only  
> need one clipping for the whole frame.  So, ideally we'd call  
> ns_focus outside the loops that call ns_draw_glyph_string, but the  
> architecture won't allow that.
>
>>> 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.
>>
>> If possible, we should minimize the amount of platform-dependent code
>> inside xdisp.c.  Could you experiment with putting these calls  
>> somewhere
>> in nsterm.m, say surrounding the calls to note_mouse_highlight?
>>
>> Also, could it be ns_update_begin and ns_update_end that you want to
>> call, instead of NSDisableScreen and NSEnableScreen?
>
> Yes, sure, this variant works well, and it takes care of the ugly  
> flicker as well.
> (However, when moving the mouse over a piece of text with (common)  
> mouse-face property, we shouldn't need to redraw in the first  
> place, and that should be addressed at some point, perhaps after  
> 23.1.)

That ns_update_begin() acheives the same effect suggests that perhaps  
the core mouse face code should do this (through the RIF).   
ns_draw_glyph_string() is not slow for any other operations, despite  
the fact that it is called with the same granularity (same-face-glyph- 
run) everywhere, likely because the update_begin()/end() batching is  
used.

(And yes, thanks for tracking this David!)

-Adrian

Message #52 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: David Reitter <david.reitter <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        "\
 Ian Eure" <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Tue, 05 May 2009 10:13:12 -0400

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

> That ns_update_begin() acheives the same effect suggests that perhaps
> the core mouse face code should do this (through the RIF).

Yes, show_mouse_face (or one of its callers) should probably call
update_begin and update_end.  But it's a little far along in the pretest
to risk that.  I'll make a note of revisiting this after the release.

Could either your or David check in the nsterm.m fix, assuming no other
problems turn up with it?

Message #57 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        "\ Ian Eure" <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Tue, 5 May 2009 13:32:43 -0400

On May 5, 2009, at 10:13 AM, Chong Yidong wrote:

> Could either your or David check in the nsterm.m fix, assuming no  
> other
> problems turn up with it?

I will test it for a day or two, but check it in soon.

I still think there are other places where the same technique would be  
beneficial, but they would be outside of ns*.m, albeit in #ifdefs.   
From the sound of your messages, I take it we'll hold off on that.

Getting back to Ian's original point: Overall, if we were to release  
now, I would consider the NS port "usable", but "experimental" rather  
than "stable".

Message #62 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: David Reitter <david.reitter <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        Chong Yidong <cyd <at> stupidchicken.com>, Ian Eure <ian <at> digg.com>,
        Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 06 May 2009 09:50:21 +0900

>>>>> On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert <adrian.b.robert <at> gmail.com> said:

> That ns_update_begin() acheives the same effect suggests that
> perhaps the core mouse face code should do this (through the RIF).
> ns_draw_glyph_string() is not slow for any other operations, despite
> the fact that it is called with the same granularity
> (same-face-glyph- run) everywhere, likely because the
> update_begin()/end() batching is used.

The effect of ns_update_begin seems to avoid -[NSWindow flushWindow]
call (via ns_unfocus) for each ns_draw_glyph_string call.  Does this
frequent flushing necessary in the first place?  Other terms don't
seem to do flushing for each string drawing call.

				    YAMAMOTO Mitsuharu
				mituharu <at> math.s.chib-u.ac.jp

Message #67 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        David Reitter <david.reitter <at> gmail.com>, Ian Eure <ian <at> digg.com>,
        Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Tue, 05 May 2009 21:47:04 -0400

>> That ns_update_begin() acheives the same effect suggests that perhaps
>> the core mouse face code should do this (through the RIF).
> Yes, show_mouse_face (or one of its callers) should probably call
> update_begin and update_end.  But it's a little far along in the pretest
> to risk that.  I'll make a note of revisiting this after the release.

I think as long as this is guaranteed to only affect the NS port, we can
still install it before the release (assuming tests indicate it does
improve the behavior, and assuming we agree that it's the right way to
fix it).


        Stefan

Message #72 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: David Reitter <david.reitter <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        Chong Yidong <cyd <at> stupidchicken.com>,
        Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 6 May 2009 08:55:36 +0700

On May 6, 2009, at 7:50 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert  
>>>>>> <adrian.b.robert <at> gmail.com> said:
>
>> That ns_update_begin() acheives the same effect suggests that
>> perhaps the core mouse face code should do this (through the RIF).
>> ns_draw_glyph_string() is not slow for any other operations, despite
>> the fact that it is called with the same granularity
>> (same-face-glyph- run) everywhere, likely because the
>> update_begin()/end() batching is used.
>
> The effect of ns_update_begin seems to avoid -[NSWindow flushWindow]
> call (via ns_unfocus) for each ns_draw_glyph_string call.  Does this
> frequent flushing necessary in the first place?  Other terms don't
> seem to do flushing for each string drawing call.

My assumption was that it is legal to call draw_glyph_string()  
outside of an update_begin()-end() pair.  So draw_glyph_string() must  
be able to operate in "self-contained" mode, which and the flush is  
needed.  The same logic holds for other RIF functions -- that they  
can either be called in one-shot mode or in batch mode (inside update  
begin-end).  In the latter case, focus/unfocus reflect the batching  
by holding screen flush until end.

Emacs core seems to batch most/all other sets of operations done at  
once as part of a single redisplay.

It may be that screen update batching is handled implicitly by the  
window system for X, so the distinction doesn't get made in the code  
there.

Some behavior in this area differs between MacOS and GNUstep (as may  
be seen, e.g., from the ifdefs in ns_[un]focus]), so any changes made  
should be tested on both platforms before committing.

Message #77 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: David Reitter <david.reitter <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        Chong Yidong <cyd <at> stupidchicken.com>,
        Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 06 May 2009 11:25:35 +0900

>>>>> On Wed, 6 May 2009 08:55:36 +0700, Adrian Robert <adrian.b.robert <at> gmail.com> said:

>> The effect of ns_update_begin seems to avoid -[NSWindow
>> flushWindow] call (via ns_unfocus) for each ns_draw_glyph_string
>> call.  Does this frequent flushing necessary in the first place?
>> Other terms don't seem to do flushing for each string drawing call.

> My assumption was that it is legal to call draw_glyph_string()
> outside of an update_begin()-end() pair.  So draw_glyph_string()
> must be able to operate in "self-contained" mode, which and the
> flush is needed.  The same logic holds for other RIF functions --
> that they can either be called in one-shot mode or in batch mode
> (inside update begin-end).  In the latter case, focus/unfocus
> reflect the batching by holding screen flush until end.

Other terms don't do flushing even at update_end, let alone at the end
of each one-shot drawing operation (you may see XFlush calls in the
code but they are mostly defined as no-ops).  IIUC, flushing happens
only by explicit flush_display(_optional) RIF calls or at the timing
of polling/receiving window system events (e.g., XPending on X11, and
ReceiveNextEvent on Carbon) implicitly.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #82 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 2530 <at> debbugs.gnu.org,
        David Reitter <david.reitter <at> gmail.com>, Ian Eure <ian <at> digg.com>,
        Adrian Robert <adrian.b.robert <at> gmail.com>,
        Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 06 May 2009 16:40:52 +0900

>>>>> On Tue, 05 May 2009 21:47:04 -0400, Stefan Monnier <monnier <at> iro.umontreal.ca> said:

>>> That ns_update_begin() acheives the same effect suggests that
>>> perhaps the core mouse face code should do this (through the RIF).
>> Yes, show_mouse_face (or one of its callers) should probably call
>> update_begin and update_end.  But it's a little far along in the
>> pretest to risk that.  I'll make a note of revisiting this after
>> the release.

> I think as long as this is guaranteed to only affect the NS port, we
> can still install it before the release (assuming tests indicate it
> does improve the behavior, and assuming we agree that it's the right
> way to fix it).

That introduces nesting in update_begin/end.  We should avoid such a
change at this stage.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #85 received at 2530 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
 Adrian Robert <adrian.b.robert <at> gmail.com>, Ian Eure <ian <at> digg.com>,
 Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Thu, 14 Jan 2016 00:08:27 -0500

There's a bunch of discussion before, in 2009, but as of now, for Emacs
25, I don't notice any particular slowness on El Capitan.  Can anyone
still reproduce a problem here?

David Reitter <david.reitter <at> gmail.com> writes:

> On May 5, 2009, at 10:13 AM, Chong Yidong wrote:
>
>> Could either your or David check in the nsterm.m fix, assuming no other
>> problems turn up with it?
>
> I will test it for a day or two, but check it in soon.
>
> I still think there are other places where the same technique would be
> beneficial, but they would be outside of ns*.m, albeit in #ifdefs.  From the
> sound of your messages, I take it we'll hold off on that.
>
> Getting back to Ian's original point: Overall, if we were to release now, I
> would consider the NS port "usable", but "experimental" rather than "stable".

Message #90 received at 2530 <at> debbugs.gnu.org (full text, mbox):

From: Alan J Third <alan <at> idiocy.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Ian Eure <ian <at> digg.com>,
 David Reitter <david.reitter <at> gmail.com>, Chong Yidong <cyd <at> stupidchicken.com>,
 Emacs-Devel devel <emacs-devel <at> gnu.org>,
 Adrian Robert <adrian.b.robert <at> gmail.com>
Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Thu, 14 Jan 2016 20:34:22 +0000

Andrew Hyatt <ahyatt <at> gmail.com> writes:

> There's a bunch of discussion before, in 2009, but as of now, for Emacs
> 25, I don't notice any particular slowness on El Capitan.  Can anyone
> still reproduce a problem here?
>
> David Reitter <david.reitter <at> gmail.com> writes:
>
>> On May 5, 2009, at 10:13 AM, Chong Yidong wrote:
>>
>>> Could either your or David check in the nsterm.m fix, assuming no other
>>> problems turn up with it?
>>
>> I will test it for a day or two, but check it in soon.
>>
>> I still think there are other places where the same technique would be
>> beneficial, but they would be outside of ns*.m, albeit in #ifdefs.  From the
>> sound of your messages, I take it we'll hold off on that.
>>
>> Getting back to Ian's original point: Overall, if we were to release now, I
>> would consider the NS port "usable", but "experimental" rather than "stable".

David Reitter has a number of open bug reports about redraw slowness on
OS X and I can't replicate any of the ones I've looked at. I don't know
if the display code's been rewritten or something?

-- 
Alan Third

Message #93 received at 2530 <at> debbugs.gnu.org (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Alan J Third <alan <at> idiocy.org>
Cc: 2530 <at> debbugs.gnu.org, Andrew Hyatt <ahyatt <at> gmail.com>,
 Chong Yidong <cyd <at> stupidchicken.com>, Ian Eure <ian <at> digg.com>,
 Emacs-Devel devel <emacs-devel <at> gnu.org>,
 Adrian Robert <adrian.b.robert <at> gmail.com>
Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Thu, 14 Jan 2016 16:00:35 -0500

> David Reitter has a number of open bug reports about redraw slowness on
> OS X and I can't replicate any of the ones I've looked at. I don't know
> if the display code's been rewritten or something?

Most of these are really very old.

Come to think of it, with the current codebase, I don’t recall seeing these NS port slownesses.

One thing worth testing would be the slowness that occurred with very long lines.  I apologize, but due to my schedule I can’t find the according bug report and try to reproduce.  

Message #96 received at 2530 <at> debbugs.gnu.org (full text, mbox):

From: Christian Kruse <cjk <at> defunct.ch>
To: Andrew Hyatt <ahyatt <at> gmail.com>, David Reitter <david.reitter <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
 Adrian Robert <adrian.b.robert <at> gmail.com>, Ian Eure <ian <at> digg.com>,
 Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Thu, 14 Jan 2016 22:39:20 +0100

[Message part 1 (text/plain, inline)]

Hi,

Andrew Hyatt <ahyatt <at> gmail.com> writes:

> There's a bunch of discussion before, in 2009, but as of now, for Emacs
> 25, I don't notice any particular slowness on El Capitan.  Can anyone
> still reproduce a problem here?

Compared to Linux (the Linux hardware is slower, a Notebook from 2011
and the OS X notebook is a Macbook Pro Retina from 2014), the OS X
version is *pretty* slow. While everything I do with Emacs is nearly
instant when using Linux there is a notably delay when using Emacs with
OS X. The worst example is Magit, which I already profiled because it is
*so* slow: when using Linux `magit-status` shows up instantly. It takes
about 1.5 seconds when using OS X (hold it, I am aware that this is not
the place to discuss Magit performance, it is just an example :-) Every
buffer with lots of lines (e.g. a notmuch buffer with 26k mails, my
archive of the pg-hackers list) is lightning fast when using Linux, but
takes round about 30 seconds when using OS X.

Although I’m not sure that it is only the rendering engine (of course it
could also be the elisp interpreter being slower) it occurs to me that
it plays its part: especially redraw actions seem to be very slow. For
example mu4e is unbearable slow when displaying maildirs with a lot of
mails (e.g. the 26k mails maildir I mentioned above) but works fine for
small mailboxes; and while the content of the maildir is loading, the
buffer is flickering all the time as if it gets redrawn all the time.

Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[signature.asc (application/pgp-signature, inline)]

Message #99 received at 2530 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christian Kruse <cjk <at> defunct.ch>
Cc: 2530 <at> debbugs.gnu.org, ahyatt <at> gmail.com, david.reitter <at> gmail.com,
 cyd <at> stupidchicken.com, ian <at> digg.com, emacs-devel <at> gnu.org,
 adrian.b.robert <at> gmail.com
Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Fri, 15 Jan 2016 09:38:29 +0200

> From: Christian Kruse <cjk <at> defunct.ch>
> Date: Thu, 14 Jan 2016 22:39:20 +0100
> Cc: 2530 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
> 	Adrian Robert <adrian.b.robert <at> gmail.com>,
> 	Ian Eure <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
> 
> Compared to Linux (the Linux hardware is slower, a Notebook from 2011
> and the OS X notebook is a Macbook Pro Retina from 2014), the OS X
> version is *pretty* slow. While everything I do with Emacs is nearly
> instant when using Linux there is a notably delay when using Emacs with
> OS X.

That's normal: GNU/Linux is significantly more efficient than other
modern OSes.  Nothing related to Emacs, really.

> The worst example is Magit, which I already profiled because it is
> *so* slow: when using Linux `magit-status` shows up instantly. It takes
> about 1.5 seconds when using OS X (hold it, I am aware that this is not
> the place to discuss Magit performance, it is just an example :-) Every
> buffer with lots of lines (e.g. a notmuch buffer with 26k mails, my
> archive of the pg-hackers list) is lightning fast when using Linux, but
> takes round about 30 seconds when using OS X.

Sounds like you describe a situation that is file I/O extensive.  If
so, again, there's little wonder you see much faster operation on
GNU/Linux.  If you'd say the same about comparison with MS-Windows,
say, then it would be something worth investigating.

> Although I’m not sure that it is only the rendering engine (of course it
> could also be the elisp interpreter being slower) it occurs to me that
> it plays its part: especially redraw actions seem to be very slow. For
> example mu4e is unbearable slow when displaying maildirs with a lot of
> mails (e.g. the 26k mails maildir I mentioned above) but works fine for
> small mailboxes; and while the content of the maildir is loading, the
> buffer is flickering all the time as if it gets redrawn all the time.

The flickering you describe can only be triggered by
platform-independent parts of the display engine, so again, this isn't
OS X or NS specific, AFAIU.

Emacs comes with a trace-redisplay command (compiled only if you
configure Emacs --enable-testing='yes,glyphs'), so if someone wants to
test the hypothesis that such flickering is specific to NS, they could
run the same scenario on OS X and on another system, after invoking
trace-redisplay, and compare the outputs.  I'd expect them to be
identical (except for the addresses it prints).

Message #102 received at 2530 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 2530 <at> debbugs.gnu.org, ian <at> digg.com, Christian Kruse <cjk <at> defunct.ch>,
 david.reitter <at> gmail.com, cyd <at> stupidchicken.com, emacs-devel <at> gnu.org,
 adrian.b.robert <at> gmail.com
Subject: Re: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Fri, 15 Jan 2016 23:15:58 -0500

It seems there is some agreement that there isn't a serious problem
anymore.  I'll close these bugs as doneunreproducible.  Flickerings or
slowness in elisp should probably be considered a different, separate bug.

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Christian Kruse <cjk <at> defunct.ch>
>> Date: Thu, 14 Jan 2016 22:39:20 +0100
>> Cc: 2530 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
>> 	Adrian Robert <adrian.b.robert <at> gmail.com>,
>> 	Ian Eure <ian <at> digg.com>, Emacs-Devel devel <emacs-devel <at> gnu.org>
>> 
>> Compared to Linux (the Linux hardware is slower, a Notebook from 2011
>> and the OS X notebook is a Macbook Pro Retina from 2014), the OS X
>> version is *pretty* slow. While everything I do with Emacs is nearly
>> instant when using Linux there is a notably delay when using Emacs with
>> OS X.
>
> That's normal: GNU/Linux is significantly more efficient than other
> modern OSes.  Nothing related to Emacs, really.
>
>> The worst example is Magit, which I already profiled because it is
>> *so* slow: when using Linux `magit-status` shows up instantly. It takes
>> about 1.5 seconds when using OS X (hold it, I am aware that this is not
>> the place to discuss Magit performance, it is just an example :-) Every
>> buffer with lots of lines (e.g. a notmuch buffer with 26k mails, my
>> archive of the pg-hackers list) is lightning fast when using Linux, but
>> takes round about 30 seconds when using OS X.
>
> Sounds like you describe a situation that is file I/O extensive.  If
> so, again, there's little wonder you see much faster operation on
> GNU/Linux.  If you'd say the same about comparison with MS-Windows,
> say, then it would be something worth investigating.
>
>> Although I’m not sure that it is only the rendering engine (of course it
>> could also be the elisp interpreter being slower) it occurs to me that
>> it plays its part: especially redraw actions seem to be very slow. For
>> example mu4e is unbearable slow when displaying maildirs with a lot of
>> mails (e.g. the 26k mails maildir I mentioned above) but works fine for
>> small mailboxes; and while the content of the maildir is loading, the
>> buffer is flickering all the time as if it gets redrawn all the time.
>
> The flickering you describe can only be triggered by
> platform-independent parts of the display engine, so again, this isn't
> OS X or NS specific, AFAIU.
>
> Emacs comes with a trace-redisplay command (compiled only if you
> configure Emacs --enable-testing='yes,glyphs'), so if someone wants to
> test the hypothesis that such flickering is specific to NS, they could
> run the same scenario on OS X and on another system, after invoking
> trace-redisplay, and compare the outputs.  I'd expect them to be
> identical (except for the addresses it prints).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.