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

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

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.



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

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

[Adrian Robert]

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

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

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

[Adrian Robert]

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?

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

[David Reitter]

[-- 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 --]

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

[Chong Yidong]

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?

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

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

[Adrian Robert]

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

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

[Chong Yidong]

Adrian Robert <adrian.b.robert@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?

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

[David Reitter]

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

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert <adrian.b.robert@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@math.s.chib-u.ac.jp

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

[Stefan Monnier]

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

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

[Adrian Robert]

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

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 6 May 2009 08:55:36 +0700, Adrian Robert <adrian.b.robert@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@math.s.chiba-u.ac.jp

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 05 May 2009 21:47:04 -0400, Stefan Monnier <monnier@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@math.s.chiba-u.ac.jp

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

[Andrew Hyatt]

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

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

[Alan J Third]

Andrew Hyatt <ahyatt@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@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

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

[David Reitter]

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

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

[Christian Kruse]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

Hi,

Andrew Hyatt <ahyatt@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Eli Zaretskii]

> From: Christian Kruse <cjk@defunct.ch>
> Date: Thu, 14 Jan 2016 22:39:20 +0100
> Cc: 2530@debbugs.gnu.org, Chong Yidong <cyd@stupidchicken.com>,
> 	Adrian Robert <adrian.b.robert@gmail.com>,
> 	Ian Eure <ian@digg.com>, Emacs-Devel devel <emacs-devel@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).

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

[Andrew Hyatt]

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@gnu.org> writes:

>> From: Christian Kruse <cjk@defunct.ch>
>> Date: Thu, 14 Jan 2016 22:39:20 +0100
>> Cc: 2530@debbugs.gnu.org, Chong Yidong <cyd@stupidchicken.com>,
>> 	Adrian Robert <adrian.b.robert@gmail.com>,
>> 	Ian Eure <ian@digg.com>, Emacs-Devel devel <emacs-devel@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).