* Re: 23/NS: redraws according to mouse-face are slow [not found] <BAF3A3D5-641B-45BA-9DA1-DC767D2D9ECE@gmail.com> @ 2009-04-20 18:01 ` David Reitter 2009-04-24 3:27 ` Adrian Robert 0 siblings, 1 reply; 20+ messages in thread From: David Reitter @ 2009-04-20 18:01 UTC (permalink / raw) To: Adrian Robert; +Cc: 2530, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-04-20 18:01 ` 23/NS: redraws according to mouse-face are slow David Reitter @ 2009-04-24 3:27 ` Adrian Robert 2009-05-04 22:55 ` David Reitter 0 siblings, 1 reply; 20+ messages in thread From: Adrian Robert @ 2009-04-24 3:27 UTC (permalink / raw) To: David Reitter; +Cc: 2530, Emacs-Devel devel 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 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 ` Chong Yidong 0 siblings, 2 replies; 20+ messages in thread From: David Reitter @ 2009-05-04 22:55 UTC (permalink / raw) To: Adrian Robert; +Cc: 2530, Ian Eure, Emacs-Devel devel [-- 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 --] ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-04 22:55 ` David Reitter @ 2009-05-04 23:24 ` Leo 2009-05-05 1:53 ` Chong Yidong 1 sibling, 0 replies; 20+ messages in thread From: Leo @ 2009-05-04 23:24 UTC (permalink / raw) To: emacs-devel On 2009-05-04 23:55 +0100, David Reitter wrote: > Moving the mouse a bit causes the whole mouse highlight to flicker. > I suspect that it's the same underlying problem. I think I reported something similar to this a long time ago when unicode2 branch was first merged. At that time I was using Emacs on GNU/Linux. > I wonder if we need to wrap more code in NSDisableScreenUpdates. -- .: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :. www.git-scm.com git - the one true version control system ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-04 22:55 ` David Reitter 2009-05-04 23:24 ` Leo @ 2009-05-05 1:53 ` Chong Yidong 2009-05-05 3:37 ` David Reitter 1 sibling, 1 reply; 20+ messages in thread From: Chong Yidong @ 2009-05-05 1:53 UTC (permalink / raw) To: David Reitter; +Cc: 2530, Ian Eure, Adrian Robert, Emacs-Devel devel 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-05 1:53 ` Chong Yidong @ 2009-05-05 3:37 ` David Reitter 2009-05-05 10:36 ` Adrian Robert 0 siblings, 1 reply; 20+ messages in thread From: David Reitter @ 2009-05-05 3:37 UTC (permalink / raw) To: Chong Yidong; +Cc: 2530, Ian Eure, Adrian Robert, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-05 3:37 ` David Reitter @ 2009-05-05 10:36 ` Adrian Robert 2009-05-05 14:13 ` Chong Yidong 2009-05-06 0:50 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 20+ messages in thread From: Adrian Robert @ 2009-05-05 10:36 UTC (permalink / raw) To: David Reitter; +Cc: 2530, Chong Yidong, Ian Eure, Emacs-Devel devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-05 10:36 ` Adrian Robert @ 2009-05-05 14:13 ` Chong Yidong 2009-05-05 17:32 ` David Reitter 2009-05-06 1:47 ` Stefan Monnier 2009-05-06 0:50 ` YAMAMOTO Mitsuharu 1 sibling, 2 replies; 20+ messages in thread From: Chong Yidong @ 2009-05-05 14:13 UTC (permalink / raw) To: Adrian Robert; +Cc: 2530, David Reitter, Ian Eure 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-05 14:13 ` Chong Yidong @ 2009-05-05 17:32 ` David Reitter 2016-01-14 5:08 ` bug#2530: " Andrew Hyatt 2009-05-06 1:47 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: David Reitter @ 2009-05-05 17:32 UTC (permalink / raw) To: Chong Yidong; +Cc: 2530, \ Ian Eure, Adrian Robert, Emacs-Devel devel 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". ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: bug#2530: 23/NS: redraws according to mouse-face are slow 2009-05-05 17:32 ` David Reitter @ 2016-01-14 5:08 ` Andrew Hyatt 2016-01-14 20:34 ` Alan J Third 2016-01-14 21:39 ` Christian Kruse 0 siblings, 2 replies; 20+ messages in thread From: Andrew Hyatt @ 2016-01-14 5:08 UTC (permalink / raw) To: David Reitter Cc: 2530, Chong Yidong, Adrian Robert, Ian Eure, Emacs-Devel devel 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". ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#2530: 23/NS: redraws according to mouse-face are slow 2016-01-14 5:08 ` bug#2530: " Andrew Hyatt @ 2016-01-14 20:34 ` Alan J Third 2016-01-14 21:00 ` David Reitter 2016-01-14 21:39 ` Christian Kruse 1 sibling, 1 reply; 20+ messages in thread From: Alan J Third @ 2016-01-14 20:34 UTC (permalink / raw) To: Andrew Hyatt Cc: 2530, Ian Eure, David Reitter, Chong Yidong, Emacs-Devel devel, Adrian Robert 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: bug#2530: 23/NS: redraws according to mouse-face are slow 2016-01-14 20:34 ` Alan J Third @ 2016-01-14 21:00 ` David Reitter 0 siblings, 0 replies; 20+ messages in thread From: David Reitter @ 2016-01-14 21:00 UTC (permalink / raw) To: Alan J Third Cc: 2530, Andrew Hyatt, Chong Yidong, Ian Eure, Emacs-Devel devel, Adrian Robert > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: bug#2530: 23/NS: redraws according to mouse-face are slow 2016-01-14 5:08 ` bug#2530: " Andrew Hyatt 2016-01-14 20:34 ` Alan J Third @ 2016-01-14 21:39 ` Christian Kruse 2016-01-15 7:38 ` Eli Zaretskii 1 sibling, 1 reply; 20+ messages in thread From: Christian Kruse @ 2016-01-14 21:39 UTC (permalink / raw) To: Andrew Hyatt, David Reitter Cc: 2530, Chong Yidong, Adrian Robert, Ian Eure, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: bug#2530: 23/NS: redraws according to mouse-face are slow 2016-01-14 21:39 ` Christian Kruse @ 2016-01-15 7:38 ` Eli Zaretskii 2016-01-16 4:15 ` Andrew Hyatt 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2016-01-15 7:38 UTC (permalink / raw) To: Christian Kruse Cc: 2530, ahyatt, david.reitter, cyd, ian, emacs-devel, adrian.b.robert > 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). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: bug#2530: 23/NS: redraws according to mouse-face are slow 2016-01-15 7:38 ` Eli Zaretskii @ 2016-01-16 4:15 ` Andrew Hyatt 0 siblings, 0 replies; 20+ messages in thread From: Andrew Hyatt @ 2016-01-16 4:15 UTC (permalink / raw) To: Eli Zaretskii Cc: 2530, ian, Christian Kruse, david.reitter, cyd, emacs-devel, adrian.b.robert 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). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-05 14:13 ` Chong Yidong 2009-05-05 17:32 ` David Reitter @ 2009-05-06 1:47 ` Stefan Monnier 2009-05-06 7:40 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2009-05-06 1:47 UTC (permalink / raw) To: Chong Yidong Cc: 2530, David Reitter, Ian Eure, Adrian Robert, Emacs-Devel devel >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-06 1:47 ` Stefan Monnier @ 2009-05-06 7:40 ` YAMAMOTO Mitsuharu 0 siblings, 0 replies; 20+ messages in thread From: YAMAMOTO Mitsuharu @ 2009-05-06 7:40 UTC (permalink / raw) To: Stefan Monnier Cc: 2530, Ian Eure, David Reitter, Chong Yidong, Emacs-Devel devel, Adrian Robert >>>>> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-05 10:36 ` Adrian Robert 2009-05-05 14:13 ` Chong Yidong @ 2009-05-06 0:50 ` YAMAMOTO Mitsuharu 2009-05-06 1:55 ` Adrian Robert 1 sibling, 1 reply; 20+ messages in thread From: YAMAMOTO Mitsuharu @ 2009-05-06 0:50 UTC (permalink / raw) To: Adrian Robert Cc: 2530, David Reitter, Chong Yidong, Ian Eure, Emacs-Devel devel >>>>> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-06 0:50 ` YAMAMOTO Mitsuharu @ 2009-05-06 1:55 ` Adrian Robert 2009-05-06 2:25 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 20+ messages in thread From: Adrian Robert @ 2009-05-06 1:55 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: 2530, David Reitter, Chong Yidong, Emacs-Devel devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 23/NS: redraws according to mouse-face are slow 2009-05-06 1:55 ` Adrian Robert @ 2009-05-06 2:25 ` YAMAMOTO Mitsuharu 0 siblings, 0 replies; 20+ messages in thread From: YAMAMOTO Mitsuharu @ 2009-05-06 2:25 UTC (permalink / raw) To: Adrian Robert; +Cc: 2530, David Reitter, Chong Yidong, Emacs-Devel devel >>>>> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-01-16 4:15 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <BAF3A3D5-641B-45BA-9DA1-DC767D2D9ECE@gmail.com> 2009-04-20 18:01 ` 23/NS: redraws according to mouse-face are slow 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 ` Chong Yidong 2009-05-05 3:37 ` David Reitter 2009-05-05 10:36 ` Adrian Robert 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 20:34 ` Alan J Third 2016-01-14 21:00 ` David Reitter 2016-01-14 21:39 ` Christian Kruse 2016-01-15 7:38 ` Eli Zaretskii 2016-01-16 4:15 ` Andrew Hyatt 2009-05-06 1:47 ` Stefan Monnier 2009-05-06 7:40 ` YAMAMOTO Mitsuharu 2009-05-06 0:50 ` YAMAMOTO Mitsuharu 2009-05-06 1:55 ` Adrian Robert 2009-05-06 2:25 ` YAMAMOTO Mitsuharu
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).