Community
Participate
Working Groups
Scrolling any text / source file in the eclipse main text editor is sluggish on Mac OS X (tested on 10.7.2 Lion) in comparison to Windows or Linux. The speed of the scrolling is worse the larger the text editor's area is; with a small area (~200x200 pixels) the scrolling is smooth. In addition, enabling "show whitespace characters" will dramatically slow down the scrolling. This does not appear to be hardware related, as eclipse will scroll smoothly in a Windows virtual machine. My best guess is this issue is caused by slow repainting.
*** Bug 366473 has been marked as a duplicate of this bug. ***
I have the same problem and always have with Eclipse, through different OS X and Eclipse versions. I've always wondered why this isn't reported more. Is it hardware related, something that isn't accelerated on this video board, for example? MacBook Pro 2.4 GHz Intel Core Duo, 4GB SDRAM, NVIDIA GeForce 8600M GT 256 MB Mac OS X Lion 10.7.2 (11C74) Eclipse Version: Indigo Service Release 1 Build id: 20110916-0149
Silenio, Lakshimi Is your Mac OS X slow for scrolling ?
I am also seeing slow scrolling on a custom control also based on Canvas. This seems to be due to Canvas.isObscured() always returning true which causes the control to redraw.
Seeing the exact same issue here on OS X 10.7.3 with an external 30" screen. As others have mentioned in various eclipse forums, the issue basically disappears when I turn off "Show whitespace characters".
I tried this on OSX 10.7.3 with "show whitespace characters" enabled, but I'm unable reproduce the slow scrolling behavior.
How are you scrolling? For me, mouse wheel/two finger trackpad scrolling work fine. The problem occurs when trying to move through the file with the keyboard using the arrow keys.
(In reply to comment #7) > How are you scrolling? For me, mouse wheel/two finger trackpad scrolling work > fine. The problem occurs when trying to move through the file with the > keyboard using the arrow keys. I was scrolling with trackpad and it worked fine. When I try to scroll using the arrow keys with "show whitespace characters" enabled, I can see the editor's slow scrolling problem. Out of curiosity, I tried XCode editor, and it scrolls very slowly when using the keys. TextEdit seems to scroll better.
I am also experiencing this issue and enabling "Show Whitespace Characters" makes it even much worse. I've been using Eclipse ever since from 10.7.1 to current 10.8.0 and slow scrolling was present on every Lion / Mountain Lion version I had. The behaviour seems to be much better when System Preferences -> General -> Show scroll bars is set to "Always".
I too have the exact same problem and the trick with always showing the scrollbars works just fine for me on my OSX Lion 10.7.4. Shame though as I like the clean no scrollbars look ;( Thanx Peter Misak for pointing this out!
(In reply to comment #10) > I too have the exact same problem and the trick with always showing the > scrollbars works just fine for me on my OSX Lion 10.7.4. Shame though as I > like the clean no scrollbars look ;( > > Thanx Peter Misak for pointing this out! Forgot to mention I have this problem on both version 3.8 and the new 4.2.
I'm experiencing the same issue with Eclipse 3.8.0 and Eclipse 4.2. In fact I signed up only to report this issue. I'm describing the issue below. Let me know if you need logs or something. OS: Mac OS X 10.7.4 Hardware: 2.3 GHz i5, 4GB RAM Eclipse: 3.8.0 I20120608-1200 STEPS: - Fresh install Eclipse - Create 2-3 page long JAVA file - Open the file in Eclipse JDT Editor - Open same file in TextEdit (Mac's Text Editor) - Scroll both editors side by side OBSERVATIONS: - TextEdit scrolls smooth, like 60fps - Eclipse scroll is choppy, like 15 fps DETAILS: Eclipse editor scroll is choppy in Mac. It's not slow by any means, but it shatters, like the viewport is trying to align itself to lines or something. Like instead of scrolling 1 pixel at a time, viewport is scrolling 5 pixels at a time, in bursts. Like it's scrolling at 15 fps. IMPORTANCE: It's not a deal breaker, but it puts a lot of strain on eyes.
(In reply to comment #12) You are seeing the problem when scrolling with mouse, trackpad or arrow keys? From comment#7, the problem happens only when scrolling with arrow keys.
(in reply to comment #13) I also created this account for this issue. I see very poor scrolling performance both when scrolling via the mouse and by scrolling using arrow keys. I used a large java file that I opened both in Sublime2 editor (w/ java syntax highlighting) and in eclipse. I'd say that the 60fps vs. 15fps performance noted in comment #12 is consistent with what I'm seeing as well. My specs are a little different from comment #12 however: OS: Mac OS X 10.8.1 (Mountain Lion) Hardware: 2.8 GHz i5, 8GB RAM Eclipse: 3.8.0 I20120608-1400 (Eclipse.org JDT feature)
(In reply to comment #13) > (In reply to comment #12) > You are seeing the problem when scrolling with mouse, trackpad or arrow > keys? From comment#7, the problem happens only when scrolling with arrow > keys. I'm using Macbook Pro 13 2011. I'm experiencing the issue with Touchpad, haven't tried a mouse. Arrow keys also have almost the same (slow) scrolling speed, but the problem is less visible, because arrow keys are 'supposed' to scroll the editor 'line-by-line' and thats what happens. The problem is more evident when scrolling through touchpad. In other Lion apps, Touchpad scrolls the viewport like it's scrolling through a long pre rendered canvas. In Eclipse, it scrolls like it's trying to draw one line at a time on screen. Turning persistent scrollbars on or off does not make a huge difference. I'll try to make a video demonstrating the effect.
(In reply to comment #4) > I am also seeing slow scrolling on a custom control also based on Canvas. > This seems to be due to Canvas.isObscured() always returning true which > causes the control to redraw. I believe isObscured() always return true because of the overlay scroll bars. Does performance get better if the System Preferences for "Show scroll bars" is set to "Always"?
Just FYI: I've tried enabling setting the "Show scroll bars:" option to "Always" in the System Preferences > General. This does not appear to have any effect on performance; the scrolling is still relatively sluggish.
I've experienced the same issue - extremely slow scrolling of structured (Java and XML) editors. This is on Indigo (build 20120216-1857) and Juno on a new iCore 7 machine, 8GB ram and SSD, OSX 10.8.2, regardless of JDK 1.6 or 1.7. A few observations. 1. The slow-down is proportional to the size of the display. The bigger the display, the worse it is. eg: I almost never notice it on a built-in 11" display. On an external 24" display it is very frustrating. On a 30" display it's so painful Eclipse is unusable. 2. Changing startup memory sizes etc (the usual eclipse optimizations) has no effect. 3. Disabling the display of "show whitespace characters" the problem goes away! ie: Eclipse > Preferences > General > Editors > Text Editors > Show whitespace characters (turn this off). 4. For ultimate speed, also turn off "Show line numbers" and "Show print margin". I haven't looked at the code, but any (and all of) these options have a noticeable impact on scrolling performance.
This is still an issue with Juno and Kepler. Scrolling is horribly CPU intensive, and slow as described. On my Air 2011 i7, scrolling a two pages long PHP file uses about 70% CPU according to Activity Monitor. It's only the text editor that exhibits this issue (other GUI lists/trees are super fast when scrolling). It's like it's redrawing its entire contents with every little bit of scrolling it does, rather than just move the (supposedly already rendered) canvas inside the viewport. Comparing with other editors such as Sublime Text 2 is depressing, because the scrolling there is soooo smooth. Eclipse scrolling looks like I'm using a ten year old machine in comparison. As noted, turning off visible whitespace helps quite a bit. Turning on persistent scroll bars also helps. The problem is much worse when the file being edited is also wider than the editor can display, especially when you're scrolling with the touchpad, because it then scrolls both horizontally and vertically at the same time. Hiding gui elements to make the content fit horizontally and making the horizontal scroll bar disappear helps a lot. The CPU usage remains the same, though, which to me definitely indicates a serious problem somewhere. An option to turn off horizontal scrolling with anything but the keyboard would be helpful, as would adding a soft word wrap feature so that we could control the width of the code in text editors.
*** Bug 399557 has been marked as a duplicate of this bug. ***
This is still an issue in 4.3. I cannot upgrade Eclipse from 3.4 unless this is fixed. Its *so* bad as it would make my development abilities suffer greatly. Can't anyone fix the scrolling in the editor? 3.4 wasn't perfect in scrolling abilities, but its lightning fast compared to every version after it. Over 3 years now on this bug and related ones. BUG 321020 BUG 387258 Those are the same as this one essentially. 2010/07/27 is the current oldest open bug as developers keep closing these bugs as they consider them fixed on their tiny 13" laptop screens. Its *NOT* fixed, and its the only editor in modern OS X that sucks like this. There have been bugs reported since 3.5 was released dealign with this issue and its never been fixed. --Ben
It is slow on my large screen and extremely annoying.
*** Bug 387258 has been marked as a duplicate of this bug. ***
Confirmed. It's still an issue with Eclipse 4.3 on Mac Lion.
After installing Oracle JDK 1.7.0_40, the problem seems better compared to original apple JDK6
I have also noticed and improvement, could be an apple update or the new JDK.
Any developers with a large monitor? Performance does actually seem a little better...but still not really useable on a large monitor. Dell 30" monitor, 1600x2560 resolution...so a lot of visible code being scrolled. Inertial scrolling is horrible. You can swipe back and forth a few times, then sit back and watch the movie of your code scrolling slowly back and forth until it catches up. The older eclipse is still lightning fast. A 10 out of 10. The new eclipse is a 5/10 which is better than a 2/10 which is what i would have rated them at before. But I still really can't use it unless there was no other choice. Performance hasn't improved enough for real usage. Windows is fine, just an OSX/Eclipse issue. --Ben
Seeing this, too, still on Kepler. 2010 MacBook Pro. External 27" screen, 2560x1440. It gets noticeably better with scrollbars always enabled, and again with whitespace characters off. But as others have described, this is not enough to make it comparable to most any other editor. On the smaller laptop screen it is bearable though still not great. However, the whole point of the giant screen is to use it for development :)
I have the same problem. OSX 10.9, rMBP 13', i7 2.9 Ghz Ivy Bridge, 8G Eclipse 4.3.1 Scrolling is very very slow (~12fps). Like others said it is proportional to the screen area. Resizing the window to a small size makes the scrolling reasonably fast. Which kind of is the symptom of re-rendering the whole window every time.
Using a late 2013 MBP Retina i7, scrolling is a tiny bit laggy without show whitespace on, but as soon as you turn it on it is extremely annoying. This is with Kepler SP1, Java 7, and a Java editor on an external 27" 2560x1440 screen. Can someone update this ticket to indicate it applies to the current version of Eclipse? I'm worried this is falling off the radar, but is a very real problem. I should be able to get buttery smooth scrolling along with showing whitespace and anything else I'd like in there.. this is just text after all.
I have the same problem. MacBook Pro Mid 2009 (Core 2, 2,26 GHz, 8 GB RAM, Intel x25-m SSD with plenty of free space). Fully updated OS X Mavericks. When scrolling in eclipse while maximized (1280x720) top reports >80% CPU usage. The scrolling is slow and renders in approx. 10 fps. While on my external 27" monitor (2560x1440) CPU usage spikes above 80% but with ~2-5 fps. Eclipse Standard/SDK Version: Kepler Service Release 1 Build id: 20130919-0819 Scrolling in other applications (browsers, text editors, finder, etc) works butter-smooth. Some info from top: Processes: 220 total, 2 running, 2 stuck, 216 sleeping, 1126 threads 11:04:58 Load Avg: 2.70, 2.65, 3.08 CPU usage: 10.44% user, 12.85% sys, 76.70% idle PhysMem: 8051M used (1157M wired), 26M unused. VM: 492G vsize, 1026M framework vsize, 0(0) swapins, 0(0) swapouts. PID COMMAND %CPU TIME #TH #WQ #POR #MREG MEM RPRVT PURG CMPRS VPRVT VSIZE 838 eclipse 1.6 02:46:39 50 1 967 2430 612M 592M 0B 4036K 1214M 4726M 1.6% CPU usage when idle and minimized... The two processes stuck is, as always, "Spotify Helper"
The CPU usage raise up to 76% while scrolling and the UI lose responsiveness. Eclipse : Version: Kepler Service Release 1 Build id: 20130919-0819 Mac: MacBook Pro 15-inch, Late 2011 Processor 2.4 GHz Intel Core i7 Memory 16 GB 1333 MHz DDR3 Graphics AMD Radeon HD 6770M 1024 MB Software OS X 10.9.2 (13C64) Resolution: 1920 x 1200 @ 60 Hz
Same issue for me on the Android ADT. I am using a mid-2012 MacBook air. specs: -core i5 (1.8ghz) -8gb ram. This is literally the ONLY application on the entire computer that feels like it was written in 1999. I have tried all the suggestions mentioned before, and the issue persists. I am using a magic mouse...god forbid I turn on the "show whitespace" option lol. When I turn that on it feels like I have a pentium D processor powering my mac. :P Placing a vote now, and as someone else mentioned, this is text. This should not be a problem. Especially on a $1000 machine that is only 2 years old. There is some horribly inefficient code somewhere for sure.
The people with the skills to fix this issue do their testing on a small screen and are satisfied with the performance, so the bug just goes ignored for 4+ years. Eclipse 3.4.2 is the last version before this issue became a problem. Every release after this has been horrific. The latest ones have improved slightly from the prior horrific ones, but coding in java in Eclipse 3.5 and above on OSX is not feasible from my experience. It would be 100x faster to run a windows VM with shared drive access to your source code, and use a "unity" mode to have a faster OSX app that is begin emulated... There is no other solution. Same bug as Bug 321020. OSX 10.9.2, iMac i7 quad core 2.93Ghz, 12GB RAM, and new Eclipse gets *maybe* 5 to 10 FPS. --Ben
Nice specs! I personally think the only place eclipse MIGHT run lag free (for 20+ inch screens) is one the new mac pro that's designed to power like three 4k displays lol. Even then i'm not so sure! haha (In reply to Ben Spink from comment #34) > The people with the skills to fix this issue do their testing on a small > screen and are satisfied with the performance, so the bug just goes ignored > for 4+ years. > > Eclipse 3.4.2 is the last version before this issue became a problem. Every > release after this has been horrific. The latest ones have improved > slightly from the prior horrific ones, but coding in java in Eclipse 3.5 and > above on OSX is not feasible from my experience. It would be 100x faster to > run a windows VM with shared drive access to your source code, and use a > "unity" mode to have a faster OSX app that is begin emulated... > > There is no other solution. > > Same bug as Bug 321020. > > OSX 10.9.2, iMac i7 quad core 2.93Ghz, 12GB RAM, and new Eclipse gets > *maybe* 5 to 10 FPS. > > --Ben
FYI editor rendering speed increased *dramatically* for me when I started using Microsoft's Consolas font. Macbook Air on Mavericks with 27inch monitor.
This didn't work for me. Macbook Pro Retina on Mavericks. (In reply to Nelson Rodrigues from comment #36) > FYI editor rendering speed increased *dramatically* for me when I started > using Microsoft's Consolas font. > > Macbook Air on Mavericks with 27inch monitor.
I used the Menlo Font as such: "Preferences>General>Appearance>Color and Fonts>Java Editor Text Font" together with changing the Scrollbar to always visible. This definitely made it faster but still not as fast as it should be for me. (In reply to Jeremias Volker from comment #37) > This didn't work for me. > > Macbook Pro Retina on Mavericks. > > (In reply to Nelson Rodrigues from comment #36) > > FYI editor rendering speed increased *dramatically* for me when I started > > using Microsoft's Consolas font. > > > > Macbook Air on Mavericks with 27inch monitor.
Changing the scrollbar to always visible made it faster. But changing the font didn't work for me. > This definitely made it faster but still not as fast as it should be for me. Yes, if I compare the result to Sublime for example, there is definitely a difference. (In reply to Wayne Forrest from comment #38) > I used the Menlo Font as such: > > "Preferences>General>Appearance>Color and Fonts>Java Editor Text Font" > > together with changing the Scrollbar to always visible. > This definitely made it faster but still not as fast as it should be for me. > > > > (In reply to Jeremias Volker from comment #37) > > This didn't work for me. > > > > Macbook Pro Retina on Mavericks. > > > > (In reply to Nelson Rodrigues from comment #36) > > > FYI editor rendering speed increased *dramatically* for me when I started > > > using Microsoft's Consolas font. > > > > > > Macbook Air on Mavericks with 27inch monitor.
If you are using eclipse with 27" screen (2560x1440), you have to disable whitespace characters rendering. Each character (space, tab, newline, ...) is rendered separately. See bug 434194
*** Bug 438772 has been marked as a duplicate of this bug. ***
Hi folks, I've been following this post since... well, a long time. Just found out that turning off the option NSHighResolutionCapable in the Info.plist app file will turn it usable BUT fonts will look like they are being drawn by a 3 yo kid... Anyway, just edit $PATH_TO_ECLIPSE/Eclipse.app/Info.plist and add the following lines inside <dict> <key>NSHighResolutionCapable</key> <true/> Than drag the Eclipse.app to another folder (Desktop for example) and move it back to it's original folder. This is necessary due to the OSX's cache with plists files. Et voi lá, ugly but functional.
Sorry, made a mistake. To turn it off the tag should be <false/> <key>NSHighResolutionCapable</key> <false/> (In reply to Ulysses Bonfim from comment #42) > Hi folks, > I've been following this post since... well, a long time. > > Just found out that turning off the option NSHighResolutionCapable in the > Info.plist app file will turn it usable BUT fonts will look like they are > being drawn by a 3 yo kid... > > Anyway, just edit $PATH_TO_ECLIPSE/Eclipse.app/Info.plist > and add the following lines inside <dict> > <key>NSHighResolutionCapable</key> > > <true/> > > Than drag the Eclipse.app to another folder (Desktop for example) and move > it back to it's original folder. This is necessary due to the OSX's cache > with plists files. > > Et voi lá, ugly but functional.
Created attachment 246821 [details] UI thread stack while scrolling
In Linux Mint 13 the scrolling is slow only when using the mouse wheel and only on file editor (other tabs scrolls ok). The inertial scrolling keep going up and down several seconds after making some fast up-down scrolls. Moreover inertial scrolling would be a bad thing also if it was working correctly: it should be allowed to switch it on/off in preferences.
There's an open bug for it on JDK https://bugs.openjdk.java.net/browse/JDK-8029253
I am not sure it's the same ticket, I see this problem and I *don't* have a Retina display.
Likewise. I *don't* have a retina display, but on a large screen eclipse is unusable. Other IDEs work fine on the same Java Platform.
Eclipse 3.4 is still fine, even on a vertical 4K monitor. Scrolling is snappy, some minor lag, but nothing that gets in the way of working or quick scroll actions, etc. Even keyboard repeat scrolling up or down is smooth and fluid on fastest key repeat rate. Resolution: 2160x3840 244 visible lines of code, 292 horizontal characters. All newer versions of eclipse are impossible to use beyond a small screen. Its been this way for years, across 3 computers now (i7 Macbook pro, 17", hires, 27" iMac i7 2.93, and now MacPro). I am stuck on the old eclipse because there is no fix. Max of 5 FPS or so...or less. Going on 4 years now with this bug...
Please try this, 1) Set the Eclipse Java editor font to use Menlo as the Font (General->Appearance->Color and Fonts->Java.../Java Editor Text 2) Set OSX scrolling to show always (System Preferences->General : Show Scroll Bars Always). This seems to work for me using on Luna Release (4.4.0) Rgds. Wayne. (In reply to Ben Spink from comment #49) > Eclipse 3.4 is still fine, even on a vertical 4K monitor. Scrolling is > snappy, some minor lag, but nothing that gets in the way of working or quick > scroll actions, etc. Even keyboard repeat scrolling up or down is smooth > and fluid on fastest key repeat rate. > > Resolution: 2160x3840 > > 244 visible lines of code, 292 horizontal characters. > > All newer versions of eclipse are impossible to use beyond a small screen. > Its been this way for years, across 3 computers now (i7 Macbook pro, 17", > hires, 27" iMac i7 2.93, and now MacPro). I am stuck on the old eclipse > because there is no fix. Max of 5 FPS or so...or less. > > Going on 4 years now with this bug...
Can you compare your speed with the older Eclipse? You never indicated your vertical visible lines, or screen resolution at all, or other real speeds. You just said "works for me". But you may be perfectly happy with 10FPS or poor performance compared to the rest of us. Compare carbon eclipse versus your current one, and use the fastest key repeat rate and maximize a large class window and try it out. Maybe you'll realize how slow yours is... ------------------ Resolution: 2160x3840 4K 244 visible lines of code, 292 horizontal characters. I used eclipse carbon 3.4. 1292 line file, fastest key repeat rate. Starting from top of file and Cocoa eclipse 4.4 downloaded today. -------------------------------------------- Carbon: 58 seconds, 1292 lines. 22.3 lines per second Cocoa: 58 seconds, 488 lines scrolled...I gave up. 3.6 lines per second After your suggested changes from the defaults: Carbon: 58 seconds, 1292 lines. 22.3 lines per second Cocoa: 58 seconds, 805 lines scrolled, I gave up, too slow. 13.9 lines per second Xcode: 65 seconds, 1292 lines scrolled. 19.8 lines per second. -------------------------------------------- So yes, a different font helps some, it doesn't fix the issue, and is still extremely slow. What these measurements don't quantify though is usability. There is a minimum frame rate that is needed to make scrolling work and allow your eyes to track the text that is moving. 22.3 is workable, although still slow in my opinion. 13.9 is definitely not. but suing a track pace or scroll wheel and inertia, you *need* fluidity in the scrolling and a high frame rate. Without it, developing is painful. So the issue remains. Cocoa eclipse is still slow. --Ben
I spent some time on analyzing this issue. Three classes slowing down scrolling performance on mac: 1. org.eclipse.jface.text.WhiteSpaceCharacterPainter (disable showing whitespace) 2. org.eclipse.ui.internal.texteditor.LineNumberRulerColumn (disable line numbers in editor) 3. org.eclipse.jface.text.source.AnnotationRulerColumn First and second use swt GC.drawString many times (on cococa and gtk this method call directly GC.drawText), which is very slow, due three calls: * NSLayoutManager.glyphRangeForTextContainer * GC.createString * NSLayoutManager.drawGlyphsForGlyphRange. Maybe it's another way to paint, cache and scroll these elements? Last, AnnotationRulerColumn, on mac always call redraw() and update(). This code was introduced 4 years ago due performance problems ;), bug 298936. I disabled AnnotationRulerColumn.redraw mac hack on my test environment, and scrolling become faster (lower CPU utilization). Summary per class: 1. Bug 434194 is reported 2. More lines => slower scroll 3. Maybe hack is no longer required for current SWT/e4 My test environment: * Eclipse 4.4.1 * Java 1.7_60 * OSX Yosemite PB3 (modified MBP 17" 2011) * screen 2560 x 1440 I hope it help.
Please fix this. This issue is real.
Yes, please, fix this bug. It really impacts battery life and usability.
OSX 10.9.5 ADT/Eclipse 4.2 As the above - slow as all hell, faster when window is smaller, faster when scroll bar is set to always show, slower when show whitespace is enabled. Please fix, it's one of the more impactful eclipse bugs :c
(In reply to Dawid Pakula from comment #52) > 3. org.eclipse.jface.text.source.AnnotationRulerColumn [..] > Last, AnnotationRulerColumn, on mac always call redraw() and update(). This > code was introduced 4 years ago due performance problems ;), bug 298936. I > disabled AnnotationRulerColumn.redraw mac hack on my test environment, and > scrolling become faster (lower CPU utilization). I've fixed bug 447983, consolidated the 5 IS_MAC fields into VerticalRuler.IS_MAC_BUG_298936, and then ran the org.eclipse.jdt.text.tests.performance.ScrollAnnotatedJavaEditorTest#testScrollJavaEditorLineWise1() test. Old MacBook Pro master: 1.63m Old MacBook Pro with IS_MAC_BUG_298936 set to false: 2.75m Fast Windows machine: 4.12s => Mac-specific code is still faster for me (though still way too slow...). Dawid, what exactly did you change in AnnotationRulerColumn? If you just remove the call to fCanvas.redraw(), then it's only faster because it stops redrawing the ruler. As in bug 298936, removing fCanvas.update() didn't improve speed for me.
(In reply to Markus Keller from comment #56) > Dawid, what exactly did you change in AnnotationRulerColumn? If you just > remove the call to fCanvas.redraw(), then it's only faster because it stops > redrawing the ruler. As in bug 298936, removing fCanvas.update() didn't > improve speed for me. I hardcoded IS_MAC field to false
This is so hopeless. We've already moved our teams to Idea and Sublime. Hope this gets fixed after all.
Maybe this will help: If I modify org.eclipse.swt.widgets.Composite::createHandle() and add in line 292 "scrollWidget.setAutohidesScrollers (true);" scrolling become truly fast (whitespace rendering is disabled) but scrollbars are not visible.
I installed a new Java 6 update for OS X last night; This could improve things a bit. http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US
No Difference, other than fixing the install issue for Android Studio/IntelliJ. (Android Studio/InteliJ has no lag).
On a 4k monitor this issue grows to the extend, that using the editor is a pain. On a top specced Macbook pro 15" late 2014. I love the screen realestate, but the lagging scrolling and delay in updating the editor window when typing makes me want to switch to another IDE.
MacBook Pro 2.7GHz 16GB RAM Mavericks 10.9.5 with brand new Apple Thunderbolt Display 27" 2560x1440 pixels and Eclipse Java EE Luna release 4.4.0 Build 20140612-0600, Java 7 1.7.0_67 Scrolling is not great, but doable. Working with JSPs causes Eclipse to show useless spinning beachball and spiking CPU well over 100%. Totally useless. I've been working with Eclipse for over 10 years and this is killing all of my productivity. Any and all ideas welcome. Thx -Rob
(In reply to Rob Mitchell from comment #64) > MacBook Pro 2.7GHz 16GB RAM Mavericks 10.9.5 with brand new Apple > Thunderbolt Display 27" 2560x1440 pixels and Eclipse Java EE Luna release > 4.4.0 Build 20140612-0600, Java 7 1.7.0_67 > > Scrolling is not great, but doable. > > Working with JSPs causes Eclipse to show useless spinning beachball and > spiking CPU well over 100%. Totally useless. > > I've been working with Eclipse for over 10 years and this is killing all of > my productivity. > > Any and all ideas welcome. > > Thx > -Rob I think the best we can do is vote for this bug and also get others to vote.
My eclipse is getting slow on scrolling also when I have "Show Whitespace characters" enabled. If I disable it, it becomes quicker, but I think it goes slower than other apps even with little files. Hope you can improve this. This issue it's really annoying when you are working because it slows down your working progress. Android Studio it's incredibly fast when scrolling. I can use it for Android Development (only Java, I think native is not fully or easy supported right now), but I use Eclipse with Aptana for Web development also so I would like it to be as quick as other IDEs if possible. Thanks to all to improve such great IDE. My MAC specs: OS X Yosemite (10.10.1) MacBook Pro (Retina, 15-inch, Early 2013) Processor 2,7 GHz Intel Core i7 16 GB 1600 MHz DDR3 NVIDIA GeForce GT 650M 1024 MB
Look at the date, people. Nothing's gonna happen. I've been using Sublime as a replacement for two years now, Eclipse is dead for the Mac. Get with it :)
Well, i've been using Eclipse for main stream Java web development for years with very, very few problems until recently. For developing and debugging Java apps, its great. Not sure you can debug step-by-step with Sublime.
Very true. Sublime is missing a lot of features, that including. I still use Eclipse (and Eclipse-based variants) for debugging, but not for development anymore.
I gave up on this being fixed over a year ago. After using Eclipse since version 1.0, it was pretty sad to change. However life now with IntelliJ is much better. I really don't miss Eclipse at all.
Wow this is really disappointed. I'm a PHP developer and have just switched to a 2014 Macbook Pro recently. I've tried other IDEs like Sublime, PHPStorm but decided to stay with Eclipse because they are not good enough. But this scrolling issue is a pain. And with PHP I have less alternative choices...
I switched Eclipse Luna's JSP editor to plain text to get it to not beachball anymore but lose all the cool JSP editor features (sigh). I've also resorted to using either TextWrangler or Sublime for editing as well. Its just way faster than Eclipse.
Using the latest Eclipse PDT and this bug has been occurring for a few months now. I'm on Fedora, i7 with 8GB RAM, Eclipse is absolutely useless when it comes to scrolling. It takes about 5 seconds to scroll about 100 lines on 1920x1080. I have Aptana and an Eclipse version that's about a year old and they work flawlessly here. Is there a way to disable redrawing or "animated" scrolling effect somehow so that it works properly?
OS X Yosemite: Problem still exists
This issue is becoming more urgent. Using Java 6 and a carbon Eclipse on OS X is about to become impossible probably with Apple's next OS updates. Without a scrolling fix, developing in eclipse is next to impossible. I have 280 vertical lines of text in eclipse, and I use that ability to quickly move through code, understand the flow, jump around, and so on. If you have only 60 or 100 vertical lines of code visible, you may not notice how bad the issue really is. Large monitors, lots of lines of text, and eclipse is *not* usable. It doesn't crash, but its not something that can be used. I have googled this, and can't find anything indicating this is not allowed. So if its not...then please let me know. Otherwise, I am offering $500 to the developer who fixes this bug, and gets their changes committed into the eclipse build for new versions. I'm not accepting "do this and it will be better", or "make changes here and recompile and that will fix it" type solutions. It must be a full proper solution that is accepted into the eclipse codebase fixing the issue, rewriting the scrolling, etc. The solution must fix the issue for OS X users, and I will specifically be testing it with my 280 visible lines of a java source code page. Thanks, Ben
Using a 2014 rMBP 15" 2.2Ghz. Scrolling test done using Eclipse 4.5M7, with a large 6000 lines Java file, using a maximized editor (CTRL-M), using the defaut font and size, with fullscreen Eclipse (CTRL-CMD-F), using the dark theme. I went from abysmal scrolling performance (below 15fps) to excellent performance (at least for keyboard scrolling and trackpad scrolling, see below) with *all* these conditions met: - running Eclipse on JDK 8u45. This is important to use > 8u40 as a performance bug has been fixed there - in the OSX General preferences, have "Show scroll bars" set to "Always". This is also crucially important for smooth scrolling. Otherwise the scrollbars drawn by Eclipse in place of the native OS scrollbars will slow scrolling to crawl - whitespace characters disabled in Eclipse prefs With this setup: - keyboard scrolling is mostly very smooth (> 30 fps), with the occasional hiccup - trackpad scrolling (2 finger swipe) is also a tad smoother but gets more jerky the faster you scroll - same thing scrolling dragging the (native) scrollbar: if you scroll very fast it will appear lagging. But still better than the default - mouse whell scroll is OK
I tested with 4.5m7. Its the visible vertical line count that matters the most. This version hasn't helped. The issue remains. Java 1.8.0_45 OS X Yosemite MacPro 3.5Ghz 6 Core Xeon E5 5113 lines in java code file 281 lines visible 288 characters visible width OS X scroll bars visible always key repeat set to maximum speed in system prefs Eclipse 3.4.2 (my base line): 10 seconds to reach the bottom holding down arrow. after 60 seconds was at line 1042 Eclipse 4.5m7: 10 seconds to reach the bottom holding down arrow. after 60 seconds was at line 725 So an immediate 30% decrease in speed. But its worse when you factor in the usability with the trackpad and scrolling. Subjective tests: 3.4.2: 2 finger repeated gesture scrolling, 7.5 seconds to hit the bottom 4.5m7: 2 finger repeated gesture scrolling, 10.7 seconds to hit the bottom 3.4.2: 2 finger fast as I could down, up and repeat 3 times in a row. 28 sec 4.5m7: 2 finger fast as I could down, up and repeat 3 times in a row. 36 sec 3.4.2: 20 quick rapid mini scrolls in 4 seconds, 6 seconds delay until things stopped moving. 4.5m2: same as 3.4.2 surprisingly...but it felt like it was choppier as it did the scrolling. Its my "feeling" but the frame rate feels at half the speed in 4.5m7 compared to 3.4.2. Its functional, but only just barely. Its functional like notepad is for doing development. --Ben
Eclipse is hopeless on OS X and I'm so tired of the sadly useless effort of this thread. Someone please tell me how to unsubscribe from this thread, I'm not able to find a unsubscribe button!
(In reply to Jitin Sameer from comment #78) > Eclipse is hopeless on OS X and I'm so tired of the sadly useless effort of > this thread. Someone please tell me how to unsubscribe from this thread, I'm > not able to find a unsubscribe button! Did the miss the $500 bounty Ben Spink posted just four days ago?
(In reply to Jitin Sameer from comment #78) > Someone please tell me how to unsubscribe from this thread, I'm > not able to find a unsubscribe button! You voted for this bug, and I guess your account has some options enabled in the "Voter" column here: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
Its sat to see Eclipse loosing grounds to other IDE's just because no one cares to fix this issue. Its a real show stopper and its been here for a long time. Is there anything we can do to aid in finding a fix for this ?
I would like to help also to fix this issue. Does anyone know if we can help in someway? I would like to have this bug fixed because it's really annoying. If this bug persists, I might migrate to other IDEs. I like eclipse to have lots of editors in the same one, but I prefer speed IDEs that don't slow down my day to day work. Thanks to all and let me know if we can help in someway.
The problem still exists OS X Yosemite 10.10.5 Eclipse for PHP Developers Version: Mars Release (4.5.0) Build id: 20150621-1200
Any updates on this issue? Any workarounds/fixes? Maybe there is a fix in one of the beta builds? Thanks, Michael
(In reply to Michael Krupinski from comment #84) > Any updates on this issue? Any workarounds/fixes? We're still working on this. See comment 9 for a workaround.
(In reply to Dani Megert from comment #85) > (In reply to Michael Krupinski from comment #84) > > Any updates on this issue? Any workarounds/fixes? > > We're still working on this. See comment 9 for a workaround. I really hope this isn't any indication of the work being done... Comment #9 improves the slowness...but its still garbage and impossible to use. If your working on a 15" laptop screen, or a little "HD" monitor screen, you won't notice the slowness much. But if you try and use a large screen to be productive like I do, its unbearable. I've given the timings and stats many times already, so I won't bother again, but I have to say something when someone indicates there is a "workaround". There is no actual workaround. Eclipse performance is horrible. Try Xcode, TextWrangler/BBEdit, etc. if you think eclipse is actually working fine so you see how snappy things should be. I have 280 vertical lines of text visible. My long time offer of $500 still stands, waiting for a developer to fix this issue. --Ben
Is the team still working on this? Any updates about delivery plan? Thanks, Mohit
They won't fix it, it is way too old...just throw Eclipse in the Trash and install IntelliJ because they also had the same problem and they fixed it.Now IntelliJ has 60fps when scrolling, while Eclipse is so 10 years ago,laggy and not worth taken into consideration...there are other IDEs which are better. How can you possibly not fix a BUG which is CRUCIAL in development and 4 years old?! Trash Eclipse!
(In reply to Ben Spink from comment #86) > My long time offer of $500 still stands, waiting for a developer to fix this > issue. Ben, You may have heard of our recently-announced FEEP program, where the Eclipse Foundation will be paying for enhancements to the platform. This bug is going to be on the first round of items that we will be announcing next week. Hopefully we will be successful in finding someone to take this on. If we do get it fixed, hopefully you will see fit to contribute your $500 to the Friends of Eclipse program[2]. Let's keep our fingers crossed that will be fixed soon. [1] https://mmilinkov.wordpress.com/2015/08/19/users-can-now-fund-development-work-on-eclipse/ [2] https://www.eclipse.org/donate/
I'll donate to the foundation in general if needed, but would prefer this go to the developer actually fixing the issue. Regardless this will only be a post donation as I'm not willing to give out $500 in hopes of a fix, even if expected, or promised. Only once I can validate it myself. Surely I'm not the only Java developer using a 4k vertical screen for source code... I'm tired of people saying "its not slow for me" without any real understanding of the issue. Happy to donate or pay, once the bug is actually fixed. --Ben (In reply to Mike Milinkovich from comment #89) > (In reply to Ben Spink from comment #86) > > My long time offer of $500 still stands, waiting for a developer to fix this > > issue.
(In reply to Ben Spink from comment #90) > I'll donate to the foundation in general if needed, but would prefer this go > to the developer actually fixing the issue. If this FEEP approach works, the Eclipse Foundation will be paying a developer to fix this problem. I suspect that we will be paying them more than $500. Perhaps significantly more. Once the bug is fixed to can either "top up" the developer's payment by contacting them separately, or contributing $500 to the Friends of Eclipse funds. That is totally your call.
Any news about this issue? Is there workaround?
As a slight improvement to comment 9, instead of changing system settings you can do this: defaults write -app "Eclipse Mars" AppleShowScrollBars -string "Always" and then restart Eclipse. This will force scroll bars in Eclipse Mars, but lets you keep the normal behavior in other applications.
Any way of having 60 fps in eclipse/IntelliJ like in Safari while scrolling? Is someone working at this bug?
still waiting! can't work in eclipse on Mac!
Checking this and I just can't reproduce it. Editor scrolls like any other editor on OSX as fast as others afaics. Anyone got a screencast showing the issue ?
OMG! here we go again! to reproduce it you need to have a retina macbook pro, just check and see it is not as smooth as lets say Safari, it is under 60 FPS. It hurts my eyes because of the slowness
(In reply to john elhm from comment #97) > OMG! here we go again! > > to reproduce it you need to have a retina macbook pro, just check and see it > is not as smooth as lets say Safari, it is under 60 FPS. It hurts my eyes > because of the slowness As an alternative, try scroll full screen editor on 1920x or 2500x monitor, and compare with macvim or coda.
Provide details of who you tested. See my prior comments, I provided exact details of my testing. And compare against an Eclipse 3.4.x version so you can see the difference. If you don't have a screen in portrait mode, your unlikely to even notice how bad things are. Turn your screen sideways. I'm working with 280 vertical lines in eclipse and 293 horizontal. Provide details of your testing where you don't see an issue.
you can see the difference in scrolling on retina macbook, just compare scrolling in Xcode vs Eclipse.In Xcode you always get 60 fps but in Eclipse it is not that smooth. If you increase the resolution the scrolling gets very choppy.If the editor is small it scrolls ok,but if you minimize the console and the Outline panel on the right side it gets slow on high resolution.This issue does not occur on non-retina macbooks, only on high resolution displays.Also Eclipse is not Retina ready, the icons look blurry.
To make this bug more obvious, it is also important to in the OSX General preferences, have "Show scroll bars" *not* set to "Always". And put a code editor in fullscreen and scroll that editor.
This stuation may have been improved with the release of El Capitan and the new metal, I haven't tried since... But it was also getting worse when the file/project size grows bigger (4500+ lines)
Also, don't forget that my 6 month old $500 bug fix bounty remains on this, its apparently not incentive enough...but its all I'm willing to offer for the fix. $500, just get your fix accepted and released and provide proof you did it, and its yours. --Ben
From what I can tell El Capitan did not improve things vs Yosemite. Scrolling is still dead slow if OSX "Show scroll bars" is not set to "Always". It is passable if set to something else. The slowness is proportional to the number of lines / characters shown in the editor.
Issue can be viewed by clicking the link under, I recorded using quicktime Screen Recording functionality. The Show Scroll Bars is set to -> when scrolling https://www.dropbox.com/s/c4hl8dvqni5mniz/EclipseScrollIssue.mov?dl=0
I tried capturing the slowness, but really couldn't do a good job in a video because it doesn't reflect the difference of what I am doing with the touch pad versus what I am getting. That brings up a good point, its important to have a touchpad doing inertial scrolling, not just a simple scroll wheel mouse, or page up/ down keyboard keys. And don't think the 3.4.x is perfect either...its not the fastest, but its nowhere near as bad as the current Eclipse. Other editors have always been much smoother than eclipse, and still are. Just things got even worse for a mediocre (in speed) editor after 3.4.x. --Ben
(In reply to john elhm from comment #97) > OMG! here we go again! > > to reproduce it you need to have a retina macbook pro, just check and see it > is not as smooth as lets say Safari, it is under 60 FPS. It hurts my eyes > because of the slowness I'm on OS X El Captain retina macbook pro, using a touchpad on a macbook with laptop screen running retina and external 27" monitor. If I compare with safari, then sure - its not as smooth (few apps are) but it is not at all slow. thus i'm not sure I'm actually testing/seeing the same thing.
aah! thanks to the video I got it now. Was missing the *full* screen part. only just resized my editor area. Yeah, that's not great. Unfortunately I don't know enough SWT+OSX to help fix it ;/
I think the whole UI needs to be adapted, especially the icons which look blurry. IntelliJ adapted the UI for high resolution, hiDPI and the whole UI is smooth 60FPS everywhere. Please install IntelliJ and compare the UI scroll with Eclipse.
HDPI icons is a different concern and in a different issue. I got the bug reproduced - only happens when going in 100% full screen for the editor area for me.
Hurray! :D ok, looking forward into this issue to be solved soon because ever since I bought the retina version I have to use other IDEs which do not have this issue.
I just want to raise awareness to the fact that this issue might occur also for the other panels...lets call them "editors" in Eclipse for example the outline panel on the right could also suffer from this issue if lots on thing need to be displayed there, probably the console panel down too and the Project Explorer on the left.
Great, finally something happens here. Looking forward for a fix, good luck!
No, nothing happened here. Nothing is being fixed. All the comments today were because someone new reported they couldn't reproduce it, yet they also can't fix it. So we still have no one to fix the issue, and absolutely nothing is being done on this bug. Find another IDE if you have that luxury, or suffer with Eclipse until you can't stand it any longer. The issue has nothing to do with 100% mode either, it has to dow with the number of visible vertical and horizontal lines. The issue is proportional to the number of visible lines, and the features being used (code styling, show invisibles, line numbers, scroll bars, etc.) The more you want rendered, the worse things get. But even at the most minimal level of items, its still not acceptable for a professional to work with. So 100% mode means more of that is visible, making the effect more noticeable, but if someone is paying close attention they will be able to see the issue even on smaller screens and editor areas. But its absolutely not required to be at 100% to have the issue affect you, I am generally not at 100% mode myself and still have the issue because I work on a large screen. --Ben
Okay, I joined this chorus almost four years ago (and have been using Sublime for a good three years since). Stayed on the topic ever since out of curiosity. Got a shit ton of emails today with the new "activity". Seriously, people, this won't be fixed. Sorry to further contaminate the thread with additional non-news, but I'm with my brother in pain farther above — this isn't going to be fixed, and Eclipse is dying. Save yourselves from heartache and find another IDE. Eclipse might continue as another IDE for Microsoft nerds that don't do .NET, but it's dead, and has been for awhile, for anyone not on Windows. It's sad, but seeing as how it is how it is, probably for the better :)
And, the comment system is broken for Safari apparently, causing me to inadvertently repost the same comment over and over. Sorry folks, not my doing.
no issue is encountered on retina macbook using Windows.Eclipse on retina macbook using Windows is smooth. 60 FPS
...and this thread is non-Windows. Move on.
here is a list of bugs which will be solved in the NEON version of eclipse, Retina issue bug included. https://wiki.eclipse.org/Platform_UI/Plan/4.6/Milestones Stop being so pessimistic!
The "retina" bugs took forever, and are only now being fixed... And don't confuse this situation. This is not a retina issue regardless how many people tell you its bad on their retina laptop, or not bad. I'm using a 4k display. Forget the marketing hype of retina. My monitor is not retina, pixels are much larger than the DPI on a retina display, and the issue is very and for me. More than that, its been bad across multiple displays, including Apple's non retina 30" display (identical to Dell's 30" display). The issue is purely the number is pixels being drawn in the editor and scrolling it. This is not a retina issue, and no one has made any commitment of this being fixed, and the bug you referenced is not related to this. So its not going to help. I could care less what the icons look like if my scrolling is bad.
by retina I mean high resolution definitely...how come in Xcode everything scrolls smooth and in eclipse not? It can have 5000 line and still smooth
I've spent some time today trying to analyze what might be causing this issue. I began by commenting out the ruler and whitespace rendering just to reduce the number of moving parts. Once those parts were out the way, mt observations are that if Eclipse is started when "show scroll bars" is set to "always" scrolling behaves well. If it's started when "show scroll bars" is set to "when scrolling", things go south. Interestingly, switching "show scroll bars" when Eclipse has already started doesn't have any effect (i.e. a full restart is required). The StyledText.handlePaint method seems to be where the majority of the time is spent when scrolling. I usually see 3-4 calls when I two finger scroll on the trackpad. This is the same no matter what "show scroll bars" is set to, however, the passed Event is significantly different. When set to "always", the events look like this: Event {type=9 StyledText {} time=228575339 data=null x=2 y=1031 width=797 height=10 detail=0} Event {type=9 StyledText {} time=228575418 data=null x=2 y=1030 width=797 height=11 detail=0} Event {type=9 StyledText {} time=228575429 data=null x=2 y=1026 width=797 height=15 detail=0} When set to "when scrolling", they look like this: Event {type=9 StyledText {} time=228779520 data=null x=2 y=0 width=812 height=1056 detail=0} Event {type=9 StyledText {} time=228779576 data=null x=2 y=0 width=812 height=1056 detail=0} Event {type=9 StyledText {} time=228838359 data=null x=2 y=0 width=812 height=1056 detail=0} The `height` attribute is significantly larger when the scroll lag is observed. Unfortunately I've not been able to work out why the `height` is so different. I don't have much experience working with cocoa, but I'm wondering if the information in this article might be relevant [1]? Specifically, it would be good to try using the `needsToDrawRect` method. I doubt I will be able to get much further on this, but hopefully these observations will be useful to someone who knows SWT better than me. [1] https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CocoaViewsGuide/Optimizing/Optimizing.html
After a little more time working on the issue I've found a couple of things that seem to make a difference to scroll performance for me. I'm not that familiar with SWT programming or OSX internals so I've not pushed this for a Gerrit review yet. If someone wants to take a quick look at what I've done it's available on GitHub for both Eclipse Neon[1] and Eclipse Mars SR1[2] (See the commit messages for details of what I changed). I'm also traveling at the moment so I don't have access to a large monitor to really stress test things (the best I can do is full screen on a retina display). If anyone tracking this issues wants to give my changes a try on an external monitor I've posted a jar and some instructions here[3]. [1] https://github.com/philwebb/eclipse.platform.swt/tree/bz-366471 [2] https://github.com/philwebb/eclipse.platform.swt/tree/bz-366471-mars [3] https://github.com/philwebb/eclipse.platform.swt/releases/tag/mars-sr1-patch
I confirm that it's definitely smoother on my 24" in fullscreen. Not 60 fps nor a constant framerate (there's regular hiccups) but smoother for sure. Performance is proportional to the number or characters/lines show on screen.
@Mchael Pujos, thanks for testing. That's what I expected, some improvement to make it almost usable but certainly not as smooth as applications such as SublimeText manage to achieve. Out of interest, did you have "show whitespace" and "show line numbers" enabled? Also what is your OSX "show scrollbars" setting?
Thank you Phillip Webb! (In reply to Phillip Webb from comment #126) > I'm also traveling at the moment so I don't have access to a large monitor You breathed new life to my old MacBook 2008 with external FullHD monitor connected.
Thank you Philip Webb! A definite improvement!
I can not find this path on my mac ./Eclipse.app/Contents/Eclipse/plugins/org.eclipse.swt.cocoa.macosx.x86_64_3.104.1.v20150825-0743.jar , I do not have the plugins directory nor even if I install a plugin from marketplace
@john elhm, The plugin should be inside the Eclipse.app file that you download.(it's not in the marketplace). Here's what I did: - Open the terminal at the location you want to install Eclipse - Download the Eclipse distribution you usually use (e.g. http://eclipse.mirror.garr.it/mirrors/eclipse//technology/epp/downloads/release/mars/1/eclipse-jee-mars-1-macosx-cocoa-x86_64.tar.gz) and save it to the folder $ wget http://eclipse.mirror.garr.it/mirrors/eclipse//technology/epp/downloads/release/mars/1/eclipse-jee-mars-1-macosx-cocoa-x86_64.tar.gz - Unpack $ tar xvzf eclipse-jee-mars-1-macosx-cocoa-x86_64.tar.gz - Run Eclipse at least once and say "OK" to the downloaded from internet box $ open Eclipse.app - Close eclipse - Back in the terminal cd into the plugins directory $ cd Eclipse.app/Contents/Eclipse/plugins - Replace org.eclipse.swt.cocoa.macosx.x86_64_3.104.1.v20150825-0743.jar $ rm org.eclipse.swt.cocoa.macosx.x86_64_3.104.1.v20150825-0743.jar $ wget https://github.com/philwebb/eclipse.platform.swt/releases/download/mars-sr1-patch/org.eclipse.swt.cocoa.macosx.x86_64_3.104.1.v20150825-0743.jar - Restart Eclipse $ cd ../../../.. $ open Eclipse.app
"Out of interest, did you have "show whitespace" and "show line numbers" enabled? Also what is your OSX "show scrollbars" setting?" I had neither 'show whitespace' nor 'show line numbers' enabled. But I had OSX scrollbars set to "when scrolling", which in practice disable OSX scrollbars in Eclipse and makes scrolling dead slow (without your patch). You patch improve scrolling performance easily by 10x I think, maybe more (compared to OSX scrollbars disabled). Of course this is an unscientific number. In a typical code editor window not fullscreen it's easily 30+ fps, although not constant (garbage collection maybe) ?
@Phillip Webb, the Eclipse.app from you link that you provided has the plugins directory and I replaced the .jar(I used to download a new copy which had no plugins directory), however the scrolling still isn't smooth enough.
@john elhm: did you notice any improvement? What are your "show scrollbars" and "show whitespace" settings?
scroll bar->always white spaces->checked the scrolling is not smooth enough, it is supposed to be like in TextWrangler or XCode Editor, but it is not even close to one of them...it is still choppy
(In reply to john elhm from comment #136) > scroll bar->always > white spaces->checked > > the scrolling is not smooth enough, it is supposed to be like in > TextWrangler or XCode Editor, but it is not even close to one of them...it > is still choppy Phillip did not claim that his patch resolved the issue. The question is not "is it fixed". The question is "do you notice an improvement"?
ok, so I downloaded the Eclipse again and replaced the requested .jar. I don't know if I see an improvement or it is just a placebo effect in which my mind plays tricks on me. If there is an improvement is it a small one, to me very hard to notice.
Thanks Phillip for looking into the problem. I tried out the patch. With the patch applied, I can see that there is an improvement in the scrolling performance when the "show scrollbars" is set to automatic. But, when it is set to "always", I couldn't see any improvement in performance. I had both show whitespace and show line numbers enabled.
@Lakshmi Shanmugam, One thing to double check with the whitespace speed is that you're running full-screen on a large monitor and with a file that has plenty of whitespace. The difference is only really noticeable when lots of whitespace chars need rendering. My general test was: - On a retina mac change the display setting to "scaled" and "more space" - Make eclipse full screen - Open the ArrayList type (it's pretty big and has typical whitespace) - Double click the editor title so that the editor occupies all of Eclipse - Two-finger-scroll as quick as possible
I'm back from vacation and finally got time to try out the patch which is intended to speed things up a little. I've still got $500 riding on whoever can resolve this. It does speed things up a little bit...but only a very little bit. No whitespace enabled for me, just line numbers, and scroll bars always visible. 4k monitor turned vertical, eclipse is showing 244 lines when code editor is maximized using all defaults on this brand new download of eclipse. I did a 30 second key repeat scroll test before and after the patch to give you real numbers instead of subjective opinions. Number of lines scrolled: (3.4.2) Reference: 472 --Its not fantastic, but "useable". (4.5.1) Before patch: 308 (4.5.1) After patch: 339 So you can see the patch did help by just a little bit, but its very minimal, and not enough to make things useable. And more importantly, flick scrolling with the trackpad still feels sluggish compared to 3.4.2. --Ben
It'll be very helpful, if more people can try out Phillip's patch and check if they can see improvement in the scrolling performance. Download the patched swt plugin from --> https://github.com/philwebb/eclipse.platform.swt/releases/download/mars-sr1-patch/org.eclipse.swt.cocoa.macosx.x86_64_3.104.1.v20150825-0743.jar and replace it in Eclipse 4.5.1 build. (See #comment132 for detailed steps)
And you should clarify...measure the performance change. The subjective "feels faster, Thanks!" is meaningless without before and after numbers to show the difference, knowing screen size, knowing visible lines, etc. We are all developers here I assume...so why doesn't anyone else provide any sort of numbers or metrics? If you want this fixed, provide useful information and measure things. The only way I know of to measure the speed consistently is with key repeat set on fastest in he OS and measuring how many lines are scrolled over an interval of 30 or 60 seconds. Compare before and after patch speeds, and if you have eclipse 3.4, compare there too. --Ben
I think the problem is that it took sooooooo long to get attention for a fix that everybody who suffered from this already moved on to other IDE's and now that they lost their interest in this bug (and in this IDE) :(
I have tested it on 27" Retina 5K iMac (late 2014, 4GHz i7, 32GB RAM, AMD Radeon R9 M290X 2GB) and it is clearly better now. It is still not smooth and even if you scroll very slow it would always scroll in steps of ~1 line - but not exactly and not always same height.
So do a test, compare before and after, time 30s of scrolling with key repeat on fastest, how many lines are scrolled before and after? How many lines are visible vertically when scrolling?
(In reply to Ben Spink from comment #141) > I'm back from vacation and finally got time to try out the patch which is > intended to speed things up a little. I've still got $500 riding on whoever > can resolve this. > > It does speed things up a little bit...but only a very little bit. No > whitespace enabled for me, just line numbers, and scroll bars always > visible. 4k monitor turned vertical, eclipse is showing 244 lines when code > editor is maximized using all defaults on this brand new download of eclipse. > > I did a 30 second key repeat scroll test before and after the patch to give > you real numbers instead of subjective opinions. > > Number of lines scrolled: > (3.4.2) Reference: 472 --Its not fantastic, but "useable". > (4.5.1) Before patch: 308 > (4.5.1) After patch: 339 > > So you can see the patch did help by just a little bit, but its very > minimal, and not enough to make things useable. > > And more importantly, flick scrolling with the trackpad still feels sluggish > compared to 3.4.2. > > --Ben I see that the scrolling with keys is very slow, scrolling with trackpad is much faster. The patch uses whitespace character caching to improve the scrolling. So, I think it didn't help much in the usecase you tested as you had whitespace characters disabled. Can you try to test & measure scrolling with trackpad or mouse, with whitespace characters enabled?
Scrolling with the trackpad is much faster, but what does it matter if the refresh rate is super choppy and lagging in responsiveness for when you want to stop the scrolling, or move quickly a certain amount, etc.? Using a trackpad to move around is terrible feeling, its slow...buts its really subjective to measure it unless you have a robotic arm to do the same motions, or some sort of software hack to simulate specific scrolling actions. The key repeat rate is a quick easy way to measure the screen updates in how fast its working, its shifting the entire screen up one line at a time effectively, and measuring this over a period of time gives a good solid metric that we can compare in the exact same way across machines, OS's, people, eclipse versions, and even different apps. I never have whitespace enabled, its not something I want to see, and its not something I am factoring into any measurements I have for Eclipse. I'm perceiving eclipse being slow even without that whitespace being shown. The benchmark here is eclipse 3.4 versus everything later. If someone wants to compare their whitespace speed in 3.4 versus newer, i expect it to be relatively the same speed in slowness that non whitespace in 3.4 and newer versions. --Ben
when can we expect this issue to be fixed?it is very frustrating to have choppy scrolling, intelliJ already fixed this issue.Why is it taking so long?
Agree with Ben. This is NOT a retina issue. Experience same problem on HP EliteBook 8560w running Ubuntu Linux 14.04 OS with external 1440x2560 Samsung monitor in portrait orientation. Scroll or even cursor move performance unbelievable slow. Also noted that performance totally depends on Eclipse editor window size. Had to temporary switch to Intellij IDEA because of this bug only. Also after read these comments found and installed Eclipse 3.4.2. See no such issue at all there.
There is no chance of fixing this in 4.5.2 as we're already past the last scheduled builds for 4.5.2, moving to 4.6. There is a potential solution under consideration but that seems to be only a partial one at this point... As for the problem mentioned on Ubuntu 14.04, its probably better to raise a separate bug for that issue as this bug is very specific to the scrolling behaviour on Mac OS X.
There is indeed an issue with Canvas.isObscured. I've done some benchmarks with standard neon code and with mods that prevent the full canvas to be re-drawn (setNeedsDisplayInRect for the full rect). Basically, I ignore the returned value of isObscured in Canvas.scroll. The test protocol is similar to what Ben has been doing. On file ArrayList.java, all lines displayed (1461 in my impl), 163 lines visible (27" WQHD monitor in portrait mode). Caret on line 163 (last visible). Stopwatch start when I hit bottom arrow and stop when I reach end of the document (ie when 1461-163 lines have been scrolled). Line numbers are shown, but no whitespace characters. Xcode 7.3 => 48" Atom 1.8.0 => 45" Eclipse Neon (release) => 3'13" Eclipse Neon with modified Canvas.scroll (ignore isObscured) => 1'45" Eclipse Neon with modified Canvas.scroll (ignore isObscured) + Phillip's fix => 1'26" IMHO, Phillip's fix doesn't fix the root issue. The issue is in the isObscured method. It always returns true because the difference between the visible region of the canvas (as calculated by Canvas.calculateVisibleRegion) and the visible rect of the Canvas.view (as returned by NSView.visibleRect) is not empty when the scroll bars are not always shown. So the real issue is in Canvas.calculateVisibleRegion. It always returns a size that is not accurate when the scroller are displayed as overlays. HTH -- (note that the performance issues of the whitespace character painting is not addressed here, and IMHO should be discussed in another bug linked to this one)
Since Apple has deprecated their Java 6 on OS X, Eclipse 3.4 is EOL in a few months. This 5+ year old bug is going to prevent me from upgrading my OS. This bug is becoming more urgent. My year old bounty still stands...$500 to the dev who fixes this and gets the code committed to a new build of eclipse. Just to throw more incentive on this, there are 365 days in a year, 188 days remaining this year from today. I'll pay an additional $555 for this bug fix, for a total of $1055. However, each day that goes by from today, the additional pot decreases by $5. So in 111 days, the additional pot will be $0. The original bug bounty remains as always at a fixed $500. This reflects the urgency to me...if its not fixed soon, I end up finding another tool and the second $555 pot is meaningless to me. Does that make this worth it to anyone to fix? $1k to fix a scrolling bug? Its unheard of...split it with a friend, spend an evening hacking the code to get it working, then email me. Once I have a build I can use, I'll stop the countdown and pay out the total once committed into eclipse. Want to get more specific or ask questions, etc?...email me. I just want this bug fixed. I prefer to stay on eclipse, and I am willing to pay a lot to do so! --Ben
For what it is worth: On my MacBook Pros, scrolling performance with Eclipse Mars and Neon is good on OSX Yosemite, but on OSX El Capitan, it is very bad. Also, for some reason that I do not know, on Yosemite, Eclipse has its scrollbars always visible even when the setting in System Preferences says to hide them automatically.
(In reply to Dennis Schieferdecker from comment #154) > Also, for some reason that I do not know, on Yosemite, Eclipse has its > scrollbars always visible even when the setting in System Preferences says > to hide them automatically. Scrollbar visibility behaviour in OS X may deceptively depend on whether or not you have a non-Apple pointing device plugged in. If your Yosemite system has a USB mouse or something, scrollbars may be visible compared to a system with no mouse attached. Just incase that has some relevance here.
Moving to 4.7 as we do not have any concrete fix yet, once we have a fix it can be backported to 4.6.2 or 4.6.3 accordingly.
I am having this problem on Mac OS 10.10.5 Yosemite, Eclipse Mars 2 Release (4.5,2), Build 20160218-0600. But my system was fine until recently when I did an update to the present release. The problem is fixed by an Eclipse restart, but generally returns after 24 hours or so.
Philipp, hello. Definitely you observation make sense. I enabled always scroll, and it solve problem for choppy scrolling from trackpad. osx 10.12 (macOS Sierra), Eclipse 4.5.2 (Mars). (In reply to Phillip Webb from comment #125) > I've spent some time today trying to analyze what might be causing this > issue. I began by commenting out the ruler and whitespace rendering just to > reduce the number of moving parts. Once those parts were out the way, mt > observations are that if Eclipse is started when "show scroll bars" is set > to "always" scrolling behaves well. If it's started when "show scroll bars" > is set to "when scrolling", things go south. Interestingly, switching "show > scroll bars" when Eclipse has already started doesn't have any effect (i.e. > a full restart is required). > > The StyledText.handlePaint method seems to be where the majority of the time > is spent when scrolling. I usually see 3-4 calls when I two finger scroll on > the trackpad. This is the same no matter what "show scroll bars" is set to, > however, the passed Event is significantly different. > > When set to "always", the events look like this: > > Event {type=9 StyledText {} time=228575339 data=null x=2 y=1031 width=797 > height=10 detail=0} > Event {type=9 StyledText {} time=228575418 data=null x=2 y=1030 width=797 > height=11 detail=0} > Event {type=9 StyledText {} time=228575429 data=null x=2 y=1026 width=797 > height=15 detail=0} > > When set to "when scrolling", they look like this: > > Event {type=9 StyledText {} time=228779520 data=null x=2 y=0 width=812 > height=1056 detail=0} > Event {type=9 StyledText {} time=228779576 data=null x=2 y=0 width=812 > height=1056 detail=0} > Event {type=9 StyledText {} time=228838359 data=null x=2 y=0 width=812 > height=1056 detail=0} > > The `height` attribute is significantly larger when the scroll lag is > observed. > > Unfortunately I've not been able to work out why the `height` is so > different. I don't have much experience working with cocoa, but I'm > wondering if the information in this article might be relevant [1]? > Specifically, it would be good to try using the `needsToDrawRect` method. > > I doubt I will be able to get much further on this, but hopefully these > observations will be useful to someone who knows SWT better than me. > > [1] > https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ > CocoaViewsGuide/Optimizing/Optimizing.html
Further to my previous comment. I have a desktop iMac. I always have scroll bars visible, and scroll using the scroll bars with a mouse (or Kensington Trackball to be precise), as I have always done for decades. My editor window size was circa 1200 lines, with lots of short lines. But I spotted another fault or corruption that appeared with jerky scrolling. The panel highlight colour was wrong, and didn't switch panels (editor, navigator, outline, etc). I went to Preferences, Appearance, Colours and fonts, View and editor folders. I restored and re-applied the defaults. And now the window highlight fault is fixed, and the jerky scrolling problem went away. This was 10 days or so ago, and the system has been stable since. This could be pure coincidence, but without the scrolling going wrong again, I have been unable to repeat the experiment. Also, in a state of desperation to get the scrolling fixed, I may have done something else, but a connection with fonts, window presentation, etc, did seem plausible.
Possibly related to bug 497175. I suspect we may actually have multiple bugs here (these are just hypotheses - not conclusions): 1. On OSX (and, to a lesser degree Gtk), painting the editor is slower than it should be. 2. AnnotationRulerColumn appears to be forcing a synchronous repaint in response to each scroll event. Thanks to (2), if the scroll events arrive faster than Eclipse can paint the scroll events start backing up in the SWT event queue... and thanks to (1), Eclipse doesn't paint very fast. I consider (2) to be the more serious problem, and it would be an issue with platform text, not SWT. Widgets are just supposed to dirty themselves in response to user events and then paint asynchronously. That way, if the user events arrive faster than the paints can be processed, the event queue doesn't back up. I tried to find the patch that was used to build the binaries in comment 126 but couldn't locate it. Could someone link to it? My guess is that it speeds up the paint speed rather than makes the paints asynchronous.
Just stopping in to say this issue has affected me for years, and has gotten so bad (on a brand new 2016 MacBook Pro) that I'm considering switching to a different IDE. The scrolling/editor experience is very painful when compared to Windows/Linux. If there's anything I can provide, CPU samplings, etc. that would help diagnose and resolve this issue, I'm happy to help. I love Eclipse, but this is a breaking issue IMO.
This bug is the reason i've stopping using Eclipse and switched to the community editions of JetBrains IDEs six months ago. Just mentioning this here to point out the urgency of this bug for anyone still invested in Eclipse. Appalling! Goodbye.
Moved to IntelliJ a few months ago due to this issue. Do yourself a favour and just move. This bug will never be fixed.
Moved to IntelliJ a few months ago due to this issue. Need some time to do such move, but you never move back.
(In reply to Hendrik van Huyssteen from comment #163) > Do yourself a favour > and just move. This bug will never be fixed. Do ourselves a favor and please avoid posting such useless and inaccurate comments and stop wasting Eclipse contributors resources, time and energy.
(In reply to Hendrik van Huyssteen from comment #163) > This bug will never be fixed. (In reply to Valentin Popov from comment #164) > Need some time to do such move, but you never move back. Never say never ;)
Is it possible for the webmaster to delete all the "I stopped using Eclipse because of this bug" comments and other such content that doesn't contain any diagnostic information? The amount of spam on this bug is making it very hard to follow the thread of the investigation. Go ahead and delete this comment at the same time.
New Gerrit change created: https://git.eclipse.org/r/90202
New Gerrit change created: https://git.eclipse.org/r/90203
I found three places in the code that were triggering synchronous paints in response to scroll events - two in platform text and one in SWT. The attached patches delete those calls. With the calls removed, scrolling is *instant*. No lag at all (note that I only patched the GTK version of SWT - the OSX version will also need an equivalent patch). I'm now trying to do some code archaeology to figure out why those synchronous paints were there in the first place. My guess is that the ones in platform text were workarounds for the one in SWT which may have been drawing over the ruler during scroll.
(In reply to Mickael Istria from comment #165) > (In reply to Hendrik van Huyssteen from comment #163) > > Do yourself a favour > > and just move. This bug will never be fixed. > > Do ourselves a favor and please avoid posting such useless and inaccurate > comments and stop wasting Eclipse contributors resources, time and energy. LOL :D I ditched Eclipse four years ago due to this bug. You're seriously trying to make this point? When is the last (which coincidentally would be the first) time any developer actually gave a single f*** about this bug? My God, you're delusional. We're all developers here, and as such, we should be able to recognize when someone like us just don't give a flying f***. I realized four years ago, and am so happy with Sublime Text, I just keep my subscription to this bug for the occasional laugh when some sorry person is lured into thinking that an Eclipse-based platform is in any form usable on OS X (oh, sorry, it's now 2017, make that macOS). I predict this bug will prevail until this crappy software is finally practically abandonware within the next two to three years.
> You're seriously trying to make this point? Both of you please take your argument somewhere else.
I'm going to break this into three separate bugs to deal with the synchronous paints in GTK, OSX and platform text. I can sort out the platform text issues and probably the GTK ones, but I don't have an OSX machine to fix that bit. If anyone wants to volunteer, please ping me on Mattermost and I'll share what I've learned.
For the record, I totally understand your discarding of comments like mine, and I'm happy to see you take responsibility like this — this bug needs that kind of attention, and if you're successful in getting it fixed, great! Eclipse, when usable, is pretty awesome! Good luck!
(In reply to Stefan Xenos from comment #173) > I'm going to break this into three separate bugs to deal with the > synchronous paints in GTK, OSX and platform text. > > I can sort out the platform text issues and probably the GTK ones, but I > don't have an OSX machine to fix that bit. If anyone wants to volunteer, > please ping me on Mattermost and I'll share what I've learned. I don't currently use Mattermost, but I do have an interest in getting this bug fixed on macOS (and GTK and really on all other platforms too). I'd be willing to try a patch for you on macOS or work with you on it. I'd also be willing to give you access to a macOS machine that you could work with to get the fix right (e.g., a Mac I have or <http://www.macincloud.com/>). Thanks for working on this bug! Much appreciated!
I'm currently building Eclipse locally (on my Mac running 10.12.3) with the two patches to the *RulerColumn.java classes to see how it fares. I'm not sure exactly what change is needed in the Cocoa version of Canvas.java, but if anyone has suggestions I can test them out.
I've created bug 511596 for the platform text issues. I have a patch there waiting for review and it seems to work correctly. I'd appreciate feedback from someone with more experience on that component to ensure I've tested all the correct corner cases (preferably Dani or Markus, if one of you has the time).
> I'm currently building Eclipse locally (on my Mac running 10.12.3) with the > two patches to the *RulerColumn.java classes to see how it fares. Make sure you have the latest version of the patch. I updated it recently. > I'm not sure exactly what change is needed in the Cocoa version of > Canvas.java, but if anyone has suggestions I can test them out. Run a profiler while scrolling too fast for Eclipse to keep up. Look at what the top hotspot is. You'll probably see a stack whereby some sequence of calls is invoking Canvas.update from within an SWT event handler. Break that sequence (make one of the callers invoke redraw() rather than whatever method is calling update()). See my attachment to bug 511597 for an example of how I did it on GTK or contact me on mattermost and we can look at the profiler output together. I'll stay on for another 30 mins or so. My patches are ready for review. GTk is pretty much sorted out.
Not sure if I do anything wrong, but the two patches do not appear to do anything good on OSX (10.10.5, Retina 15-inch Late 2013 MacBook Pro). Yourkit shows that Control.update takes much less relative time with the patches, but the scrolling appear to lag little more.
(In reply to Stefan Xenos from comment #173) > I'm going to break this into three separate bugs to deal with the > synchronous paints in GTK, OSX and platform text. > > I can sort out the platform text issues and probably the GTK ones, but I > don't have an OSX machine to fix that bit. If anyone wants to volunteer, > please ping me on Mattermost and I'll share what I've learned. Hi Stefan, The patch for StyledText affects Mac-cocoa as well as the code is common. The changes for platform text also would affect Mac too. With both the patches in my workspace I can see the scroll performance is better, but still not fast. I'll test some more and add the numbers here.
> I'll test some more and add the numbers here. No need. Your subjective experience is sufficient to prove that it's not fixed on OSX yet and numbers won't change that. You need to figure out what is blocking up the event queue. It's almost certainly the case that something expensive is happening synchronously while processing the scroll events. You need to figure out what that is and make it asynchronous such that there is never more than one occurrence of that operation enqueued at any given time. A profiler trace should tell us what the problem is pretty quickly.
Created attachment 266619 [details] yourkit call stack while scrolling Attached profiler capture with the two patches applied. Can't make head or tails of it, to be honest. Am I even looking at the right parts of the stack?
Let's stop the flames and counter flames and focus on the technical issues. Lakshmi will soon publish more details here.
Reassigning this back to Lakshmi. I'll offer what advice I can but I can't take the lead on the remaining OSX issues.
Re: comment 182 Please confirm that you were scrolling a large file too rapidly for Eclipse to keep up at the time you captured that trace (ie: inputs were lagging at the time)... because everything in that trace looks like it's behaving well. In that stack trace, you've expanded the nodes for the paint events and none of them are occurring synchronously during an input event. That's where we want most of the CPU time going during scroll. Could you dig around your trace some more and try to find the nodes related to handling your input events (keyboard events if you were scrolling on the keyboard, mouse events if you were scrolling on the mouse). I'd like to see how expensive they are. On GTK, prior to my patch, they were very expensive and showed up quite close to the top of the trace.
In case there's any question as to whether my patches fix scrolling on GTK... Video of GTK scrolling before my patches: https://bugs.eclipse.org/bugs/attachment.cgi?id=266621 Video of GTK scrolling after my patches: https://bugs.eclipse.org/bugs/attachment.cgi?id=266622
I understand that there is still work to do on OSX, but please let's get the patches in for bug 511596 and bug 511597 in asap since the effect on GTK is dramatic.
(In reply to Stefan Xenos from comment #186) That does look better already. But: the typical use case in macOS would be to use inertial scrolling via a touch pad, as is seen e.g. in mobile phones. I've actually stopped using mice as I use mostly keyboard with the occasional touch gesture. Check out e.g. Safari or Chrome scrolling websites on a mac. So my hunch is that the problem lies deeper. I'm sure there are standard Cocoa ways of implementing inertial scrolling, and last time I looked, this didn't work well at all (due to lag) on eclipse
FWIW I never see scrolling issues when scrolling on the trackpad on macOS but I have "highlight current line" disabled. Worth a try to see if that helps.
Created attachment 266626 [details] Flame graph captured from simple profile while scrolling It looks like about 10% of samples are to do with having the current line highlighted on each line, and another 10% each for each of the rulers visible (line numbers, debugger). In addition the StyledText class has a number of setXxx calls, which each seem to invoke 'redraw' and 'resetCache' pretty much any time anything changes. I would think this could be optimised to avoid the number of redraws necessary when changing e.g. foreground colour, then background colour. A redraw in between isn't necessary. Flame graph generated as follows: while true; do jstack $PID >> /tmp/$PID.log; done stackcollapse-jstack.pl < /tmp/$PID.log | flamegraph.pl > flame-$PID.svg Flamegraph tools available from https://github.com/brendangregg/FlameGraph
Created attachment 266675 [details] Video showing slow scrolling on macOS (10.12.3) in Eclipse (4.6.2) Stefan Xenos, great GTK videos! They so clearly show the problem and proof of fix! Thanks! Since there is no such video for macOS, I attached one that clearly shows the slow behavior on macOS Sierra (10.12.3) in Eclipse Neon.2 (4.6.2).
I also discovered bug 511803 while profiling the paint code. I have a WIP patch attached there and in my tests on GTK this also improved scroll performance considerably.
(In reply to Mikael Eiman from comment #93) > As a slight improvement to comment 9, instead of changing system settings > you can do this: > > defaults write -app "Eclipse Mars" AppleShowScrollBars -string "Always" > > and then restart Eclipse. This will force scroll bars in Eclipse Mars, but > lets you keep the normal behavior in other applications. While not a proper solution, I confirm that this makes a big improvement for me too with Eclipse from the master branch: $ defaults write -app Eclipse AppleShowScrollBars Always
By any chance, could an SWT reviewer take a look at this? https://git.eclipse.org/r/90202
(In reply to Stefan Xenos from comment #194) > By any chance, could an SWT reviewer take a look at this? > > https://git.eclipse.org/r/90202 I believe Arun is already looking at it. Niraj, can you also test it on Windows as the code is in StyledText?
Created attachment 266741 [details] YourKit-snapshot-with-latest-build I've attached a YourKit snapshot with the latest build (has the jface.text fix) and StyledText patch applied to the workspace. The performance is better than before when scrolling with keydown. But, the lag when scrolling with trackpad is still visible. The snapshot shows that the Cocoa API - NSLayoutManager.drawGlyphsForGlyphRange(NSRange, NSPoint) takes a lot of time (>20%) followed by NSLayoutManager.glyphRangeForTextContainer(NSTextContainer) (>10%). These APIs are called from StyledTextRenderer.drawLine() and LineNumberRulerColumn.doubleBufferPaint() which are invoked many times and looks like this makes drawing the text quite slow.
For what it's worth: Forcing scollbars to Always and disabling row numbers and range indicator gives a huge performance boost and is close to an acceptable work-around.
Forcing scrollbars is not a fix. And you didn't quantify anything with your "close to acceptable workaround" statement. Maybe 5 FPS for you is acceptable? Try the keyboard scrolling test to see what the exact change is scrolling over say 2000 lines before and after to give more concrete numbers. You also didn't say how many lines were visible on your screen...50 vertical text lines? 280 vertical text lines? If 50 lines scrolls good for you, great, but the bug really shows itself when dealing with large screens. I have 280 lines visible with a sideways 4k resolution, and even experimented running my monitor at 8k, but then eclipse was worthless with over 500 visible vertical text lines. I would love to try a build where I can see if there is improvement. If its helpful I could even do something with 8k screen so the situation is exaggerated to the extreme. 4320 width by 7680 height. There is still the $500 bug bounty on this issue...happy to pay out when someone fixes it.
Fair enough: My eclipse window is generally 1711x1410. 76 lines visible. 229 characters per line. I'm skinning my eclipse 4.6.2 with the solarized theme. Late 2013 16Gb mbp13 i5 on 10.12.3 Sierra. Code folding, a metric ton of projects and a bunch of other essentials enabled. Scrolling (holding down-key on) a java file of 1030 lines. Baseline for smoothness: Sublime Text 3. Scrolls through the 1030 lines in 20 seconds. Probably limited by my key-repeat delay, so around 1500 lines per 30 seconds is a theoretical max on my machine. In eclipse 4.6.2: 1. With scrollbars set to "When scrolling" and line numbers and range indicator on I can scroll 211 lines in 30 seconds. 2. With scrollbars set to "Always" and line numbers and range indicator on I can scroll 471 lines in 30 seconds. 3. With scrollbars set to "Always" and lines number and range indicator off I can scroll 571 lines in 30 seconds. In nightly build 20170214 (no particular settings): 1. 368 in 30 seconds 2. 365 in 30 seconds 3. 395 in 30 seconds So in nightly the variation has been done away with - but I can't say the overall performance is better... And Ben, I'm not suggesting this is a good-enough fix and that we can all go home - I just wish someone in this thread had informed me there was a way of ~tripling scrolling performance in 4.6.2.
The typical use case (for me at least) is generating scroll events via inertial scrolling on a touch pad. This likely generates vastly more events than holding down a cursor key on the keyboard. Scrolling to top or bottom of any editor window should take no more than half a second, as seen when scrolling long web pages in Chrome or Safari via inertial scrolling. That should be the performance target, not Sublime Text 3 via keyboard, in my opinion.
I also see a noticeable improvement in scrolling speed when turning off line numbers. (Performance is still not _good_, just noticeably better.) For most of us this is not an acceptable workaround, but I hope it's maybe a hint that the line number rendering code could use some optimization.
Absolutely inertial scrolling is important, its just hard to do measurements to know if things are improving and the subjective "feel" to it is really hard to know how much things improved. Key repeat rate is constant and once that is improved, then the inertial scrolling will be better too. We can then get all the subjective comments from people saying how fast things are. Some of the attached videos clearly show how bad inertial scrolling works with eclipse...including the GTK one which shows it appears to be completely fixed now with the latest patch. On OS X however, its still terrible for both key repeat scrolling and inertial. This seems to have been forgotten, but scrolling on 3.4.2 isn't anywhere near as bad as v4.x. I'm still on 3.4.2 for this very reason, but I would love to move beyond JDK 1.6 and a newer eclipse.
What effect, if any, do you see if you also disable the "highlight current line"?
So redid the tests: Scrollbars visible, line numbers off, range off, highlight off: 587 in 30 secs Scrollbars visible, line numbers off, range off, highlight on : 561 in 30 secs
@Stefan Xenos thank you and others for investigate time on this bug. I want point you to changes in #comment 128 from @Phillip Webb. These changes have led to a strong increase scrolling speed and comments from #127-130 confirms improvements. But this changes lost in time, why?
I mean changes in #comment 126.
See #comment 141 Prior tests were all subjective. In comment 141 I tested it to see the actual measurable increase, and over 30 seconds, it improved scrolling by 30 lines. So one more line was scrolled per second. It was an improvement, but not a noticeable one.
Created attachment 266845 [details] VisualVM Profile (.nps) of inertial scrolling w/ line numbers enabled Attached is a VisualVM profile I took while scrolling a ~200 line file back and forth for 30 seconds or so. This was in Eclipse 4.6.2 (no patches) on Sierra 10.12.3. It seems like most of the time is being spent in: org.eclipse.swt.internal.cocoa.NSLayoutManager.drawGlyphsForGlyphRange() org.eclipse.swt.graphics.TextLayout.computeRuns() org.eclipse.swt.widgets.Composite.scrollWheel() But obviously loading up the profile will give you a much better idea.
Re: Comment 205 As I said in comment 160, I found the binaries attached by Phillip Webb but could not locate his actual patch. He linked to a git repository, but I'm not familiar with the github interface and couldn't find the particular commit that was related to this problem. If you or someone else can link to the actual patch (or - even better - convert it to a gerrit patch), someone will check it out.
Here are the two commits from philwebb's forks in git-patch format. I can't push these to gerrit without resetting auther to myself (due to an eclipse policy, I believe), which I don't think would be appropriate. https://github.com/philwebb/eclipse.platform.swt/commit/35b507d5c70a8d3da945cd0bc4734e0dd4a1b522.patch https://github.com/philwebb/eclipse.platform.swt/commit/a0b2e1dcd26edce20f3cb5b7d4772418a1aea795.patch
Thanks Igor, this exactly i talk about. In my comment 129, performance boot was significant on my weak macbook 2008.
New Gerrit change created: https://git.eclipse.org/r/92327
New Gerrit change created: https://git.eclipse.org/r/92326
New Gerrit change created: https://git.eclipse.org/r/92329
New Gerrit change created: https://git.eclipse.org/r/92328
@Igor Fedorenko Sorry for the delay submitting those patches. I've pushed those commits (rebased to master) for review: https://git.eclipse.org/r/#/c/92328/ https://git.eclipse.org/r/#/c/92329/
Created attachment 267111 [details] Patched scroll (with show whitespace) Since these videos seems to be all the rage here's the result before/after the patches mentioned in comment 216. You need to ensure that "show whitespace characters" is checked to really notice the difference. This is on a mid 2015 MacBook Pro with a 1920 x 1200 monitor.
So how to we get those patches compiled locally so we can test? I want to test on my vertical 4k screen to see how it reacts.
@BenSpink I've not managed to build binaries, but you can launch eclipse from eclipse if you want to test it. 1) Download the latest "Eclipse for Platform Developers" integration build from http://download.eclipse.org/eclipse/downloads/ 2) Get the patched code: $ git clone https://github.com/philwebb/eclipse.platform.swt.git $ cd eclipse.platform.swt.git $ git checkout bz-366471-oxygen 3) Rename the classpath file mv .classpath_cocoa .classpath 4) Start the downloaded Eclipse and import existing projects (you might also need to change the "missing API baseline" setting under Preferences -> Plug-in development -> API Baselines to "Ignore" 5) Open org.eclipse.swt/META-INF/MANIFEST.MF 6) Click on "Launch Eclipse Application"
Arun, could I trouble you (or someone else from SWT) to take a look at these last two patches?
Any chance you can fill in some holes in those instructions? I tried following them, but I ran into several issues... 1.) I assume the eclipse to download is the Integration Builds header one, the most current which is not marked as unstable? (I20170305-2000) 2.) cd eclipse.platform.swt instead of cd eclipse.platform.swt.git 3.) mv .classpath_cocoa .classpath....... I'm not seeing these files in my checked out git dir... Where is this file at? I have: .DS_Store .git .gitignore README.md bundles examples features local_build pom.xml tests Not trying to nitpick, I just really want to validate the scrolling improvement. The video looked good, but a larger screen will confirm it. --Ben
(In reply to Ben Spink from comment #221) > > 3.) mv .classpath_cocoa .classpath....... I'm not seeing these files in my > checked out git dir... Where is this file at? It's in a subfolder, try cd bundles/org.eclipse.swt
1) The one I downloaded was http://download.eclipse.org/eclipse/downloads/drops4/I20170303-2000/eclipse-SDK-I20170303-2000-macosx-cocoa-x86_64.tar.gz 2) Yes sorry. I'd edit the comment but of course bugzilla won't let me do that! 3) I forgot that it's in `bundles/org.eclipse.swt` The file in the repo is https://github.com/philwebb/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/.classpath_cocoa
Created attachment 267128 [details] eclipse 3.4 carbon versus newer and patched Video of the carbon 3.4 versus new versus patched new... Can't really see a difference.
Just run the Oomph installer for the SWT project. It should set up the project well enough for you to try the patch. It doesn't quite get the native builds working but this patch doesn't edit any .c code so it should work fine.
> Video of the carbon 3.4 versus new versus patched new... > Can't really see a difference. Did have "Show Whitespace" checked?
(In reply to Phillip Webb from comment #226) > > Video of the carbon 3.4 versus new versus patched new... > > Can't really see a difference. > > Did have "Show Whitespace" checked? No. I even hid line numbers, and some other highlighting things from the defaults to try and help it.
You're not going to see much (if any) improvement in that case. This patch is specifically designed to speed up the whitespace rendering. I'd be interested to know if you see a big difference when "show whitespace" is checked.
(In reply to Phillip Webb from comment #228) > You're not going to see much (if any) improvement in that case. This patch > is specifically designed to speed up the whitespace rendering. I'd be > interested to know if you see a big difference when "show whitespace" is > checked. Hi Phillip, Thanks for the patches! I've applied both the patches and tested the scrolling. I can see that the scrolling speed has improved a *lot* (almost doubled) when whitespace character is enabled in the editor. Though, it's still slower than scrolling without whitespace character enabled, it's a big improvement. Even with the whitespace character not enabled there is an improvement in scrolling speed with the patches.
I'm glad white speak his faster, but the root issue of faster scrolling remains unfixed for OSX. Its been fixed for GTK, but not OSX. I've personally never used show whitespace characters, so its never mattered to me at all. As anyone can see in the video I posted, the scroll speed makes it completely unusable. I've had this $500 bounty sitting here for 2 years now, and even had it up to $1000 for a while. I'll leave the $500 for 6 more months, then I switch IDE's and use the $500 to pay for my next IDE. Can't anyone get the improvements seen in GTK for OS X too?
This is directed to everyone who has threatened to stop using Eclipse over this bug. I'm concerned there may be a misconception here regarding how Eclipse platform development works. When you post a comment on one of these bug reports, your audience is other Eclipse users like yourself - it's not some company dedicated to fixing Eclipse issues. Threatening to stop using Eclipse makes about as much difference to those other users as their threats make to you. Sure, you may think "yeah - I find that annoying too" but it's not going to make you any more likely to fix the problem. You don't see fixing their problems as being your responsibility. If your company relies on Eclipse heavily, ask your management to hire someone to fix this bug and any others that may be blocking you. Explain to them how much time and annoyance it will save you. If you personally rely on it, help fix it yourself. However, if everyone assumes that someone else will fix it then it won't get fixed. There's nobody here to fix this besides you and other users exactly like you.
I didn't just wine, I offered money. I offered a lot of money for a bug related to scrolling. There are *very* few people that understand the intricacies of this are of eclipse. I'm an experience Java dev with 20+ years, and my own company, and I employ people who work for me. I can't fix it. My other dev who work for me can't fix it. I have never met another dev so far in my prior careers working for other companies who could fix it. I don't personally know a single person with the kind of expertise needed to be able to fix this. So for the very few people who are on this list who posses those abilities, you are rare, and I appreciate that you can take a look at this, and I will reward one of you with an actual cash payment should you be able to fix this. I'm not threatening or whining eclipse is dead, etc. I'm just putting an end date on my $500 offer is all. August 1st, 2017 it expires. I don't want someone to call me a liar who fixes it after that date. My threat to leave eclipse amy never materialize as it will be really hard to leave it. But if you looked at the video, there is *no* possible way for me to use any new version its so bad. All you guys using little screens...I'm just not that way, and its impossible to use eclipse with the scrolling at 1FPS. Apple is going to drop the java eclipse 3.4 is using, and I can't update my OS, or else my Eclipse is dead, so I have to make a choice in probably 6 months whenever the next OS X update comes out and I am completely screwed. I *want* to use the new eclipse, I like eclipse in general, but I am being forced away from it by no choice of my own, even with cash incentive to get such a critical thing fixed you would thing that other people who like eclipse would be embarrassed to even tell someone they work on it with how bad this one single bug is. That's all... I'll stop posting these worthless garbage posts now after this and wait for something to come up that shows promise.
Please accept my apologies Ben. I didn't mean to suggest you were whining and your bounty offer is very generous. However, what the Eclipse platform as a whole needs in order to fix bugs is contributors. In a lot of bugs, there's nobody currently contributing to the project that understands the relevant code. The fact that you and your staff don't know how any of this works doesn't mean you can't fix it. It just means someone will need to figure it out. It will take time, but if switching to another IDE and retraining your staff would cost your team a bunch of manhours I'd suggest spending those manhours instead on having one of your developers learn what they need to learn in order to fix this bug. Having such a developer on your team may actually save costs in other ways because they can fix also any other workflow-breaking problems your team encounters.
(In reply to Ben Spink from comment #230) > I've had this $500 bounty sitting here for 2 years now, and even had it up > to $1000 for a while. Maybe you should get in touch with the FEEP program ( https://eclipse.org/contribute/dev_program.php ) which is responsible of dispatching donation money to work items. Direct donations for a task aren't yet clearly handled by the program, but your bounty could be an excellent case to discuss in that context and to help FEEP also handle specific donations/bounties. Please join and post on https://dev.eclipse.org/mailman/listinfo/eclipse.org-feep-stakeholders if you want to discuss "how to found a specific task?", and let's keep this bug focused on technical issues and solutions.
I think this is a dup of Bug 511596, which was been fixed for Oxygen. I lets others confirm that with latest I-Build from http://download.eclipse.org/eclipse/downloads/
I'm downloading the latest I-Build, but the ETA is ~4 hours. :-( Will let you know then, unless there's a faster mirror somewhere.
My download speed is also very slow. Will post an answer, once I am ready with the download.
(In reply to Lars Vogel from comment #235) > I think this is a dup of Bug 511596, which was been fixed for Oxygen. I lets > others confirm that with latest I-Build from > http://download.eclipse.org/eclipse/downloads/ I use I20170317-2000. Scrolling is still very slow.
I only have anecdotal evidence, but I20170322-2000 feels identical to 4.6.
Confirming that I20170317-2000 is still dead slow, scrolling in a 11000 lines Java file, using a 2014 MBP @ 1080p high dpi, jdk1.8.0_112. Like really, shockingly slow. It will not be today that this issue is put to rest unfortunately. The day it happens, I will celebrate.
Bug 511596 only fixed GTK. This bug has the same symptoms but affects OSX.
I tested the version from 0322, it looks like the scrolling is a bit faster and snappier, but still not good enough.
Please for the love of god someone fix this, it has driven and continues to drive me *bonkers* How many years is it this has been an issue now? This absolutely cripples productivity on OSX, Eclipse is legitimately unusable on Apple devices... how is this not a major issue?
@Liam Stewart I agree with you. This issue is the BIGGEST ISSUE Eclipse has!!!!! There is no other issue with Eclipse of this IMPORTANCE!!!!! This IS A STOP BLOCKER!!!! and it should be given the HIGHEST PRIORITY !!! Leave all other BUGS and fix this this BLOCKER!!! NetBeans and IntelliJ had the same issue with scrolling on the Mac, but they both FIXED the issue!!! It passed almost 5 Years since this issue was first noticed and nothing changed since then!!! WTF!!! If you developers can't find a solution for this issue, go do something ELSE!!!
(In reply to john elhm from comment #244) > @Liam Stewart I agree with you. This issue is the BIGGEST ISSUE Eclipse > has!!!!! There is no other issue with Eclipse of this IMPORTANCE!!!!! This > IS A STOP BLOCKER!!!! and it should be given the HIGHEST PRIORITY !!! Leave > all other BUGS and fix this this BLOCKER!!! > > NetBeans and IntelliJ had the same issue with scrolling on the Mac, but they > both FIXED the issue!!! > > It passed almost 5 Years since this issue was first noticed and nothing > changed since then!!! WTF!!! > > If you developers can't find a solution for this issue, go do something > ELSE!!! dude, I don't think you understand how open source works
I do, that's why this IDE is such a bad product...I prefer to pay 0.99$ for an app as long as it works, instead of being free will full of ads.
There are numerous other IDEs that will be more than happy to take your money then. If you're so willing to pay, I'm not sure why you're still here contributing absolutely nothing to the conversation.
why does it take so long to FIX this BLOCKER dude?! Everyone is going crazy here cause of this issue. Don't you care about that?
(In reply to john elhm from comment #248) > why does it take so long to FIX this BLOCKER dude?! Everyone is going crazy > here cause of this issue. Don't you care about that? You've got a few options: 1. Fix the problem yourself, surely you could have figured this out sometime in the past "5 years" if it was really that big of a deal for you. 2. Take your own suggestion and switch to another IDE, I recommend JetBrains products personally. 3. Wait on someone capable to fix it. Disclaimer: this option may take another 5 years. This is the nature of open source. No amount of complaining is going to change anything. Everyone on the CC list of this bug are just regular people like you, we don't attend any board meetings where your opinion might matter, etc. Complaining to us is just a waste of your time, and ours-- not to mention all of your complains have already been voiced multiple times above.
I already gave up Eclipse...cause of the ignorance...but I remained subscribed here and I receive messages from people complaining about the incompetence of the "Devs" and your "open source" facts...I never thought it would end up with complains.
FWIW, I am using Eclipse with CDT in MacOS and ever since I activated to always show the scrollbars in the editor, scrolling was fine for me, and nowhere near as bad as in the video in the attachment. I can scroll through a 1000+ line C++ file in a project with about 100 compile units just fine.
It is still not fixed...
John, Brandon has already explained all your options. Please be considerate to other subscribers and don't abuse this thread. Stick to the topic - bug related technical conversations. This is not a chat room.
Looking at the profiler traces, it seems like drawGlyphsForGlyphRange is the biggest hotspot on OSX. Presumably, that's related to painting text. Some relevant info here: http://www.cocoabuilder.com/archive/cocoa/32180-optimizing-drawing-text.html Just a thought: I know that the Mac likes to use lovely anti-aliased fonts everwhere, which are presumably expensive to render. I wonder if there's any way to force it to use an ugly old-style bitmapped font?
I would think downgrading text rendering to ugly-style isn't a real solution. There's enough precedent of butter-smooth scrolling walls of text all over macOS.
Given we know that it appears to perform much better when the scrollbars are always on, I'd guess the remaining issue is related to the scrollbars turning on and off depending on the scroll method.
Given many other IDEs had this issue in their past at some point caused by the same update by apple, can't we just look into other open source IDE's commits around those days and have some clues?
(In reply to Emre Besirik from comment #257) > Given many other IDEs had this issue in their past at some point caused by > the same update by apple, can't we just look into other open source IDE's > commits around those days and have some clues? Sure, if you find some helpful links, please share them.
I think this might be it; https://github.com/JetBrains/intellij-community/commit/c747f6ce2db01919b6708f2adb5ca3ac9f353694 https://youtrack.jetbrains.com/issue/IDEA-97804#tab=Comments did not throughly inspected though...
(In reply to Torkild Resheim from comment #256) > Given we know that it appears to perform much better when the scrollbars are > always on, I'd guess the remaining issue is related to the scrollbars > turning on and off depending on the scroll method. Couldn't we enforce for Oxygen to always show the scrollbars on OSX if no better fix was found? Then we'd have happier users, and OSX-friendly contributors could work on fixing it with less noise and pressure. Also, at that point, shouldn't we split this issue into several ones: * One about rendering too slow without scrollbars * Another about rendering too slow with "Show Whitespaces" * Maybe others I've missed? Or are the 2 things strongly coupled?
Well although permanently showing scrollbars does improve scrolling a bit, it is still pretty laggy, far far laggier than on Windows. I think the people saying that helped are just happy it was a bit snappier, with a retina screen and a small font size it is still pretty bad so I wouldn't see that as a fix, just as a symptom of a larger issue. So here are the things we know speeds it up a little: - Don't show whitespace characters - Don't draw line numbers - Use a larger font (so less characters are drawn to the screen) But even with all of those in place it still isn't what I would call "snappy", and the symptoms seem to point to an issue with rendering text (less characters on the screen = better performance). Is it something specifically to do with retina screens? I don't recall having this issue on my 2011 MBP which was non-retina, it's only since I grabbed a 2016 one that this issue jumped out at me. Emre Besirik had a really good idea with regards to seeing what other IDEs did to fix this, I know IntelliJ had this issue when Retina screens became a thing but they resolved it fairly sharpish, can someone who knows a thing or two perhaps take a look at his links? Just to confirm, although forcing scrollbars does help a little, it is not the fix we are looking for as it is still no where near close to windows performance. Windows is snappy and instant with its scrolling, OSX feels heavy and laggy even with every workaround and tweak listed in this thread. In order to not get in the way of the user, this needs to be 100% responsive, just like in Windows. I get that this is Open Source, but a 5 year old issue that makes this product fairly incompatible with a mainstream operating system... surely this has to catch *someones* attention? I understand how Open Source works, but let's not talk about forcing everyone affected onto another IDE, I really don't want to have to learn the ins and outs of IntelliJ because I can't scroll down my classes, and I've used this IDE for over 10 years... switching to something else now feels like trying to teach a dinosaur how to drive a car. I can't take the time to learn everything I need to learn in order to debug and fix this myself, I am a busy guy and my productivity has already been obliterated by this issue as it is... what I can do is test and provide any information anyone needs in order to look at this. I have a system heavily affected by this issue and am 100% up for working along side someone and providing them all the information they need to address it. If you are reading this and you are an eclipse contributor looking to do something legitimately impactful to a huge number of users, let's work together and get this sorted.
Forget Apple marketing. "Retina" screens are just a larger resolution, so there is more pixels to draw...my screen is 2160x3840. I don't have the UI making things "sharper". So your old laptop running at 1600x1200 just wasn't drawing very many pixels...I have more than 3x as many vertically. Or to put it another way, I have 280 lines of text visible in eclipse, with 292 horizontal characters. So technically I could have 81,760 (292x280) characters visible that need to be scrolled. Granted my code has a lot of white areas...but you get the idea. So the larger amount of characters to scroll slows this. Scrollbars affect things so minimal its pointless. Enabling whitespace drawing affects things because now you just increased the number of "characters" that have to be rendered... Its only the spacing at the end of the line that isn't rendered. When someone things there is a fix, measure it. Stop the "it feels snappier" subjective garbage. Tell us how many lines were visible in your scrolling test, use the fastest keyboard repeat rate, etc. Something that can be measured and replicated.
(In reply to Ben Spink from comment #262) > Forget Apple marketing. "Retina" screens are just a larger resolution, so > there is more pixels to draw...my screen is 2160x3840. I don't have the UI > making things "sharper". > > So your old laptop running at 1600x1200 just wasn't drawing very many > pixels...I have more than 3x as many vertically. > > Or to put it another way, I have 280 lines of text visible in eclipse, with > 292 horizontal characters. So technically I could have 81,760 (292x280) > characters visible that need to be scrolled. Granted my code has a lot of > white areas...but you get the idea. > > So the larger amount of characters to scroll slows this. Scrollbars affect > things so minimal its pointless. Enabling whitespace drawing affects things > because now you just increased the number of "characters" that have to be > rendered... Its only the spacing at the end of the line that isn't rendered. > > When someone things there is a fix, measure it. Stop the "it feels > snappier" subjective garbage. Tell us how many lines were visible in your > scrolling test, use the fastest keyboard repeat rate, etc. Something that > can be measured and replicated. Actually in case of retina "marketting" its not exactly like that. you still see exactly the same amount of characters as you see before retina, the only differance is that each character is represanted with more (at least x4 time more) pixels. So it is not more chacters, its more pixels per character.
I decided to have a look and I noticed scrolling is significantly more responsive on Oxygen using the current org.eclipse.swt master. I opened the same file on Neon.3 to confirm. There have been several changes on SWT for macOS since Neon.3, several related to HighDPI (retina) screens. Since I have such a screen it may be that the improvements I see does not affect scrolling in general. Anyone else want to give it a try? The easiest is to start with the Eclipse Installer, select Eclipse for Committers and provision for the SWT project. OS.java is a nice 4400 line file that should be sufficient for testing.
I just had a look at the NetBeans issue tracker and found a few that may be related. NetBeans use a different rendering technology, but there might be a few clues. Related Netbeans bugs: * Editor scroll very slow on iMac retina 5k [1] * Performance improved significantly using Java 9 * Is related to high resolution displays and Draw2D * Poor editor performance with Java 7 and retina display on OS X [2] * OGL: rendering of lcd text is slow[3] [1] https://netbeans.org/bugzilla/show_bug.cgi?id=249391 [2] https://netbeans.org/bugzilla/show_bug.cgi?id=237724 [3] https://bugs.openjdk.java.net/browse/JDK-8087201 As noted earlier, performance has improved in Oxygen and backported to Neon.3 (see "depends on" above), especially when using the trackpad, but scrolling using the keyboard, line by line, is still pretty slow. I suspect that this issue is related to the introduction of "retina" displays and that Eclipse is rendering bits twice as often as it should. There is some indication of that, given numbers above. The improvements we see may be unrelated, for instance handling excessive ruler repainting, e.g. the line numbers ruler, see #511596. I'm not familiar enough with the SWT code to understand what is happening, but it could be as simple as that somewhere the area to be repainted is reported to be ½ the size it should be, because of some property reporting the wrong display area.
New Gerrit change created: https://git.eclipse.org/r/95461
Gerrit change https://git.eclipse.org/r/95461 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d25c358129bdd309520ae7b67a7f0ced1e33a85b
Is there a build, which contains this change?
(In reply to Teodor Shaterov from comment #268) > Is there a build, which contains this change? You can use the latest I-Build: http://download.eclipse.org/eclipse/downloads/
I've tried it and it looks much better now! Even when scrollbars are not always shown.
(In reply to Lars Vogel from comment #269) > (In reply to Teodor Shaterov from comment #268) > > Is there a build, which contains this change? > > You can use the latest I-Build: > http://download.eclipse.org/eclipse/downloads/ I'm still testing and validating if the change improves the performance. Will post here once I can confirm this.
@Lakshmi Shanmugam Thanks for reworking the original patch and applying it to master. Are you still considering https://git.eclipse.org/r/#/c/92329/ to help with performance when "Show Whitespace" is checked?
Scrolling still dead slow, using Eclipse I20170423-2000, macOS Sierra 10.12.4 on a rMBP 2014, 1080p @ HiDpi, scrolling a Java file using keyboard down arrow, line numbers disabled. "Show scroll bars" macOS system preference does not seem to have any impact in performance: scrolling is dead slow whatever its value. Is it certain that the latest commit went into this I20170423-2000 build ?
Thank you for fixing this! Just a minor thing, a debug println was left behind https://git.eclipse.org/r/#/c/95461/4/bundles/org.eclipse.swt/Eclipse+SWT/cocoa/org/eclipse/swt/widgets/Composite.java:576
(In reply to Phillip Webb from comment #272) > @Lakshmi Shanmugam > > Thanks for reworking the original patch and applying it to master. Hi Phillip, The patch is part of the build - I20170424-2000. But, on testing the build I notice some strange behavior. The scrolling speed doesn't seem to have improved in the build, but when I measure it with eclipse launched with the same code in the run configuration it shows a big improvement scrolling performance. I'm not sure what is the problem. But looks like the fix is not working in the build. Can you please test the build and see if you notice the same behavior? Another problem I noticed is that some files scroll much slower (for eg:OS.java) compared to the other files.
(In reply to Berardino la Torre from comment #274) > Just a minor thing, a debug println was left behind > https://git.eclipse.org/r/#/c/95461/4/bundles/org.eclipse.swt/Eclipse+SWT/cocoa/org/eclipse/swt/widgets/Composite.java:576 > This has been removed in another commit --> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ae04c8525a357949d37af6e10cb336e47da6357a
(In reply to Eclipse Genie from comment #267) > Gerrit change https://git.eclipse.org/r/95461 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d25c358129bdd309520ae7b67a7f0ced1e33a85b > I've been testing the builds with this fix and I can confirm that it improves the scrolling performance. But there are still 2 problems due to which the performance improvement is not as much as I saw while I tested the patch (p.s comment#229): 1) The fix doesn't show as much performance improvement in the build as it does in a run configuration mode. I've also tested by launching eclipse without the launcher and it scrolls as fast as it does in run configuration mode. So, launching eclipse with the launcher seems to make the scrolling slower. I looked at the launcher code but was not able find the reason(s). 2) Some files (eg: OS.java) scroll very slowly in the Java editor compared to other java files (eg: Display.java). It doesn't seem to be related to the number of lines.
The fix for bug 434194 should also improve the scrolling speed quite a bit. Try it out!
1. I just found that for me the slow scrolling causes simultaneous moving of cursor. 2. If I am concentrated to don't move mouse while scrolling it scrolls fine. 3. If I use trackpad for scrolling while moving cursor with mouse, scrolling is so slow, that it keeps to scroll even minute after I stopped doing scrolling gesture.
1. I just found that for me the slow scrolling causes simultaneous moving of cursor. 2. If I am concentrated to don't move mouse while scrolling it scrolls fine. 3. If I use trackpad for scrolling while moving cursor with mouse, scrolling is so slow, that it keeps to scroll even minute after I stopped doing scrolling gesture. I have Version: Neon.2 Release (4.6.2) Build id: 20161208-0600
I am sorry, that I posted 2 maybe useless comments in this thread. I tried to download latest release of Eclipse and it already has performance radically improved. So issue I written above is gone. Scrolling while moving cursor is almost fluent for me.
This is probably not related, I am just wondering if anyone else noticed this and maybe this one here fixes it. Since Mars 1 (4.5.1) I get a lot of flickering (Mac OS 10.11) when expanding items in tree editors (e.g., Package Explorer) and scrolling, and also scrolling in editors. With Neon this got even worse that it's quite annoying. Compared to Mars (4.5.0) it seems that expanding and scrolling got faster, which is why I am commenting here.
I have mentioned this before...but it apparently needs mentioning again. When someone thinks there is a fix, measure it. Stop the "it feels snappier" subjective garbage. Tell us how many lines were visible in your scrolling test, use the fastest keyboard repeat rate, etc. Something that can be measured and replicated. Since there had been a few emails of people commenting it was much faster, I went to check...and well, there has been no change. None. Its not usable. I don't have line numbers enabled, or show invisibles, and scroll bars are always visible. In 30 seconds I scrolled 74 lines. 2.46666 lines per second with fastest keyboard scrolling rate. 244 visible vertical lines of text. Eclipse Neon 4.6.3
IMO, the best way to measure this is to record a video that shows both the mouse movement and the scroll behavior. That lets you count the input-to-pixel latency by counting frames. Trying to instrument the code is problematic because it doesn't include anything that happens asynchronously or in the operating system. Ben: If you're using 4.6 then you wouldn't be expected to see much improvement. I don't think many of the patches I wrote went into the 4.6 branch. Try a 4.7 build. The biggest problem on OSX is drawGlyphsForGlyphRange and no patch so far has addressed this. There's been some patches targetting some lesser bottlenecks, but the biggest problem is still present... so a modest improvement is expected but it definitely won't go from being unusable to usable.
I agree a video and scrolling via trackpad would be ideal, but recording videos are annoying and slow to upload for us with slow internet. Until keyboard scrolling is fast, there is no point getting to the subjective feel of inertia scrolling. We all know its slow and unusable right now, I'm just adding some numbers to it. I tested with 4.7.0 M6, the results were identical. 74 lines scrolled in 30 seconds with 244 visible lines. For reference, eclipse 3.4 for the same 244 lines visible did 450 lines in 30 seconds or 15 lines per second. Not super impressive, but usable. --Ben
Using 4.7.0 M6, it is still dead slow, scrolling with key down. Nothing seems to have improved. This issue is maddening in the sense that nobody seems to able to fix it for good, despite several attempts. Defeated by Eclipse's enormous complexity.
> Defeated by Eclipse's enormous complexity. The situation isn't that grim. I suspect nobody's even tried to fix this yet on OSX. My patches were intended to fix this bug on GTK, and they worked. The fact that they also slightly sped up OSX was just a side-effect. Phil's patches were intended to fix the problems with whitespace rendering, and they also worked. Nobody's even made an attempt to fix the drawGlyphsForGlyphRange issue yet, but my guess is that a serious attempt probably won't be defeated. :-) A good place to start would be to inspect the NetBeans and IntelliJ patches linked to, above.
(In reply to Lakshmi Shanmugam from comment #277) > 1) The fix doesn't show as much performance improvement in the build as it > does in a run configuration mode. I've also tested by launching eclipse > without the launcher and it scrolls as fast as it does in run configuration > mode. So, launching eclipse with the launcher seems to make the scrolling > slower. I looked at the launcher code but was not able find the reason(s). 4.7M7 build includes the eclipse launcher that has been rebuilt (on 10.10). This has improved the scrolling speed considerably and it gives similar performance as in run-config mode. I did some tests with 4.6 vs 4.7M7: Scrolling Display.java with key down for 20s, 184 lines visible. 4.6 - 100 lines scrolled 4.7M7 - 230 lines scrolled Please try out the 4.7M7 build - http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/S-4.7M7-201705120500/eclipse-SDK-4.7M7-macosx-cocoa-x86_64.dmg
(In reply to Stefan Xenos from comment #284) <snip> > The biggest problem on OSX is drawGlyphsForGlyphRange and no patch so far > has addressed this. There's been some patches targetting some lesser > bottlenecks, but the biggest problem is still present... so a modest > improvement is expected but it definitely won't go from being unusable to > usable. NSLayoutManager.drawGlyphsForGlyphRange() is showing up in the profiles because it's getting called for every line of text because scroll events are invalidating the entire editor window in StyledText.scrollVertical(). This seems to be cause by the fix for bug 511597. Previously, the code used scroll() to copy the unchanged region and invalidate a small region corresponding to the newly displayed text, which results in far fewer drawGlyphsForGlyphRange() calls. After reverting the fix, LineNumberRulerColumn and maybe the Cocoa messaging machinery are the top CPU users.
> After reverting the fix, LineNumberRulerColumn and maybe the Cocoa > messaging machinery are the top CPU users. By reverting that patch it may reduce the relative time spent in glyph drawing but it also forces one paint to occur for each scroll event - so if the paints can't be processed as fast as the scroll events occur, scroll events start backing up. That's not a trade you want to make. If you want to reduce the size of the invalidation rectangle, you'd need to do it in the paint handler (at the time when asynchronous paints are processed) - not the scroll handler (which should be getting called much more frequently). The old code used the scroll handler, which makes scroll latency worse - not better. Although it's possible we'll get some gains by copying-and-moving common pixels, I'm not sure this is really a good approach to take. It won't help with rapid scrolls since most of the screen gets invalidated anyway... and it won't fix whatever is causing the paints to get backlogged on OSX. I suspect that on OSX, we're performing one paint for each scroll event. We could confirm this by counting scroll events and paints... and if that's the case, then this is the root cause of the problem. It should be possible for scroll events to arrive much more rapidly than paint events. There should never be more than one paint event enqueued after you stop scrolling. Fixing this will fix the latency, even if the paints themselves are still slow. You're unlikely to find a fix to this by reverting Eclipse patches since AFAIK there was never a version of Eclipse that worked properly on the new versions of OSX. You're more likely to find the fix in the netbeans or intellij patches listed above, where they actually fixed this problem.
In master, scrollVertical() is called a little more frequently than handlePaint() when flicking the mouse, but not that much more. After reverting, handlePaint() is called at the same rate as scrollVertical() (after filtering out events for cursor blink). But I think what's happening in master is paints aren't keeping up with scroll events because painting is too slow and it's visible as sluggish scrolling. I don't see any evidence that paints are getting backlogged, like the paint keep firing after I've stopped scrolling (in master or after revert). I don't claim to be an expert on this stuff, but I have to disagree about copying unmodified region not being part of the solution. I don't see how you can possibly draw faster than a simple bitblt. Even the very fastest scroll I can do still has ~50% of pixels in common with the previous frame. In the more common case of slow scrolls that move the cursor one line at time or just skimming code, ~95-99% of pixels are common. Assuming for the moment the copying is part of the solution, I don't see how it can be done in handlePaint(). I don't see any way to communicate from scrollVertical() that the amount of common pixels is very large or how much is being scrolled. And does it make sense to say scroll events should be able to happen more rapidly than paint events? I think I would want paints to happen as fast as scrolls, or what I see doesn't match what I'm doing. I don't think I would want it to keep painting after I stop moving my finger, but that doesn't happen on OSX. Perhaps that's the difference between OSX and GTK that's at issue here. I think reverting the change for bug 511597 would make a big difference for OSX but I can see how it would hurt GTK. Perhaps on GTK, Canvas should turn scroll() into a no-op and Control should turn redraw(int,int,...) into redraw(). I also suspect there's some tricks OSX can do that Eclipse doesn't use. There's some stuff in Apple's docs that sounds like it can do some extra painting in an off screen layer and that it scrolls by just shifting how much of the layer is visible with the net that latency between input and display is reduced because most of the work was already done in the background. But I could also be completely misreading it. I think another reason scroll feels a little off is that Eclipse is scrolling in line height units, which is not what other apps on OSX do. Browsers or TextEdit don't do that, so they feel more responsive to fine scrolls and can make the end of a mouse flick animate more smoothly.
Using Quartz Debug's frame meter (now in the Additional tools for Xcode package in the Graphics folder) may help get some figures on refresh performance, although it won't tell anything about over-redraw of course but the numbers seem to match what happens on screen. On 4.7 build I20170520-1500, I get those on a work area of 1900x1300@2x (3800x2600) on a 5K iMac, 80 lines displayed, scrolling with MagicMouse or scrollbar, scrollbar forced to display as it improved performance before but seems to not matter now. - Vertical scrolling: 10 fps - Horizontal scrolling: 30-35 fps (would be ideal if that was the other way around) When moved to a non-HiDPI display connected to the same machine figures become - Vertical scrolling: 20-22 fps - Horizontal scrolling: 60 fps On 4.7 build I20170512-0500, same performance on vertical scrolling, but horizontal scrolling is much less, about the same as vertical. On 4.6 vertical scrolling was subjectively the same performance. For comparison, on the same file with a very similar work area, same font and syntax coloring on, IntelliJ gets 60 fps in both directions, and Xcode seems to target 30 fps when it cannot get to 60. Some additional observations that may give a hint to someone who's acquainted to the inner workings of Quartz: - Scrolling performance drops if Eclipse's main window is dragged on a non-HiDPI display then brought back to the HiDPI one, getting in the 5-7 fps area. Relaunching seems to be the only fix. - All main windows for other apps have a non-retained backing (visible when selecting the window in Quartz Debug > Window List, in the Detail panel) with none or opaque alpha whereas Eclipse has a Buffered backing with meshed alpha. - Eclipse windows are the only ones to never show any tint when using the 'Tint surfaces' options in QD (not sure what surfaces it refers to, this one is poorly documented) - Eclipse keeps apparently for internal use a 1600x900 window on screen at Y=10,000 named "PartRenderingEngine's limbo" which is initialized before the workspace window during startup but seems to never be drawn to as QD shows a blank content in the preview.
On my 5K imac set for "Scaled Looks like 2560 x 1440" and 86 lines of 11 point Monaco, I get: master scroll w/ keyboard - 30 fps scroll w/ magic mouse - 25-30 fps revert bug 511597 scroll w/ keyboard - 40-45 fps scroll w/ magic mouse - 35-40 fps TextEdit at full height with the same font gives 50-60 fps with magic mouse. Its window is tinted. Terminal at full height with the same font gives 50-55 fps with magic mouse. Its window is not tinted just like Eclipse.
I forgot to try without the line number ruler enabled. master w/ magic mouse - 25-30 fps (change isn't noticeable) revert bug 511597 w/ magic mouse - 40-45 fps (a bit faster)
(In reply to Lakshmi Shanmugam from comment #288) > This has improved the scrolling speed considerably and it gives similar > performance as in run-config mode. > > I did some tests with 4.6 vs 4.7M7: > Scrolling Display.java with key down for 20s, 184 lines visible. > 4.6 - 100 lines scrolled > 4.7M7 - 230 lines scrolled > > Please try out the 4.7M7 build - > http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/S-4.7M7-201705120500/eclipse-SDK-4.7M7-macosx-cocoa-x86_64.dmg > Anyone tried out the 4.7M7 build & saw any improvement in scrolling speed?
> Anyone tried out the 4.7M7 build & saw any improvement in scrolling speed? Yes, tried and confirm improvement ~2x over 4.6.
> I don't see how you can possibly draw faster than a simple bitblt. Although the slow paints themselves are a problem, they're not the biggest problem. The biggest problem is that - after you stop providing scroll inputs - the UI paints multiple times with different out-of-date scroll positions. That means you need to wait for multiple repaints before you see the final state of the workbench. Let's say each repaint takes N milliseconds and you need to wait for k repaints before you see an up-to-date version of the workbench. That means the total time the user spends waiting for an up-to-date state is kN. Reducing either k or N will reduce the total input latency. Currently N appears to be an (uncomfortably large) constant, but k appears to grow without bound. Reducing either number improves the input latency. Making things draw faster reduces N which will improve the latency by a constant factor, but the latency will still grow without bound unless something is done about k... and there's no reason k needs to be > 1. Yes, what you suggest will probably make things draw faster... and that's great but making things draw faster isn't the most important factor in fixing the UI latency. > Assuming for the moment the copying is part of the solution, I don't see > how it can be done in handlePaint(). One possible implementation: Every time you paint something, remember what the scroll position was. The next time you need to paint something, compare the new scroll position to what the scroll position was the last time you painted. Then use that delta to figure out if you can use a bitblt optimization. There's no need to pass information directly from scroll handlers to paint handlers since there should be multiple scroll events between each paint. HOWEVER: All this can accomplish is speeding up the paint times. It won't solve the bigger issue which is the fact that the paints are being queued. According to comment 294, paints already run at 25fps in the worst case. That means that if we fix whatever is queuing up the paints, we can get the input latency below 1s/25=40ms - and that's without making any improvements to the drawing speed. Videos currently show UI latency of multiple seconds due to the paints being queued up, so that's an improvement of at least 100x. If you're measuring FPS, you're measuring the wrong thing. It doesn't matter if you can paint the screen at 60fps if the thing you're painting lags behind the user's inputs by several seconds. The thing we're trying to fix here is input latency, not the FPS. Yes, bug 511597 slows down painting, but it's quite reasonable to trade off FPS in order to prevent queuing. > I don't think I would want it to keep painting after I stop moving my > finger, but that doesn't happen on OSX. Continued movement after the finger is removed is exactly what I saw in the attached videos. If that's not the case then you're right that I've been trying to fix the wrong problem - and we *should* be focusing on rendering time. Could someone confirm this with a video? > And does it make sense to say scroll events should be able to happen > more rapidly than paint events? Yes. You can't process paint events any faster than you can draw them, and there is no such limit to how fast you might receive scroll events. If the scroll events arrive at a faster rate than you can paint them, you have only two choices: either queue them up and paint once for each scroll event (which creates UI lag) or allow the scroll events to be processed faster than the paint events. If you see the same number of scroll and paint events while the framerate is low then it's an indicator that the implementation may be doing the former.
(In reply to Stefan Xenos from comment #297) > > I don't think I would want it to keep painting after I stop moving my > > finger, but that doesn't happen on OSX. > > Continued movement after the finger is removed is exactly what I saw in the > attached videos. If that's not the case then you're right that I've been > trying to fix the wrong problem - and we *should* be focusing on rendering > time. Could someone confirm this with a video? Certainly my attached video from 2017-02-06 is sufficient confirmation, no? https://bugs.eclipse.org/bugs/attachment.cgi?id=266675 At 7 seconds into the video, I take my finger off the mouse, and Eclipse continues to scroll all over the place for 18 seconds after that with me doing nothing. Or am I not understanding what confirmation is desired?
Isn’t some of the scrolling post finger-lift desirable? I imagine those events are primarily caused by inertial scrolling. In other words, on macOS, scrolling slows down gradually instead of ending abruptly after lifting your finger. Try scrolling with any other Mac application and you’ll see it there too. One of the differences though is that when you change directions or if you place your finger back on the touch surface, the old inertial events are discarded. Eclipse doesn’t discard events like that so the user ends up waiting for that inertial stuff to clear out before any other desired scrolling can execute.
(In reply to Brian Mauter from comment #299) > Isn’t some of the scrolling post finger-lift desirable? I imagine those > events are primarily caused by inertial scrolling. In other words, on > macOS, scrolling slows down gradually instead of ending abruptly after > lifting your finger. Try scrolling with any other Mac application and > you’ll see it there too. One of the differences though is that when you > change directions or if you place your finger back on the touch surface, the > old inertial events are discarded. Eclipse doesn’t discard events like that > so the user ends up waiting for that inertial stuff to clear out before any > other desired scrolling can execute. Yes, excellent point! If I flick my finger on my mouse to scroll in Safari and take my finger off after the flick, it does do the inertial scrolling where it keeps scrolling the page for about 1 to 1.5 seconds longer, not at constant velocity, but rather decelerating to a stop over that 1 to 1.5 seconds. And yes, as you noted, if I flick in the opposite direction, it *immediately* starts inertial scrolling in the direction of the flick. It doesn't do any sort of trying to finish inertial scrolling that is in progress. So, if Eclipse is not discarding old inertial scrolling events that are in the opposite direction of the most recent inertial scrolling events, that is definitely an issue!
> Certainly my attached video from 2017-02-06 is sufficient confirmation, no? Yes. That's the video I was referring to. The problem in that video has everything to do with events being queued and nothing to do with FPS. However, comment 291 seems to suggest that Brian is seeing something different. Brian, if the problem you're seeing is different from the problem shown in that video, please file a new bug for it (and please attach a video that also shows your input device): https://bugs.eclipse.org/bugs/attachment.cgi?id=266675 Although improving FPS is also a good thing and is worthwhile doing, it's not the subject of this bug. Re: comment 299 > Isn’t some of the scrolling post finger-lift desirable? Yes. Sorry, I should have been more precise with my language. Continued movement after you remove your finger from the input device isn't necessarily a problem. Continued movement for more than 1 repaint after you've halted the inertial scroll is a problem. So is continued movement in the old direction after you've reversed the direction of scrolling. Changes which improve FPS will certainly help latency a bit and they're worthwhile doing as long as they don't introduce more queuing. However, we should definitely not introduce more queuing in order to improve FPS, which is what comment 294 does.
I just noticed that the Package Explorer and CVS History views properly discard inertial scroll events like Safari does. They immediately reverse and stop. That got me to wondering if the text editors handle these gestures too. What if the paints are so slow that it just appears to not discard the events? So, I resized Eclipse to be very small so that paints would be faster and sure enough, the text editors immediately reverse or stop like Safari. Sorry for the distraction.
(In reply to Brian Mauter from comment #302) > I just noticed that the Package Explorer and CVS History views properly > discard inertial scroll events like Safari does. They immediately reverse > and stop. Those are backed by OS widget while the editor is backed by a custom widget (StyledText).
*** Bug 321020 has been marked as a duplicate of this bug. ***
Its been another 5 months, time to revive this thread again. Currently I tried Eclipse "Version: Oxygen.1 Release (4.7.1)". Eclipse 4.7:243 vertical lines visible. Eclipse 3.4:279 vertical lines visible. 30 second timer. Eclipse 4.7: 161 lines scrolled. Eclipse 3.4: 343 lines scrolled. From my perspective I cannot see any improvement at all. High Sierra has been released and I cannot update to it as I loose Java 6, and can't run Eclipse 3.4. Track pad flick scrolling is immeasurably worse and impossible to use on 4.7 due to the delay and lagginess of it. $500 bug bounty still remains to whoever fixes this issue.
(In reply to Ben Spink from comment #305) > $500 bug bounty still remains to whoever fixes this issue. I don't think discussing bounties is adapted and efficient on a bug tracker. Please consider a service such as biuntysource.com, patreon.com or other to track that; or directly reach Eclipse consultants in order to contract tjis development. If you don't know any, the Rclipse Foundation should be able to list some, see eclipse.org website to contact Foundation staff about it.
Bug 522110 might be related.
I've borrowed a Mac and have a few hours free this week to take a look at this bug. Unfortunately, it seems as though the Eclipse Oomph configuration is broken again - so instead of investigating the laggy scrolling, I'm just trying to get Platform UI to compile locally without errors. If some kind soul could fix the Platform UI setup steps in the next day or two, I'll see what I can do about the Mac scrolling. Specifically, these steps are no longer producing a working Eclipse workspace: https://wiki.eclipse.org/Platform_UI/How_to_Contribute
Bug 526117 tracks the problems with the Oomph setup.
So although oomph failed, I managed to get a compiling workspace using a manual git checkout and I20171015-0655. We're good to go! I'll be working on this between 3:30AM and 6:00AM GMT every night this week. If anyone wants to collaborate, I'll be lurking on Mattermost and IRC.
Created attachment 271025 [details] What scrolling looks like on I20171015-0655
Sadly, I can't reproduce the behavior shown in https://bugs.eclipse.org/bugs/attachment.cgi?id=266675 When I try the same steps, it looks like this: https://bugs.eclipse.org/bugs/attachment.cgi?id=271025 This doesn't necessarily mean the bug is fixed. I tried the same thing on 4.6.2 and it looked pretty much the same - so I have to conclude that I'm just not doing the right thing to reproduce it... or that the hardware on this macbook pro is different from the one that recorded that video in some important way. This one is a MacBook Pro 2.3 GHz Intel Core i7 with *GB ram. The graphics chip is an Intel HD Graphics 4000 1536 MB.
Are you using a MacBook with a retina (HiDPI) display?
> Are you using a MacBook with a retina (HiDPI) display? According to the About page, it's a MacBook Pro (Retina, Mid 2012) The Display is a 15.4-inch (2880 x 1800) According to xrandr -q, it says: Screen 0: minimum 640 x 480, current 1440 x 878, maximum 2880 x 1800 So presumably this is a retina display but it's not current running at its maximum possible resolution, which would explain the performance difference. If you want to give me a hand with reproduction, we can take this offline to the Mattermost channel or IRC.
Yeah, presumably this laptop screen isn't high enough resolution to reproduce the problem. I'll see if I can borrow a 4k external monitor on short notice.
And turn the 4k 90 degrees. Its the number of lines visible that degrades performance. My testing is with 280 visible vertical lines and 304 characters wide. This is my normal working environment. Your test video, while not entirely clear to see line numbers looked like maybe 1/5th of my working screen size. If you use a display port cable, you might even be able to do 8k...I've done that before just to show how insanely bad performance drops in eclipse. It might help in exaggerating what is taking the most time in rendering is all. Otherwise 4k is still enough. Thanks, Ben
Created attachment 271031 [details] Quartz Debug FrameMeter Just wanted to make sure everyone is aware of the Quartz Debug tool from the Additional Tools for Xcode, which includes a frame rate meter as seen from the WindowServer. It should make for more meaningful comparisons between versions.
(In reply to Ben Spink from comment #316) > And turn the 4k 90 degrees. Its the number of lines visible that degrades > performance. 50 lines at 18pt font size is bad enough on my 2012 27" non-retina iMac. (In reply to Stefan Xenos from comment #312) > Sadly, I can't reproduce the behavior shown in > https://bugs.eclipse.org/bugs/attachment.cgi?id=266675 Bump the font size up, maximize the editor window and full-screen Eclipse. Now scroll ArrayList.
(In reply to Stefan Xenos from comment #312) > Sadly, I can't reproduce the behavior shown in > https://bugs.eclipse.org/bugs/attachment.cgi?id=266675 > > When I try the same steps, it looks like this: > https://bugs.eclipse.org/bugs/attachment.cgi?id=271025 > > This doesn't necessarily mean the bug is fixed. I tried the same thing on > 4.6.2 and it looked pretty much the same - so I have to conclude that I'm > just not doing the right thing to reproduce it... or that the hardware on > this macbook pro is different from the one that recorded that video in some > important way. Thanks for working on this! Hmm, perhaps your mouse? I think the mouse I used in that video was a Magic Mouse 2: https://www.apple.com/shop/product/MLA02LL/A/magic-mouse-2 That mouse supports inertial scrolling which is what I think is happening when I flick up and down on the mouse. I think a comment on this bug asked if perhaps the inertial scrolling events weren't being canceled when the direction was changed, but I have no idea if that's happening. I don't know why I didn't try it, but I would think it should be possible to recreate the problem by just flicking with the trackpad and not using the mouse at all. > This one is a MacBook Pro 2.3 GHz Intel Core i7 with *GB ram. The graphics > chip is an Intel HD Graphics 4000 1536 MB. The laptop in that video was a "MacBook Pro (17-inch, Early 2011)": https://support.apple.com/kb/SP621 It has a 2.3 GHz quad-core Intel Core i7 processor, 8 GB of RAM, and a 512 GB SSD. The spec sheet says it has an "Intel HD Graphics 3000 and AMD Radeon HD 6750M with automatic graphics switching." It does *not* have a retina display. And no external display was connected for the test.
(In reply to Ben Spink from comment #316) > And turn the 4k 90 degrees. Its the number of lines visible that degrades > performance. > > My testing is with 280 visible vertical lines and 304 characters wide. This > is my normal working environment. > > Your test video, while not entirely clear to see line numbers looked like > maybe 1/5th of my working screen size. > > If you use a display port cable, you might even be able to do 8k...I've done > that before just to show how insanely bad performance drops in eclipse. It > might help in exaggerating what is taking the most time in rendering is all. > Otherwise 4k is still enough. > > Thanks, > Ben I'm not refuting any of what you said, but I just want to note that I had no external display connected for my "MacBook Pro (17-inch, Early 2011)" video, nor did that laptop have a retina display. So, it's possible there is more than one issue at play here, or it's possible that a faster computer has to be pushed harder (e.g., external 4K display at 90 degrees) in order to reproduce the problem.
Inertial scrolling just exaggerates the already slow nature of things. There are already sample videos showing the speed of me )and others) holding down the arrow key and watching line by line as it re-renders the screen. Its really slow. And also videos showing when using inertial flick scrolling...also insanely slow. The trackpad on the laptop can do this same effect, you don't need a magic mouse. A scroll wheel mouse is likely to hide the effect as it won't have inertia. But until just simple plain arrow key on the keyboard scrolling has improved, the inertial stuff is kind of irrelevant. If the simple scrolling is improved, so will inertial. If not, that is a secondary bug...but this original bug is related to scrolling performance in general, not just when doing so with inertial finger flicking. This original bug 321020 was reported in July 2010...but that was marked as a duplicate of this bug since this one got more comments over a year later. On a small laptop screen, the performance isn't so bad, easily overlooked and workable. But for professional's who use a large screen, its impossible to work like this. :( My experience using the frame meter was that it didn't really help show the issue, it wasn't showing slow frame rates if I recall when things were slow. Not sure why that was, but it surprised me. I'm using a high end MacPro..3.5Ghz, 6core Xeon E5, two 4k monitors, and two 30" 2.5k monitors. Its slow anywhere I put the window...one monitor is not faster than another, and with my hardware...nothing should be slow. I can run windows, and eclipse there, and get fast speeds...which seems backwards. But its my only future workable solution at the moment. --Ben
Created attachment 271043 [details] Magic Mouse 2 on 5K display
Created attachment 271044 [details] Keyboard down arrow on 5K display
On a newer MacBook Pro (MacBook Pro (15-inch, 2016), 2.9 GHz Intel Core i7, 16 GB RAM, Radeon Pro 460 4096 MB and Intel HD Graphics 530 1536 MB) running macOS Sierra (10.12.6) with Eclipse Oxygen.1a (4.7.1a), the inertial scrolling lag is much less pronounced at full screen on its built-in retina display compared to the "MacBook Pro (17-inch, Early 2011)" video using either the trackpad or the Magic Mouse 2. However, if I maximize Eclipse to full screen on an LG 5K external display (landscape orientation (sorry, I don't see a way to choose portrait; it may not support it)), I can still see some lag. I open java.util.Collections in an editor view, place the cursor at the first character of the first line, maximize the editor view, and scroll to the middle of the file using the mouse or scroll bar. Then I flick up and down 10 times on my Magic Mouse 2 and let go, and it scrolls up and down for about 5 seconds while I'm not touching the mouse at all. This can be seen in the "Magic Mouse 2 on 5K display" attachment: https://bugs.eclipse.org/bugs/attachment.cgi?id=271043 If I flick up and down using the trackpad on the laptop, it doesn't seem perfect, but it seems OK and is nowhere near the 5 seconds I see when using the Magic Mouse 2 to do the flicking. So even though in theory I would expect the flick lag to be reproducible using the trackpad, in practice there seems to be a difference between the trackpad and the Magic Mouse 2. I also tried just holding down the down arrow on the laptop keyboard (which of course will depend on the keyboard repeat rate setting) in the same java.util.Collections editor view, and there I can see a clear slowness in Eclipse's ability to scroll the view when the cursor gets to the bottom of the visible lines and has to start scrolling lines into view. This can be seen in the "Keyboard down arrow on 5K display" attachment: https://bugs.eclipse.org/bugs/attachment.cgi?id=271044 I tried the same tests in Xcode by saving the java.util.Collections source code to a file named Collections.java and opening that file in Xcode. I maximized the Xcode editor window to full screen, moved the cursor to about the middle of the file, and did the 10 up and down flicks with the Magic Mouse 2 and the trackpad, and it scrolls perfectly without any lag in both cases. Similarly, I tried positioning the cursor at the first character of the first line and holding down the down arrow, and Xcode scrolled the text into view when the cursor hit the bottom perfectly with no slowdown.
(In reply to Nelson Rodrigues from comment #317) > Just wanted to make sure everyone is aware of the Quartz Debug tool from the > Additional Tools for Xcode, which includes a frame rate meter as seen from > the WindowServer. It should make for more meaningful comparisons between > versions. Thanks for the tip, but just to be clear: the bug I'm investigating has nothing to do with framerate - it has to do with input lagging behind the paints. I don't want this bug to become a placeholder for all possible paint bugs on OSX. Once the lag depicted in https://bugs.eclipse.org/bugs/attachment.cgi?id=266675 is fixed, I think we should close this and open new bugs to track any additional framerate enhancements.
I used SetResX to force the laptop into a higher resolution than the control panel normally permits (2880 x 1800), and I can reproduce the input lag now.
While looking at a YourKit profile I saw that a recoognizable amount of time is consumed by NSBezierPath#fillRect, which is called by Control#fillBackground. In my use case (paging down with key through a 10kLOC Java file) it consumed 1,5s CPU time (16%). Notebook is a 2016 MBP, 2.9GHz, 16GB on Thunderbolt Display (2560x1440) Well, I commented out the both calls of NSBezierPath#fillRect and expected that the UI gets horribly broken, but to my surprise I did not recognize a difference. So my question is: Where does this call have a visible effect, or is it just obsolete? Please note also bug#522103 and bug#525976. The first will improve Show Whitespace, the second the overall Cocoa performance.
I've found a consistent way to reproduce the event queueing on devices whose screens are too low resolution to reproduce it the normal way. Artificially slow down paints by putting this block into NSLayoutManager.drawGlyphsForGlyphRange: try { Thread.currentThread().sleep(3); catch (InterruptedException e) { } Then run the app and scroll rapidly up and down repeatedly, then hold your finger still to stop scrolling. Expected: One very slow repaint and then scrolling stops Observed: The scroll position continues to move slowly up and down for a long time.
I think the queuing problem is related to how Display.java processes events on OSX. This is all supposition right now, but I'm recording my observations in case I don't get a chance to come back to this. Display.readAndDispatch alternates between calling nextEventMatchingMask (which extracts the next event from an OS-managed queue) and application.sendEvent (which fires it and processes stuff like scroll events). However: in addition to extracting the next event, nextEventMatchingMask seems to also have the side-effect of executing events (in particular, I observed the drawRect event on custom Canvases being invoked). So nextEventMatchingMask may end up processing a draw event for every scroll event it processes... and since each scroll event can initiate a draw, the input queue backs up when scroll events start arriving faster than the app can paint. The way to fix this would be to process all queued input events before the first paint event. One possibility might be to use the mask passed to nextEventMatchingMask in order to filter out paint callbacks and only unfilter the paints when the queue is empty (or at least when we've processed a number of events equal to the initial queue size). I'm also curious why nextEventMatchingMask is executing events to begin with rather than just extracting them from the queue and returning them.
Some reference material on the run loop: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html Any idea why a call to objc_msgSendSuper with the selector sel_nextEventMatchingMask_untilDate_inMode_dequeue_ is resulting in a callback to Display.windowProc with selector sel_drawRect_? This seems to be what's initiating the paints that are blocking the input event queue.
(In reply to Karsten Thoms from comment #327) > While looking at a YourKit profile I saw that a recoognizable amount of time > is consumed by NSBezierPath#fillRect, which is called by > Control#fillBackground. In my use case (paging down with key through a > 10kLOC Java file) it consumed 1,5s CPU time (16%). Notebook is a 2016 MBP, > 2.9GHz, 16GB on Thunderbolt Display (2560x1440) > > Well, I commented out the both calls of NSBezierPath#fillRect and expected > that the UI gets horribly broken, but to my surprise I did not recognize a > difference. So my question is: Where does this call have a visible effect, > or is it just obsolete? It is needed for many widgets if you set a background color (i.e. in the dark design) But it seems that editors don't need it even in the dark design and the improvement is really noticable. Maybe making drawsBackground() public and overriding it in StyledText to return false could be an option? > > Please note also bug#522103 and bug#525976. The first will improve Show > Whitespace, the second the overall Cocoa performance.
> Maybe making drawsBackground() public and overriding it in StyledText to > return false could be an option? Good idea! I will open another bug and provide a patch. protected visibility is enough.
I have opened bug#526257 to implement Till's proposal. It does not harm, but the effect is just minimal. I observed that fillBackground is still processed many times (now except for StyledText) and calls fillRect, furher eating valuable time. While looking at the call stacks I recognized that fillBackground isn't called when controls have style SWT.NO_BACKGROUND (see Composite#drawBackground). Many composites are created with SWT.NONE and therefore will draw their background. I tried applying SWT.NO_BACKGROUND for some Composites that are created with SWT.NONE while opening an editor. The effect is that I still do not see any difference in behavior. The editor works fine with both classic and dark theme while being faster overall. Composites might be instantiated with SWT.NONE for convenience without knowing about this performance implication. So it might be worth to carefully have a look where SWT.NO_BACKGROUND is a valid style for a created Composite. Since this is not directly related to Cocoa then, I'm expecting a benefit for other OS also. Your ideas?
With bug#526293 I have applied SWT.NO_BACKGROUND to some controls that are created for the Java editor. To see how it behaves see this video https://youtu.be/n6f6ybnNQcw The video was created on a Thunderbolt display at 2560 x 1440. Actually Eclipse is running in debug mode, so this consumes also slightly time. But I think performance is quite sufficient.
Your video didn't show any stats or real feel to me. One test had 36 visible vertical lines, another blurry one looked like 70 lines. I run with 280 vertical lines. At those small resolutions, the feel of eclipse is useable mostly. Its when you go with a larger screen and maximize the text editor that you really get the slow down. The external display, try it sideways (use the displays control panel and rotate it 90), that way you can get what I consider a medium screen size to test on. So the subjective speed your seeing may not be anything useful once the window is scaled much larger. Can you use Eclipse 3.4 as a benchmark for a fast eclipse versus your changes now so we can see the difference? Just set your keyboard repeat on fastest if not and do the simple arrow scrolling test once the cursor is at the bottom. Measure what you get in eclipse 3.4 versus what you get now, or what you get in the stock 4.7 eclipse. Scroll for 30 seconds, how many lines did it scroll? How much are the changes affecting things? (measurable numbers) Or if you have a device with inertial scrolling, do some fast flicking back and forth so see how well it can keep up? (I prefer the more measurable scrolled lines test though.) Thanks, Ben
Compared 4.7.1a with patched Photon with 240 lines on vertical display now. The patches aim to reduce the time taken for filling rects, so this is where some effect is measurable. It is always tip of the iceberg what can be cut off, there will be other places to improve. You can see a direct relationship between the time difference in fillRect to the others. Oxygen.1a Photon NSApplication#nextEventMatchingMask 6.192 5.313 Widget#drawRect 5.817 4.705 Control#fillBackground 1.169 322 NSBezierPath#fillRect 1.103 322
I had to return the Mac I borrowed, but I figured I'd update this bug with the result of my investigation. The problem with the event queueing is almost certainly being caused by the fact that sel_nextEventMatchingMask_untilDate_inMode_dequeue_ is invoking sel_drawRect_. It shouldn't be doing that. The nextEventMatchingMask ObjectiveC method is just supposed to extract an event from the queue - not force a synchronous paint. The docs on the OSX painting algorithm are pretty clear on this - OSX uses pretty much the same dirty-and-then-paint-later approach used by every other platform, and they say explicitly that paints aren't supposed to run until all the outstanding input events are processed. So SWT is doing something funky that is breaking the normal OSX event loop, and IMO the next step would be to try to reproduce this behavior in a vanilla ObjectiveC app using XCode - outside Eclipse (since it's possible the XCode debugger will allow stepping into the nextEventMatchingMask method or provide more information about what it's doing). Alternatively, we could disassemble the nextEventMatchingMask method to figure out how control is ending up in drawRect. We won't fix this bug until we understand why this is happening. The problematic behavior happens inside the OSX native bits -- although I suspect Eclipse is misconfiguring something (Running the event queue on the wrong thread? Misconfiguring one of the OSX callbacks? Adding an event queue observer that is misbehaving?), the actual problem occurs inside the OSX native bits which you can't step into using the Eclipse debugger. To those of you investigating this using profilers: optimizing the paint events is certainly a useful thing to do, but it won't fix this bug. To fix this bug, we need to prevent paints from running synchronously from within nextEventMatchingMask.
(In reply to Stefan Xenos from comment #337) > Alternatively, we could > disassemble the nextEventMatchingMask method to figure out how control is > ending up in drawRect. We won't fix this bug until we understand why this is > happening. This technique might help: https://stackoverflow.com/questions/27849384/xcode-lldb-can-lldb-break-on-the-calling-function Put a break on drawRect but only if the call stack contains nextEventMatchingMask.
Created attachment 271753 [details] Screenshot: Suppress call drawRect when nextEventMatchingMask on stack (In reply to Steve Green from comment #338) > Put a break on drawRect but only if the call stack contains > nextEventMatchingMask. Steve, interesting find. I tried it, but unfortunately it does not work. There are many repaint failures when this technique is applied (see screenshot). Sorry, good idea, but not working for us.
Not sure if this helps, but I put a breakpoint on DrawRect and then scrolled. This is the stack trace: * frame #0: 0x00007fff2b013c03 AppKit`-[NSView drawRect:] frame #1: 0x0000000128c8787f libswt-pi-cocoa-4825.jnilib`Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSendSuper__Lorg_eclipse_swt_internal_cocoa_objc_1super_2JLorg_eclipse_swt_internal_cocoa_NSRect_2 + 287 frame #2: 0x000000011443f05c frame #3: 0x00000001168209c0 Admittedly I don't know enough about the ObjC bridge or the internals of SWT to make sense of this.
New Gerrit change created: https://git.eclipse.org/r/119190
(In reply to Eclipse Genie from comment #341) > New Gerrit change created: https://git.eclipse.org/r/119190 This patch removes the call to runPaint() in display.readAndDispatch(), the setNeedsDisplay and setNeedsDisplayInRect callbacks and the NSMutableArray instances (Display.isPainting, needsDisplay and needsDisplayInRect). From the history, it was added to fix cheese in code-assist popup (Bug 266206). I tested the patch with a self-hosted eclipse and it results in a big improvement in scrolling lag. I was not able to see any painting issues with the code-assist popup, but it still requires more testing to make sure that there are no other painting issues introduced by this.
Any speed comparison measurements that can be done? or some way I can get a copy of your compiled eclipse for me to test here on large monitors and I will report back on speed changes? I use 280 visible vertical lines of text in my test and use the keyboard repeat rate at max and let it go with the cursor at the bottom to see what it does. Let us know!
I downloaded a tarball of the code change and tried to run Maven on it, but there's a lot more to it than that. Is there a guide for building SWT somewhere? If so, my Google-fu is broken today. Thanks, -Brian
Gerrit change https://git.eclipse.org/r/119190 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=bb1ea18b584ec1a364834b3fa0ae316c1f8453a1
I've pushed the patch to master and it'll be available in tomorrow's I-build. I'll post the link to the build once it's there. The patch improves the lag seen while scrolling by removing the runPaint() and callbacks which were called from readAndDispatch(). It also improves the scroll speed while scrolling with the trackpad. However, I wasn't able to notice any difference while scrolling with key-down.
The changes are in the build -> http://download.eclipse.org/eclipse/downloads/drops4/I20180313-2000/download.php?dropFile=eclipse-SDK-I20180313-2000-macosx-cocoa-x86_64.dmg Please try it out.
Sad to report I don't see really any difference. Its still terrible in scrolling compared to Eclipse 3.4. How many lines visible to you have? 80? its going to be hard to see the effect so much with so few lines visible. I have 280 in eclipse 3.4...and only 262 fit in 4.8. So it has less work to do even. I can still flick my trackpad a few times and sit back and watch the show as it continues catching up. I just did a simple test at that and had a 4 second show of scrolling activity after I was done flicking. The frame rate was also terrible obviously during this time...there was no fluidity in anything going on. Updated numbers: This build: 407 lines scrolled in 60 seconds, 262 visible lines, 296 wide. Eclipse 3.4: 698 lines scrolled in 60 seconds, 280 visible lines, 291 wide. TextWrangler: 285 lines scrolled in 60 seconds, 285 visible lines. Xcode 9.2: 1721 lines scrolled in 60 seconds, 233 visible lines (it auto line wraps) Sublime 3: 1713 lines scrolled in 60 seconds, 247 visible lines (including its text map view) So not really any noticeable change I can see. And comparing to others, eclipse is terrible...Sublime was amazing. I had no idea how nice it was. The frame rate, the scrolling accuracy, the responsiveness...my first item ever using it. I was blown away. So hard going back to the eclipse editor. Its interesting to see TextWrangler struggling so much...it was surprisingly bad. So no good news to report. If you ver think eclipse is doing good, just go check out Xcode or sublime and see what things should feel like. They have done scrolling and text handling fast. --Ben
Hi Lakshmi - When checking to see if it helps any in relation to this other bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=517446 I can see an improvement with your patch. I tested with: http://download.eclipse.org/eclipse/downloads/drops4/I20180327-2000/ It seems to bring performance back to Eclipse 4.6.3 levels, so not great, but better than 4.7.
I spoke too soon, the latest patch doesn't show any noticeable difference in relation to #517446.
Maybe worth to mention when having many lines on a screen: In StyledTextRenderer there is a cache for TextLayout with a fixed size of 128. This will be enough for most cases, but some are testing here with more than 200 visible lines. Maybe that cache should be dimensioned according to the expected maximum of visible lines on the display. Already mentioned before: One hot spot is TextLayout#computeRuns(). Is it possible to reduce the number of calls on this method somehow? I did not figure out how so far.
(In reply to Karsten Thoms from comment #351) > Maybe worth to mention when having many lines on a screen: In > StyledTextRenderer there is a cache for TextLayout with a fixed size of 128. > This will be enough for most cases, but some are testing here with more than > 200 visible lines. Maybe that cache should be dimensioned according to the > expected maximum of visible lines on the display. That would drive to improvements on all platform. I don't really know the reason why 128 was chosen back then. But since inception of the StyledText, the performance of machines have increased and we very likely be able to increase this cache to a higher value without too much risk. It's definitely a track to follow!
Can anyone make a new build with all the prior fixes too and changing this to a larger number to try out? Eclipse 4.8: 136 visible lines, 984 lines in 60 seconds 119 visible lines, 1238 lines in 60 seconds Eclipse 3.4 136 visible lines, 910 lines in 60 seconds 119 visible lines, 1078 lines in 60 seconds Based on my quick tests, just having the smaller window made eclipse faster, similar to the old eclipse. But I don't think it appeared to be a difference in using the cache for all the screen versus not. So I doubt a larger cache is going to help anything. Otherwise I would have expected significant differences when cache was used versus not. --Ben
I couple days with SWT code. Problematic is how canvas are implemented in SWT. In cocoa developers shouldn’t play with scrolls like on another toolkits (size, speed etc). Rather than should set NSScrollView size and leave everything for system. Currently I have no idea howto fix this without BC. SWT simulate some scrolls behavior and decide which view part should be rendered.
Re: comment 339 We can't suppress the paints that occur during nextEventMatchingMask - they need to be deferred until the next normal repaint or repaint bugs would be expected. Disabling them entirely should let us verify the performance of a potental fix, however. Re: comment 342 I must be missing something (my OSX knowledge is not very strong), but is this patch somehow related to the repaints we were seeing inside nextEventMatchingMask? If so, how? To those of you having difficulty reproducing this bug, follow my steps in bug 526395, comment 2. "Create a vertically-scrolling control containing a widget with a custom paint callback (that gets invoked from drawRect). Insert a call to Thread.sleep() inside the paint callback to artificially slow down the paints. Then rapidly scroll the control up and down using the mouse wheel. If you're reproducing the bug, you'll see considerable input lag - after you stop scrolling the mouse, the control will continue to scroll up and down for a long time. The expected behavior (after the fix) would be that the control paints slowly (due to the sleep), but input events won't lag for more than 1 repaint." I just stuck a Thread.sleep call in a paint callback that was already high up on the profiler output. This should reproduce the input lag on any system, regardless of the screen resolution or number of visible lines.
Moving to 4.9. It can be re-targetted to 4.8 if someone is has a fix.
Bug 526395 comment 4 has a really useful stack trace. It seems to suggest that SWT has a run loop observer that is triggering synchronous paints as a side-effect of running in a transaction. There's probably not a lot of run-loop observers in SWT, so we can probably use this to find the place where it's registered (and the bug).
New Gerrit change created: https://git.eclipse.org/r/133428
Woah! Awesome news! Which build will have this, I want to help test it.
(In reply to Srecko Toroman from comment #359) > Woah! Awesome news! Which build will have this, I want to help test it. 4.11 I-Builds are not there yet. Look for them at https://download.eclipse.org/eclipse/downloads/ after the 4.10 release this week. Note that it is "just" one improvement esp. when having Show Whitespace on, not a complete solution.
(In reply to Srecko Toroman from comment #359) > Woah! Awesome news! Which build will have this, I want to help test it. You can use https://download.eclipse.org/eclipse/downloads/drops4/I20181216-1800/
Did my same test as always, 262 visible lines on vertical 4k display, but I never have had show white space enabled. Arrow key down while on the bottom line for 60 seconds. i20181216-1800 262 lines: 659 Baseline Eclipse 4.8 262 lines: 708 So its getting closer...but still terrible compared to other editors...they are in the 1700+ lines for the same test. With whitespace enabled, maybe it improved...but not a scenario I have ever used in any version. --Ben
I'm removing the target as no-one can currently commit in fixing it for next release.
Can someone test with latest I-Build https://download.eclipse.org/eclipse/downloads/? It contains several patches which should improve interactive performance.
Does not improve anything that I can see. 60 seconds scrolling with arrow key on fastest repeat. Started from last visible line. MacOS 10.12.6 Eclipse 3.4, my baseline: 280 vertical lines visible. 661 lines scrolled CPU usage around 30% across all 6 physical cores Eclipse I20190912-180 282 vertical lines visible 455 lines scrolled. CPU usage around 16% across all 6 physical cores
And just for reference, so the target is not to make it a little better, but it should be to get close to a good editor like Sublime... Xcode 9.2, 267 visible lines, 498 scrolled Sublime 3.2.1, 284 lines visible, 1695 lines scrolled!!!
I tested the eclipse-SDK-I20190912-1800-macosx-cocoa-x86_64.dmg build on macOS Mojave 10.14.5. My keyboard repeat rate was set to the fastest, and the delay-until-repeat was set to the shortest. I opened the java.util.Collections source as the text to scroll through in the editor and maximized the editor to take up most of the Eclipse window, and then made the Eclipse window as tall as I could with it still fitting in my display and with the Dock visible. With 90 lines visible (Menlo 12 pt font at Preferences > General > Appearance > Colors and Fonts > Basic > Text Font), the cursor starting on line 90, and holding down the down-arrow key for 60 seconds, I get to line 902 for a total of 812 lines scrolled. With 315 lines visible (Menlo 3 pt font [yes, really small] at Preferences > General > Appearance > Colors and Fonts > Basic > Text Font), the cursor starting on line 315, and holding down the down-arrow key for 60 seconds, I get to line 999 for a total of 684 lines scrolled. Since Ben Spink gave a timing for Xcode and Sublime, I thought I'd try Vim, so with Vim 8.1.1999 in iTerm2 3.3.1 editing the Java 7 java.util.Collections source in a file named Collections.java with syntax highlighting enabled, with 263 lines visible (achieved by setting the iTerm2 font to Monaco 3 pt [yes, really small]), the cursor starting on line 263, and holding down the j key for 60 seconds, I get to line 2062 for a total of 1799 lines scrolled.
New Gerrit change created: https://git.eclipse.org/r/149547
Gerrit change https://git.eclipse.org/r/149547 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=58f91bfc319901c60999a9f6ac226d152fcde15d
If anybody out there has sluggish scrolling problems with eclipse (and probably IMAC 5k), there's a simple solution go to Applicatios right click on eclipse icon then click Get info and in this menu select `Open in Low Resolution'. Eclipse editor now scrolls smoothly!
If anybody out there has sluggish scrolling problems with eclipse (and probably IMAC 5k), there's a simple solution go to Applications right click on eclipse icon then click Get info and in this menu select `Open in Low Resolution'. Eclipse editor now scrolls smoothly!
Can someone test with latest I-build to see if the changes from yesterday improve your situation: https://download.eclipse.org/eclipse/downloads/
(In reply to Lars Vogel from comment #372) > Can someone test with latest I-build to see if the changes from yesterday > improve your situation: https://download.eclipse.org/eclipse/downloads/ But don't get your hopes too high. Scrolling speed depends on many factors; that change only improves one little aspect. (Speeds up the drawing of line numbers somewhat. So I'd expect no effect at all if line numbers are off.) Would still be interesting to know what effects other people observe with line numbers on. I could only test on two desktop Macs, both built-in 27" screen, one retina, one not. I don't have a 5k display available. (If testing, also always state how wide the editor is, not just how many lines are visible. The wider it is, the slower the scrolling in my experience, and that's definitely not changed by this commit. Also, there's sometimes a lag with updating line numbers; that's unrelated and it tracked in bug 543196.)
(In reply to Nikos Fazakis from comment #370) > If anybody out there has sluggish scrolling problems with eclipse (and > probably IMAC 5k), there's a simple solution go to Applicatios right click > on eclipse icon then click Get info and in this menu select `Open in Low > Resolution'. Eclipse editor now scrolls smoothly! Thanks for this tip! I tried the scenario from J. Lewis Muir: Open class collections with Menlo 3pt size and 315 visible lines. I don't get his slow speed, though. With default scrolling through the whole class (5598 lines) took 10,04s while holding page-down key. With the "low res" option set, scrolling took 7.16s (-28%). Similar results with 10pt size and 100 visible lines. I did not see a visual difference on my Thunderbolt display (2560x1440), nor on the MBP's Retina display. So what does "Open in Low Resolution" mean? I did not see any lower resolution, only a speedup. So it looks as a good step forward to enable this flag by default. WDYT?
(In reply to Karsten Thoms from comment #374) > took 10,04s while holding page-down key. Page-down or arrow-down? The slow scrolling speed is observed with holding the arrow-down key down. (Which, frankly said, is not a usecase for me, but maybe is a showcase of (too) slow scrolling that occurs in other more reasonable scenarios.)
(In reply to Thomas Wolf from comment #375) > (In reply to Karsten Thoms from comment #374) > > took 10,04s while holding page-down key. > Page-down or arrow-down? The slow scrolling speed is observed with holding > the arrow-down key down. (Which, frankly said, is not a usecase for me, but > maybe is a showcase of (too) slow scrolling that occurs in other more > reasonable scenarios.) I used page-down. With arrow-down performance is in both cases horrible. At 3pt size I came in 60s in both cases only to line ~650 (starting in line 1).
(In reply to Eclipse Genie from comment #369) > Gerrit change https://git.eclipse.org/r/149547 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > ?id=58f91bfc319901c60999a9f6ac226d152fcde15d This causes regression, see bug 551320.
(In reply to Karsten Thoms from comment #374) > (In reply to Nikos Fazakis from comment #370) > > If anybody out there has sluggish scrolling problems with eclipse (and > > probably IMAC 5k), there's a simple solution go to Applicatios right click > > on eclipse icon then click Get info and in this menu select `Open in Low > > Resolution'. Eclipse editor now scrolls smoothly! > > Thanks for this tip! I tried the scenario from J. Lewis Muir: Open class > collections with Menlo 3pt size and 315 visible lines. I don't get his slow > speed, though. With default scrolling through the whole class (5598 lines) > took 10,04s while holding page-down key. With the "low res" option set, > scrolling took 7.16s (-28%). Similar results with 10pt size and 100 visible > lines. > > I did not see a visual difference on my Thunderbolt display (2560x1440), nor > on the MBP's Retina display. So what does "Open in Low Resolution" mean? I > did not see any lower resolution, only a speedup. > > So it looks as a good step forward to enable this flag by default. WDYT? We are planning to remove the obsolete code via Bug 551341.
Thanks to Nikos for the tip with the low resolution. This allowed us to remove the code. J. Lewis Muir / Ben Spink or other interested people, could you measure tomorrows I-build from https://download.eclipse.org/eclipse/downloads/ and post the results here?
I should have been making the entire area being scrolled bigger since that is an important part of reproducing the slowness. Therefore, I've changed my test to include 200 visible columns. So now my test is as follows. I set the keyboard repeat rate to the fastest and the delay-until-repeat to the shortest. I open the java.util.Collections source as the text to scroll through in the editor and maximize the editor to take up most of the Eclipse window, and then I make the Eclipse window as tall as I can with it still fitting in my display and with the Dock visible. Then I ensure that 200 columns are visible in the editor by enabling the print margin at Preferences > General > Editors > Text Editors > Show print margin and by setting the print margin column to 200. Then I resize the window width until the print margin line is just on the left side of the scroll bar on the right. In Eclipse 4.13 with 89 lines visible (Menlo 12 pt font at Preferences > General > Appearance > Colors and Fonts > Basic > Text Font), the cursor starting on line 89, and holding down the down-arrow key for 60 seconds, I get to line 515 for a total of 426 lines scrolled. In Eclipse 4.13 with 311 lines visible (Menlo 3 pt font at Preferences > General > Appearance > Colors and Fonts > Basic > Text Font), the cursor starting on line 311, and holding down the down-arrow key for 60 seconds, I get to line 737 for a total of 426 lines scrolled. In eclipse-SDK-I20190926-0625-macosx-cocoa-x86_64.dmg with 89 lines visible (Menlo 12 pt font at Preferences > General > Appearance > Colors and Fonts > Basic > Text Font), the cursor starting on line 89, and holding down the down-arrow key for 60 seconds, I get to line 811 for a total of 722 lines scrolled (~1.7 times faster than 4.13). In eclipse-SDK-I20190926-0625-macosx-cocoa-x86_64.dmg with 313 lines visible (Menlo 3 pt font at Preferences > General > Appearance > Colors and Fonts > Basic > Text Font), the cursor starting on line 313, and holding down the down-arrow key for 60 seconds, I get to line 991 for a total of 678 lines scrolled (~1.6 times faster than 4.13). For reference, I also tried Vim on Collections.java with syntax-highlighting enabled inside iTerm2 with iTerm2 anti-aliasing enabled and with the window size set to that of the Eclipse frame. In iTerm2 3.3.3 with Vim 8.1.2050 with 76 lines visible (Monaco 12 pt font), the cursor starting on line 75, and holding down the j key for 60 seconds, I get to line 1862 for a total of 1787 lines scrolled. In iTerm2 3.3.3 with Vim 8.1.2050 with 264 lines visible (Monaco 3 pt font), the cursor starting on line 263, and holding down the j key for 60 seconds, I get to line 2040 for a total of 1777 lines scrolled.
Thanks J. Lewis Muir for the detailed testing. A factor of 1.6 - 1.7 sounds like a great achievement even though other editors are still much faster. If I takes Bens numbers multiplied by this factor, 4.14 is finally faster than 3.4 in scrolling. Unless someone has an idea or is working on another patch to make scrolling faster, I would suggest to close this bug as fixed and open new once if we discover more areas to improve. This bug is already 8 years old and there is no value in keeping it open, unless we still know areas of improvement.
My results: 3.4.2: Build id: M20090211-1700 280 visible lines, 291 columns 690 lines scrolled in 60 seconds 4.14: Build id: I20190926-0625 282 visible lines, 302 columns 640 lines scrolled in 60 seconds So I agree that is fairly close to 3.4 speeds. Still not fast, responsive, or snappy in any way...but at least its maintaining the existing speed that we had 8+ years ago. I guess this bug can be closed.
Thanks everyone for working on this issue. Please open new bugs, if you are aware of more areas to improve or if performance gets worse again.
Great to see this resolved! Thanks everyone!
*** Bug 543196 has been marked as a duplicate of this bug. ***
The drawText caching here is causing bug 568777 ..
