This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 249052 - Slow rendering of complex HTML markup
Summary: Slow rendering of complex HTML markup
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: Painting & Printing (show other bugs)
Version: 8.0.1
Hardware: Macintosh (x86) Mac OS X
: P3 normal with 5 votes (vote)
Assignee: Miloslav Metelka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-02 04:43 UTC by tveimo
Modified: 2016-08-03 13:46 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
html markup (50.21 KB, text/plain)
2014-12-02 04:43 UTC, tveimo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tveimo 2014-12-02 04:43:36 UTC
Created attachment 150827 [details]
html markup

The editor slows down to a crawl rendering / scrolling the attached HTML file. 

This problem was reported as part of bug 237724, but is apparently a separate issue, so filing a new bug. Including a quote from that issue:

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

(ebakke@..)

There is profiling information attached in that issue..
Comment 1 tveimo 2014-12-08 06:16:33 UTC
Note the attachment has to be saved with an html extension and opened as such in netbeans, otherwise it doesn't trigger the slow rendering.
Comment 2 tveimo 2015-05-05 05:03:53 UTC
Is there any work being done on this issue? I tried netbeans daily 20150504 on mbp retina with intel graphics and it's super slow with the attached file, rendering an update about every 2 seconds on the heaviest lines. On nvidia graphics it's better, but still unbearable for day to day use.
Comment 3 tveimo 2015-05-05 05:06:06 UTC
- additional info: this is with jdk 1.9.0-ea-b61
Comment 4 tveimo 2015-05-27 15:58:54 UTC
Just tested with openjdk 9 patched to support subpixel antialised font rendering with NB dev 20150526, and it's now much more apparent that there's a problem with rendering speed in the editor. With the attached file open, rendering really crawls to a halt, even on the discreete nvidia graphics on my 2014 15" retina mbp. I see freezes that last for more than 40 seconds!

I used openjdk 9 from current hg, patched with the latest webrev patch set from here http://cr.openjdk.java.net/~bae/8023794/9/ 

In addition, I removed the condition in the file src/java.desktop/share/classes/sun/java2d/opengl/OGLSurfaceData.java, line 410:

sg2d.surfaceData.getTransparency() == Transparency.OPAQUE

since the current subpixel support doesn't support translucent destinations yet.
Comment 5 Miloslav Metelka 2015-05-28 11:05:44 UTC
Hi Tor,
 I'm working on a perf improvement of editor painting. We will attempt to switch editor text rendering from TextLayout to GlyphVector where possible. TextLayout has a deficiency of not being able to do partial rendering - it has just TL.draw(g2D, x, y) method. For text colored with several colors the text is rendered multiple times with appropriate restricted bounds. The Graphics should eliminate rendering of glyphs outside of the bounds but in reality it does not happen. Using an attributed string for TL does not work well visually for italic fonts. The GlyphVector.getLayoutFlags() should allow us to determine where kerning was used and so that we cannot split the text into multiple glyphvectors (otherwise the text would shift when e.g. extending a selection). In that case (and possibly for bidi text too) we would possibly retain the original way.
Comment 6 mgilede 2015-06-03 16:54:45 UTC
Hello, I just bought a Mid 2014 MacBook Pro Retina 15"... Installed NetBeans for simple php development, nothing too fancy, but I notice the performance of NB is poor, it is even better in my Late 2012 iMac 21"... How can this lag can be fixed?
My information:

Product Version: NetBeans IDE 8.0.2 (Build 201411181905)
Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 1
Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14
System: Mac OS X version 10.10.3 running on x86_64; UTF-8; en_US (nb)

The MBPR 15 has an Intel Iris Pro and the resolution is set to maximum, I believe it is like 1920x1200.

Thank you,
Comment 7 tveimo 2015-06-19 03:01:56 UTC
Good news! 

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/ which speeds up rendering quite a lot, and makes it mostly usable for day-to-day usage.

There's still a slight slowdown, especially with subpixel rendering, so it would still be an idea to investigate using GlyphVector.
Comment 8 Martin Balin 2015-06-19 07:49:24 UTC
(In reply to tveimo from comment #7)
> Good news! 
> 
> 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/ which speeds up
> rendering quite a lot, and makes it mostly usable for day-to-day usage.

Hello Tor,
This very good, did you applied this patch together with subpixel antialising one http://cr.openjdk.java.net/~bae/8023794/9/ you tried previously?
Just curious if combination of both patches improves the look and performance as well.
Comment 9 tveimo 2015-06-19 08:09:33 UTC
Yes I've applied them both, see https://netbeans.org/bugzilla/show_bug.cgi?id=216655#c102. Subpixel antialiasing is marginally slower than without, but still very usable.
Comment 10 sibidharan 2015-07-01 10:02:27 UTC
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)
Comment 11 tveimo 2015-07-02 08:44:46 UTC
I've posted a post on my blog on how to build and use. You'll need to use OpenJDK 9 though. http://www.nothome.com/2015/07/subpixel-font-rendering-with-netbeans.html
Comment 12 tveimo 2015-08-07 17:15:26 UTC
OpenJDK d76 now contains the fix for bug https://bugs.openjdk.java.net/browse/JDK-8087201, so no custom build required for much faster scroll speeds.
Comment 13 tveimo 2015-08-09 02:31:57 UTC
OpenJDK 9 b76
Comment 14 tveimo 2016-08-03 13:46:53 UTC
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.

Is there any progress on the move to GlyphVector? It would be interesting to also see what can be done to reduce the use of transparent surfaces in the netbeans editor, to avoid needing to patch the JDK.