JDK-8087201 : OGL: rendering of lcd text is slow
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-06-11
  • Updated: 2015-11-23
  • Resolved: 2015-07-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u66Fixed 9 b76Fixed
Description
OGL text renderer needs to provide an information about the destination content to lcd shader
in order to compose lcd glyph correctly. At the moment, the destination content is read from
frame buffer with j2d_glCopyTexSubImage2D(), what could be quite slow. and it
dramatically affects the overall performance of text rendering in the case of lcd  glyphs.
This effect is quite noticeable on MacOS X, where OpenGL pipeline is used by default.
On other platforms the OpenGL pipeline is optional, but the problem also exists, and
becomes visible if the pipeline is activated.

Proposed solution: we can avoid the reading from the destination frame buffer at least
in cases where a destination surface data is based on a texture of an appropriate type.
Comments
Aiming to resolve for 15_04/October PSU.
09-07-2015
NetBeans IDE suffers from slow rendering of text partially due to problems in JDK. This patch/bug fix improves NetBeans editor performance. It was verified by one of NetBeans developers see https://netbeans.org/bugzilla/show_bug.cgi?id=249052#c7 by applying this patch to JDK build. Therefore it will be very beneficial to NetBeans and other complex editors if fix will get into upcoming JDK 8 Update release. Thank you.
19-06-2015
Fix review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-June/005499.html Webrev: http://cr.openjdk.java.net/~bae/8087201/9/webrev.00/
18-06-2015
Attached benchmark configuration and results for MBP with Intel Iris graphics.
11-06-2015
"appropriate type" => "appropriate texture target", i.e. TEXTURE_2D. Attached patch illustrates the basic idea of the fix.
11-06-2015
> in cases where a destination surface data is based on a texture of an appropriate type. I don't know what you mean by "appropriate type" and how it would obviate the need to read back.
11-06-2015