The performance of the editor is very poor when these conditions are met:
- Java 7u40 and higher
- OS X
- Netbeans is displayed on retina display (Macbook Pro)
Scrolling, for instance, is nearly unusable in this situation. Scroll redraws lag seconds behind the user's actions, making it very difficult to control the editor.
Note that, on the same machine running on an external non-retina display, performance is fine. It is only when displaying to the retina display that the performance degrades.
Also note that, on the same machine, text displayed in a similar Java application (Eclipse for example) has no performance degradation on the retina display.
That's why I had to switch to another editor. At least until this bug is fixed. Netbeans on retina display in almost impossible to use. I can confirm that on external display it performs much better then on retina display on the same computer. Typing, scrolling, even resizing the application is very slow on retina display.
I don't see any noticeable performance issues in
Product Version: NetBeans IDE 7.4 (Build 201310111528)
Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08
Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18
System: Mac OS X version 10.9 running on x86_64; UTF-8; en_US (nb)
Reporter, what version of OS X are you running?
Same specs as what you listed. What hardware are you testing on? It's important to be running on a retina display, and to have the resolution scaled to the highest setting.
My hardware is a 2012 MacBook Pro 13".
I have 15" MacBookPro with Retina display, early 2013. No performance issues even when display settings are scaled to the highest resolution.
Please try running SwingSet demo or some other plain Swing app to see if it's reproducible there.
Also do you have Apple JDK 1.6 installed on your machine?
I ran the SwingSet3 demo. Scrolling performance in the main text areas is fine. Scrolling in the GUI Components pane on the left is sluggish, however, similar to the issues with Netbeans. I'm not sure that indicates anything in particular, but perhaps its a clue.
I do have the Apple JDK 1.6 installed. However, I ran Netbeans 7.4 without it installed before installing it, and had the same issues.
The 15" MacBook Pro has a much more powerful Nvidia GPU, so perhaps the issue only manifests when using Intel integrated graphics. Perhaps its worth trying to force the integrated GPU using something like http://gfx.io.
Each pane in SwingSet demo has also a source tab with HTML formatted Java code, did you try scrolling it as well?
I tried running NetBeans with integrated graphics only and while the editor scrolling does seem a bit less smooth I didn't find any performance issue.
We can try taking this to JDK team but even Apple warns of possible performance issues when scaling the display to the highest settings.
There is no issue with scrolling the source code in the SwingSet demo on my machine. In fact, I have no text scrolling issues in any application, Java or otherwise, except for Netbeans. As I said, Eclipse is perfectly fine at all resolutions, even though it is using the same 1.7 JDK.
I am not alone in noticing this issue, its being echoed by others as well:
I'm guessing that this issue is only really extreme on the Macbook Pro 13" models, although I have only been able to test that model so I haven't been able to compare.
However, please believe us that this issue is bad enough that it makes Netbeans unusable for complex documents on the retina screen.
It isn't very scientific, but could someone who has both versions and is having this issue do a screen video capture? If a video capture interferes too much, anyone with a modern-ish point and shoot can do a slow-motion videotape-the-screen capture. (I once diagnosed screen judder in Netflix using an Canon Elph's slow-motion video, which helped to clearly see frames being lagged and reversed).
Any video camera that has a high enough frame rate should do the trick.
I'm on a Macbook pro 15", 2.7GZh, and I'm not seeing a huge difference, but it does feel slower.
Same problem! I have MPBr 13" - Same issue on both OS X 10.8 and 10.9, with Netbeans 7.3.1 and 7.4.
7.3 Worked great on OS X 10.8 but it doesn't launch now on OS X 10.9.
So, I don't have an alternative Netbeans version for now. :-(
(In reply to slavikme from comment #10)
> Same problem! I have MPBr 13" - Same issue on both OS X 10.8 and 10.9, with
> Netbeans 7.3.1 and 7.4.
> 7.3 Worked great on OS X 10.8 but it doesn't launch now on OS X 10.9.
> So, I don't have an alternative Netbeans version for now. :-(
I'm confused, are you confirming that you are experiencing scrolling performance issues running Netbeans under Java 7? This bug isn't about launching Netbeans, it's specifically about scrolling performance under Java 7 on retina screens. When you upgrade to 10.9, you have to install Java again or Netbeans won't launch. Have you done that?
(In reply to markedwards from comment #11)
> I'm confused, are you confirming that you are experiencing scrolling
> performance issues running Netbeans under Java 7? This bug isn't about
> launching Netbeans, it's specifically about scrolling performance under Java
> 7 on retina screens. When you upgrade to 10.9, you have to install Java
> again or Netbeans won't launch. Have you done that?
Yes I'm experiencing the same issue, extremely slow on scrolling, typing, navigating with arrows.
Yes, I did upgrade the Java version.
About the Netbeans 7.3 launch, I figure it out, when I started it the size of the Netbeans' window was nearly zero.
But now I see, that even with Netbeans 7.3 I'm experiencing the slowness.
After updating MacOS on my retina macbook pro to
System Version: OS X 10.9 (13A603)
Kernel Version: Darwin 13.0.0
Netbeans was unable to start, so i updated java and netbeans.
Now I have better looking editor (crystal precision) but laggy scrolling. Not fun to code like this.
Product Version: NetBeans IDE 7.2.1 (Build 201210100934)
Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08
Created attachment 142618 [details]
Screen cap of jumpy scrolling on retina mbp
This video shows the lag when scrolling but it is present with all user input (typing!) to the point of being unusable.
Created attachment 142619 [details]
Screen cap of scrolling on external monitor / same machine
Low quality (for file size) but I am sure everyone else knows how NB is supposed to scroll. This is just to demonstrate when moving the NB window to the external monitor the scrolling & other input returns to normal on the same rMBP.
+1 on this. I am on a brand new Haswell 13" rMBP and I have this problem so I think you can discount graphics card performance as the cause. I could live with the laggy scrolling if typing was responsive. The latency when typing can be in the order of seconds, particularly when switching focus. It seems to catch up if you stay in one place and type continuously, but when you switch to another file or even a different place it takes some time to figure out what is going on.
This is a JDK bug. The problem is reproducible with a plain Swing app with a JTextPane - when the text pane has a lot of text simple editing/deleting the text to scroll the pane makes the CPU usage go over 100% on a retina display (MacBook Pro).
The same app on the same machine on external display scrolls just fine with CPU usage under 50%.
Reported as JDK bug https://bugs.openjdk.java.net/browse/JDK-8029253
Reporters, please provide some profiler snapshots so the JDK team can analyze the problem. Attach the snapshots either here or directly to the JDK issue.
Created attachment 142655 [details]
NB CPU profile, scrolling and typing on retina display
1 of 2. Hope these help, here is the snapshot on the retina display.
Created attachment 142656 [details]
NB CPU profile, scrolling and typing on external display
2/2. Scrolling and typing when NB window is on external display on retina Macbook Pro.
Also, relative resolutions:
Retina: 2560x1600 -> Scaled (looks like 1680x1050)
Can somebody confirm that the same freezes occur on jkd8 as well?
(In reply to serb from comment #22)
Yes. Exactly the same in b117. Can attach profiler snapshot but it is identical to jdk7
sun.java2d.opengl.OGLRenderQueue.flushBuffer[native]() 28.76976 19,732 ms (28.8%) 19,732 ms 19,732 ms 19,732 ms
> Can somebody confirm that the same freezes occur on jkd8 as well?
The same - slow scrolling...
MacbookPro 15 Retina, late 2013, Mavericks 10.9.1, Netbeans 7.4
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
AD: resolution: retina, 1680x1050, 1920x1200
I have this problem too.
(In reply to saeed_z_f from comment #26)
> I have this problem too.
It's a problem in JDK which cannot be fixed in NetBeans, please vote for the JDK issue.
I have MacBook Pro late 2011 with 10.7.5 NetBeans 7.4 and scrolling through my code is awful and ugly. It is not "sweet" if you get what I mean. I got the need to switch to other editors to work comfortably.
I haven't installed any new plugin.
Please fix it.
I would update a screencast but I see that others covered that part just fine. However, mine seems a bit more laggy than others.
Sorry, I just saw that it is reported as a JDK issue. I see you say that it has to do with Retina display, but I do NOT have a retina screen (MacBookPro late 2011). Additionally, when I run Eclipse IDE, this problem is not reproduced. What's going on then?
If you need any reports or any clarifications, just let me know.
(In reply to YannisDR from comment #29)
> Sorry, I just saw that it is reported as a JDK issue. I see you say that it
> has to do with Retina display, but I do NOT have a retina screen (MacBookPro
> late 2011). Additionally, when I run Eclipse IDE, this problem is not
> reproduced. What's going on then?
> If you need any reports or any clarifications, just let me know.
File a new issue then and leave this one closed, thanks.
Follow-up link for anybody wants to see the bug for no Retina-display issue.
Seems Retinas have nothing to do with this problem.
Ok. There has been a bit of activity on the JDK on this issue but it is a little out of my depth. What I did gather from this is that it is possible to toggle swing.volatileImageBufferEnabled and get better scrolling performance. The eventual fix hopefully will be fast and smooth but adding this switch to the netbeans.conf seems to remove the lag. The unfortunate side effect is the fonts get fuzzy. Pick your poison.
To apply this, add the following to netbeans_default_options in Netbeans.app/Contents/Resources/Netbeans/etc/netbeans.conf
Turning off swing.volatileImageBufferEnabled on my 13" late 2013 retina MBP doesn't fix the slow scrolling for me.
I guess the correct way to pass the command is like this:
However, this did not fix the problem for my NON-Retina 17 inch macbook pro.
I repeeat, this bug has NOTHING to do with Retina screen.
It would be helpful for us trying to use netbeans on retina 13" macbook pro to know if there's actually any progress in getting this issue resolved internally at Oracle.
From our viewpoint it appears netbeans is deferring the issue to the JDK group, which is deferring the issue indefinitely. Is our only option to change to a different IDE than netbeans?
So what's going on with this bug? I have the same poor, nearly unusable editor performance on a MBP 13 Retina Late 2013 with OS X 10.9.2. It makes no difference whether i use Netbeans 7.4, 8.0 or JDK7 or JDK8u20.
Other Java based IDEs work as well. Is the Netbeans dev-team investigating this issue or do we have to switch the IDE? Would be a pity.
It would be better for you to switch IDE, as the bug isn't in priority. (P2 Class).
Also it is reported as a JDK bug
(while other IDEs with similar build perform very well)
See comment #17:
(In reply to YannisDR from comment #34)
> I guess the correct way to pass the command is like this:
> However, this did not fix the problem for my NON-Retina 17 inch macbook pro.
> I repeeat, this bug has NOTHING to do with Retina screen.
Then you need to file a new bug report and attach profiler snapshots.
(In reply to Stanislav Aubrecht from comment #38)
> (In reply to YannisDR from comment #34)
> > I guess the correct way to pass the command is like this:
> > netbeans_default_options="-J-Dswing.volatileImageBufferEnabled=false"
> > However, this did not fix the problem for my NON-Retina 17 inch macbook pro.
> > I repeeat, this bug has NOTHING to do with Retina screen.
> Then you need to file a new bug report and attach profiler snapshots.
Got it already since comment 30. See comment 31.
What's the reason to keep retina and non-retina bugs separated if it is under the same issue? That's way too strange imho.
Same problem here, what a shame :/
Macbook pro retina 13" i5, Intel 4000HD, NetBeans 8, JDK 8u5.
Very bad performance, scroll and typing is laggy, apsolutely can't work in these conditions...
JDK 9 build b13 completely fixes this issue on Haswell 13" Retina Macbook Pro. Perfectly smooth scrolling and typing. I assume relevant fix will show up in 8u20 shortly.
Note, you need to remove -XX:MaxPermSize from the command line switches in netbeans.conf to get NB to start on JDK9. Everything is working just fine for me.
Just tried jdk 9 build b15 (Java: 1.9.0-ea; Java HotSpot(TM) 64-Bit Server VM 1.9.0-ea-b15), with no noticeable scrolling improvement in NB8 on my late 2013 retina MBP. I also tried with b13, with the same results.
Are there any special command line switches that are needed?
Btw the download for jdk9 can be found here for those interested: https://jdk9.java.net/download/
(In reply to grantjennings from comment #41)
> I assume relevant fix will show up in 8u20 shortly.
See comments in the JDK bug:
Not yet fixed in jdk9. Doesn't look like it will make jdk8u20.
Is there any progress within this issue? Slows down my work every day :(
NB 8.0.1 / Using MacPro End 2013 / OSX 10.10 / 2 x NEC EA244UHD
I see a great performance improvement if i remove -J-Dapple.awt.graphics.UseQuartz=true and -J-Dsun.java2d.dpiaware=false from netbeans_default_options.
NetBeans IDE 8.0.1 (Build 201408251540)
Runtime: Java(TM) SE Runtime Environment 1.7.0_67-b01
Mac OS X version 10.10 running on x86_64; UTF-8; sl_SI (nb)
MBP 13 retina
If you're waiting for this fix, you can monitor the releases at https://jdk9.java.net/download/ and see which issues are marked as released in the 'summary of changes' document. If you're really eager, you can find the releases usually a week in advance here; http://download.java.net/jdk9/archive/. They are usually added there on fridays, then put up on the download page the week after.
You'd want to look for this bug id: 8029253, and possibly this one: 8023794 which is related to subpixel rendering.
The JDK release here http://download.java.net/jdk9/archive/b38/binaries/jdk-9-ea-bin-b38-macosx-x86_64-05_nov_2014.dmg supposedly contains the OSX retina performance fix.
It doesn't really seem to provide any noticeable speedups at all really.
NetBeans IDE 8.0.1 (Build 201408251540)
Runtime: Java(TM) SE Runtime Environment 1.9.0-ea-b39
Mac OS X version 10.10.1 running on x86_64; UTF-8; en_US (nb)
MBP 15 retina Mid 2012
also tried 1.8.0_25 and some previous version, improved but not sloved.
I think there's something else that is wrong. Try putting this gist into a file with an html extension and view it in netbeans; https://gist.github.com/iampivot/5b68b3735ec71cb8ce16
It renders very slowly, when scrolling I get an update every other second or so using either integrated or discreete graphics on my 15" MBP retina.
Intellij using either jdk1.9_b39 or jdk 1.6 scrolls the same file prefectly smooth.
Created attachment 150502 [details]
.npss file attached from NetBeans
I tried scrolling tveimo's test HTML file up and down for a while on a non-retina MacBook Air with retina simulated at the "720x450 (HiDPI)" resolution (see http://stackoverflow.com/questions/12124576/how-to-simulate-a-retina-display-hidpi-mode-in-mac-os-x-10-8-mountain-lion-on ). Even though only 16 lines of text were visible in the editor at this resolution, scrolling was very sluggish. I just attached the profiling snapshot of this test.
Product Version: NetBeans IDE 8.0.1 (Build 201408251540)
Updates: NetBeans IDE is updated to version NetBeans 8.0.1 Patch 1.1
Java: 1.8.0_25; Java HotSpot(TM) 64-Bit Server VM 25.25-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_25-b17
System: Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
User directory: /Users/ebakke/Library/Application Support/NetBeans/8.0
Cache directory: /Users/ebakke/Library/Caches/NetBeans/8.0
I seem to be able to reproduce this, or a related problem, even under non-retina conditions in my NetBeans Platform-based application. I have two editors using the same underlying swing Document, so that when the text is modified in one editor, the change is immediately reflected in both editors. If there are a lot of tokens in the string (as returned by my own custom org.netbeans.spi.lexer.Lexer implementation), typing is extremely sluggish. However, if the exact same content is tokenized as a single token (by modifying the Lexer implementation), the problem disappears.
Like when scrolling tveimo's test HTML file on a retina display, the event thread spends most of its time in sun.java2d.opengl.OGLRenderQueue.flushNow(). The stack trace of the expensive calls is similar; the calls to flushNow() originate from HighlightsViewUtils.paintHighlighted().
Could something be messing up coalescing of repaints during text rendering under certain conditions (such as having a retina display, or in the example above, having two editors that ask to repaint simultaneously)?
(Not sure if this is helpful at all, but I thought I'd report my findings just in case...)
(In reply to tveimo from comment #51)
> I think there's something else that is wrong. Try putting this gist into a
> file with an html extension and view it in netbeans;
> It renders very slowly, when scrolling I get an update every other second or
> so using either integrated or discreete graphics on my 15" MBP retina.
> Intellij using either jdk1.9_b39 or jdk 1.6 scrolls the same file prefectly
Please file a new bug against editor component and keep this one closed, thanks.
Try update your JDK to 8u40 Build b20 in https://jdk8.java.net/download.html . After I updated, the performance is much better.
I have tried updating to JDK 8u40 b20 and it has no effect. Netbeans is still unusable for me on my MBP 2014 13".
I've had to move over to PHPStorm and fork out the $99.
(In reply to agungsuyono from comment #56)
> Try update your JDK to 8u40 Build b20 in https://jdk8.java.net/download.html
> . After I updated, the performance is much better.
Unfortunately it's not.
I've just installed 8u40_b23 and it's no better. Nothing has changed since I got my Retina MacBook Pro back in 2012, now I'm on a 5k iMac which has the same issue.
If there's any debug output I can provide that will help fix this then please let me know. I'm desperate to use my 5k iMac in all its glory instead of disabling HiDPI mode.
Even with the fix, which is now in jdk9, which you can download here; http://download.java.net/jdk9/archive/ the editor is marginally faster.
The editor is still very slow, depending on the complexity of the text being rendered, see eg. the associated issue; https://netbeans.org/bugzilla/show_bug.cgi?id=249052
I've switched to intellij myself, you might end up waiting a year or two before netbeans work well enough on a retina screen.
Really, is switching to IntelliJ the only option ?
Try jdk 9 first, to see if it's better for your use case. Any slowness with jdk 9 needs to be addressed as different issues, since this issue is resolved. The fix may eventually be backported to jdk 8.
And please vote for bug https://netbeans.org/bugzilla/show_bug.cgi?id=249052
it is fixed in 9 (b38) and 8u45.
Great to see some Retina-related bugfixes--markiewb's links didn't work for me (maybe it requires a login to the JDK bug system), but here are the corresponding JIRA pages:
I'll try tveimo's HTML file scrolling test as soon as JDK 8u45 becomes available.
Tried jdk 1.9.0-ea-b49 with netbeans 8.0.2 on Retina 5k and Mac OS X 10.10.2
No change for me. Scrolling is still slow.
Do you have used some additional JVM params or something like this ?
(In reply to markiewb from comment #63)
> * http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8029253
> * http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8067572
> it is fixed in 9 (b38) and 8u45.
I'm using NetBeans 8.0.2 on MBP 15" Mid 2014 and the problem is not fixed!
The editor is unusable on the Retina display. Currently I use JRE 1.8.0_40-ea-b23 but I also tried JRE 1.9.0-ea-b49 with small changes, still no luck, scrolling is lagging and even writing text appear few milliseconds later.
I'm also happy to provide more debugging information.
Please fix this, it is very frustrating. Thank you!
According to latest investigation bone by ebakke and thurka we narrowed the problem into HTML file painting.
ebakke was able to reproduce the problem even on non Retina MacBook Air as shown in linked video http://youtu.be/9vMwZoPSI_o. Also .npss attached on 2014-11-15 shows this could be the problem with editor painting.
thurka verification shown the problem is not visible with java files.
In this HTML file https://gist.githubusercontent.com/iampivot/5b68b3735ec71cb8ce16/raw/0d0000e426e3e83e573ac9e865140bd1adc1a569/netbeans-retina-slow problem is visible when scrolling over long lines 1000+ chars.
This also happens on JDK 8 Upd 40 latest build.
Therefore reopening this for editor.
Created attachment 152241 [details]
HTML file used to verify editor slow scrolling.
Originally at https://gist.githubusercontent.com/iampivot/5b68b3735ec71cb8ce16/raw/0d0000e426e3e83e573ac9e865140bd1adc1a569/netbeans-retina-slow attaching to not loose it.
(In reply to Martin Balin from comment #67)
> According to latest investigation bone by ebakke and thurka we narrowed the
> problem into HTML file painting.
> ebakke was able to reproduce the problem even on non Retina MacBook Air as
> shown in linked video http://youtu.be/9vMwZoPSI_o. Also .npss attached on
> 2014-11-15 shows this could be the problem with editor painting.
> thurka verification shown the problem is not visible with java files.
> In this HTML file
> 0d0000e426e3e83e573ac9e865140bd1adc1a569/netbeans-retina-slow problem is
> visible when scrolling over long lines 1000+ chars.
> This also happens on JDK 8 Upd 40 latest build.
> Therefore reopening this for editor.
Sorry, but on my Reina 5K Display java and groovy are slow too. It is not as slow as HTML but slower as on all other Workstations I use.
The Mac has the fastest CPU, but the slowest editing and scrolling performance.
barmeier, can you make a movie showing this, in the way that ebakke did: https://www.youtube.com/watch?v=9vMwZoPSI_o There is certainly no lack of desire to get this fixed, only the problem of reproducing the problem, which for each person that reports it could be different -- it's a matter of being able to reproduce it, ebakke's YouTube clip was perfect for that, showing the environment he uses and then the problem very precisely, together with profiling results.
And, when you reproduce the problem (ideally in a video like ebakke did), please use JDK 8u40 build b23 available here: https://jdk8.java.net/download.html.
(In reply to barmeier from comment #69)
> Sorry, but on my Reina 5K Display java and groovy are slow too. It is not as
> slow as HTML but slower as on all other Workstations I use.
> The Mac has the fastest CPU, but the slowest editing and scrolling
Can you please attach also some files where it is the most visible? In addition to what Geertjan asked for. And profiling the IDE for a while when scrolling will be also helpfull for us to get more data for fixing this. Please attach .npss. Thanks'
Pretty sure I'm affected too - when typing fast in a simple java file, letters are displayed really slow — like up to 1 second after keypress.
I tried updating to u40 from U25 from U20
Product Version: NetBeans IDE 8.0.2 (Build 201411181905)
Java: 1.8.0_40-ea; Java HotSpot(TM) 64-Bit Server VM 25.40-b25
Runtime: Java(TM) SE Runtime Environment 1.8.0_40-ea-b23
System: Mac OS X version 10.10.2 running on x86_64; UTF-8; en_US (nb)
User directory: /Users/ssch/Library/Application Support/NetBeans/8.0.2
Cache directory: /Users/ssch/Library/Caches/NetBeans/8.0.2
This did not change anything, so on to jdk9b51 - now NetBeans failed to start until I removed ‘-J-XX:PermSize=32m’ from netbeans_default_options in netbeans.conf, and it also didn’t change performance :(
I then installed a daily NetBeans build, which improved performance!!!!
Product Version: NetBeans IDE Dev (Build 201502260001)
jdk8u25 significant improvements when typing - but scrolling 300 lines of java code was still sluggish.
jdk8u40 slightly better scrolling (compared to u25) - tolerable - but not seemless..
jdk9b51 slightly better yet (compared to jdk8u25) - acceptable, but could probably be even better..
So - whatever improvement was done in NetBeans daily build, does seem to be the most effective fix to my issue at least - if possible I'd like it in the updates rather than to wait for NB9..
(In reply to ssch from comment #73)
> Pretty sure I'm affected too - when typing fast in a simple java file,
> letters are displayed really slow — like up to 1 second after keypress.
> I tried updating to u40 from U25 from U20
> I then installed a daily NetBeans build, which improved performance!!!!
> Product Version: NetBeans IDE Dev (Build 201502260001)
> jdk8u25 significant improvements when typing - but scrolling 300 lines of
> java code was still sluggish.
> jdk8u40 slightly better scrolling (compared to u25) - tolerable - but not
> jdk9b51 slightly better yet (compared to jdk8u25) - acceptable, but could
> probably be even better..
> So - whatever improvement was done in NetBeans daily build, does seem to be
> the most effective fix to my issue at least - if possible I'd like it in the
> updates rather than to wait for NB9..
Thanks' for info. Just to make it clear what is in daily builds will be part of NetBeans 8.1. Beta will be released in April.
To understand your setup for test you have NetBeans IDE Dev (Build 201502260001) on top of JDK 8 Upd40 b23?
Created attachment 152296 [details]
.npss file attached from NetBeans
(In reply to Martin Balin from comment #74)
> (In reply to ssch from comment #73)
> > Pretty sure I'm affected too - when typing fast in a simple java file,
> > letters are displayed really slow — like up to 1 second after keypress.
> > I tried updating to u40 from U25 from U20
> > I then installed a daily NetBeans build, which improved performance!!!!
> > Product Version: NetBeans IDE Dev (Build 201502260001)
> > jdk8u25 significant improvements when typing - but scrolling 300 lines of
> > java code was still sluggish.
> > jdk8u40 slightly better scrolling (compared to u25) - tolerable - but not
> > seemless..
> > jdk9b51 slightly better yet (compared to jdk8u25) - acceptable, but could
> > probably be even better..
> > So - whatever improvement was done in NetBeans daily build, does seem to be
> > the most effective fix to my issue at least - if possible I'd like it in the
> > updates rather than to wait for NB9..
> Thanks' for info. Just to make it clear what is in daily builds will be part
> of NetBeans 8.1. Beta will be released in April.
> To understand your setup for test you have NetBeans IDE Dev (Build
> 201502260001) on top of JDK 8 Upd40 b23?
Yes, that was one configuration - but I downgraded to update 31 to avoid any pre-release issues. My subjective observations were that things improved greatly once I were using the daily build of NB, and on top of that, each newer JDK release improved things slightly over the previous.
Looking forward to 8.1 :)
I'm sorry, but trying latest development versions does not improve scroll/typing lag for me :(
Product Version: NetBeans IDE Dev (Build 201503020001)
Java: 1.9.0-ea; Java HotSpot(TM) 64-Bit Server VM 1.9.0-ea-b52
Runtime: Java(TM) SE Runtime Environment 1.9.0-ea-b52
System: Mac OS X version 10.9.2 running on x86_64; UTF-8; en_US (nb)
Created attachment 152328 [details]
Snapshop with NB dev 201503020001 and JDK9
Here it is something interesting, using an external screen via HDMI presents normal scrolling/Editing speed. As fast as windows version.
(In reply to jmakuc from comment #79)
> Here it is something interesting, using an external screen via HDMI presents
> normal scrolling/Editing speed. As fast as windows version.
jmakuc, you external display is not probably retina/ultra HD?
(In reply to Martin Balin from comment #80)
> (In reply to jmakuc from comment #79)
> > Here it is something interesting, using an external screen via HDMI presents
> > normal scrolling/Editing speed. As fast as windows version.
> jmakuc, you external display is not probably retina/ultra HD?
That's right, is a regular LED display
@jmakuc if you read all the comments, you will see other people (including me) can confirm that scrolling works as expected on external screens, connected to the same MBP.
For me, it is practically unusable without another monitor.
Today I tried new available Java versions:
jre 8u40 release version
They all improved typing delay, but just a small improvement on the scroll, it is still clearly slower than on the external monitor.
I also tried the nightly build, NetBeans Dev 201503210001, with no noticeable difference, for me only the new java versions improved something.
I have the feeling the fixes in java just resolved some CPU problems when scrolling, our problem must be something related to NetBeans specifically.
I can also notice that maximizing the windows is lagging on the retina screen, while on the external screen is really snappy.
I will try to make a profiling file.
Just tried the idk 1.9 in iMac 5k. This problem still exist and editor is completely unusable.
Thank's to all for providing us the feedback on editor scroll performance.
We got enough info to narrow the problem. It is still the problem on high DPI displays, even with latest JDK 8/9 and latest NB development builds. We will attempt to fix this into NB 8.1.
Thanks for looking this, please keep the bug updated with build numbers where this issue is addressed so that we can try them out, please!
Just tried the suggested patch for jdk bug https://bugs.openjdk.java.net/browse/JDK-8087201, at http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/, with netbeans nightly , which speeds up rendering quite a lot, making it almost butter smooth on my 2014 retina nvidia gfx mbp. It's fast enough also when using the intel integrated gfx.
There's still some slowdown when rendering complex html markup, but that's covered in this bug: https://netbeans.org/bugzilla/show_bug.cgi?id=249052
I'd suggest closing this bug as wontfix and work on that bug instead.
Someone on earth, please say how to apply patch and fix it? I am using 8u45, on OS X 10.10.4 over a MacBook Pro 15" Retina (Mid May 2015)
I've posted a post on my blog on how to patch and build openJDK 9 on OSX; http://www.nothome.com/2015/07/subpixel-font-rendering-with-netbeans.html
*** Bug 253249 has been marked as a duplicate of this bug. ***
OpenJDK 9 b76 now contains the fix for bug https://bugs.openjdk.java.net/browse/JDK-8087201, so no custom build required for much faster scrolling speeds.
For me quick fix was to install the netbeans 8.1 beta and JDK 1.9 early access, then reconfigure the beta to use the newer JDK - e.g.
nano /Applications/NetBeans/NetBeans\ 8.1\ Beta.app/Contents/Resources/NetBeans/etc/netbeans.conf
then edit the path (first is the original value commented)
# netbeans_jdkhome="/Applications/NetBeans/NetBeans 8.1 Beta.app/Contents/Resources/NetBeans/bin/jre"
So definaly looks like the fix is in the pipeline - however the JDK version that ships with the beta *does not* work - you have to use 1.9 JDK.
thx a lot
As we do not have a fix for the problem on NB side yet I have to ask for the waiver for this issue for NB 8.1.
For the next NB versions we are experimenting with directly using GlyphVector for the rendering instead of the currently used TextLayout for non-bidi text rendering mainly for elimination of repetitive calls to TextLayout.draw() for multi-colored text. This should decrease the amount of data sent to the rendering pipeline. But the rewrite is not ready yet.
How did you manage to get Netbeans 8.1 to work with OpenJDK 9? Since JDK 9 has dropped tools.jar, (at least in my computer), once I install JDK 9 and tell Netbeans to use it, Whenever I try to compile any projet, I get the error:
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
you need to also have jdk 8 installed, and select this JDK in the project properties. There's a netbeans branch that is specifically for jdk 9, so this will not be needed in the future when that branch is merged in, most likely for netbeans 9.
After upgrading to El Capitan and having an actual jdk8 running scrolling and working with Java and Groovy files works much better.
For me this bug is not there when using El Capitan.
Netbeans 8.1 RC + updated JDK 8 on a retina Macbook Pro OS X 10.11 here.
Editor scroll speed is not as smooth as Eclipse or IntelliJ yet :(
Netbeans JDK9 Branch Development Version + JDK 9 fixed this problem. Actually this issue was fixed past JDK 9u38.
Performance getting a lot better on Netbeans 8.1 running on Java SE 8u65 / 8u66, on 13" Retina Macbook Pro OS X El-Capitan.
Scrolling is a lot smoother.
Confirmed. Installing Netbeans 8.1 with JDK 9 solved my problem.
I still have problems with the scrolling using netbeans 8.1 on an imac 5k .
Product Version: NetBeans IDE 8.1 (Build 201510222201)
Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23
Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27
System: Mac OS X version 10.11.5 running on x86_64; UTF-8; de_DE (nb)
None of the suggestions fixed it for me.
I have patched and build a version of OpenJDK 8 that supports subpixel rendering with netbeans on OSX. It is available for download at http://www.nothome.com/2016/08/subpixel-font-rendering-with-openjdk-8.html.
This build contains the speedup fix from JDK issue 8087201.
Thanks for letting us know about Poor editor performance with Java 7 and retina display on OS X and how to can experience a good with Java 7 if these conditions met which are shared in description.
Thanks for letting us know about the issue and poor editor performance with Java 7 and retina display on Mac OS X and the conditions which are met to happen this error for users so they can figure out the requirements and toggle the trouble.