JDK-6274813 : OGL: Accelerate LCD glyphs via OpenGL pipeline
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-05-23
  • Updated: 2017-05-16
  • Resolved: 2006-03-22
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 6
6 b77Fixed
Related Reports
Relates :  
JDK-6521434 - OGL: enable sun.java2d.opengl.lcdshader by default
Description
The intitial LCD text implementation is currently only in software and
can't be used on OpenGL surfaces. OpenGL surfaces therefore cannot use
it - accelerated or not. We need to implement this support.
###@###.### 2005-05-23 21:28:26 GMT
Comments
EVALUATION This fix was integrated into Mustang b77, but I forgot to update this bug report with the exact system property that enables the new codepath: -Dsun.java2d.opengl=true -Dsun.java2d.opengl.lcdshader=true As mentioned above, there were two outstanding driver bugs when this fix was integrated: artifacts on ATI boards, and poor performance on Nvidia boards. Since then, both bugs have been fixed by their respective driver teams and we are currently testing those fixes. The ATI fix should be available in their 8.26 release (for Linux, not sure how that correlates to their Windows Catalyst driver version) in a couple months, and the Nvidia fix should be available in their 85.xx series in a similar timeframe. Once both driver fixes are publicly available and verified, we should be able to enable the lcdshader flag by default (again, only if the OGL pipeline has been enabled).
03-04-2006
EVALUATION Just to clarify my last point, if you enable the OGL pipeline, the LCD acceleration codepath will be disabled by default. You will have to enable both system properties to enable LCD acceleration for the OGL pipeline.
12-03-2006
EVALUATION I've attached a simple performance test (LCDTextTest.java) that I've used to measure LCD text performance. I ran this test on a number of machines with shader-level hardware, and the results are all over the map. I've included these performance numbers below. In these results, the numbers indicate the number of milliseconds taken to render a particular test string (about 35 characters long, in 12 point font) 10000 times, so lower is better. def - "default pipeline" (GDI/DDraw on Windows, X11 on Linux/Solaris) ogl - "OGL pipeline" (-Dsun.java2d.opengl=True) mono - black/white text (TEXT_ANTIALIAS_OFF) gray - grayscale AA text (TEXT_ANTIALIAS_ON) lcd - LCD optimized text (TEXT_ANTIALIAS_LCD_HRGB) awt - render directly to the screen swing - render to the Swing backbuffer (pbuffer in the case of OGL) (swing-fbo) - render to the Swing backbuffer, which is an FBO (-Dsun.java2d.opengl.fbobject=true); only applicable when OGL is enabled NV GF FX 5600 (AGP), JDS Linux, 2x 2.8GHz P4 awt swing (swing-fbo) def-mono 225 319 def-gray 1697 218 def-lcd 2219 480 ogl-mono 116 109 109 ogl-gray 116 109 109 ogl-lcd 718 721 3669 NV GF FX 5600 (AGP), Windows XP, 2x 2.8GHz P4 awt swing (swing-fbo) def-mono 1469 672 def-gray 1750 250 def-lcd 2266 328 ogl-mono 234 234 235 ogl-gray 235 234 234 ogl-lcd 969 7359 6907 NV GF 6800 (PCI-E), Windows XP, 1x 2.2GHz Opteron 148 awt swing (swing-fbo) def-mono 375 297 def-gray 531 187 def-lcd 750 375 ogl-mono 78 78 62 ogl-gray 78 78 63 ogl-lcd 406 375 344 NV Quadro FX 1100 (AGP), Solaris 10, 2x 2.0GHz Opteron 246 awt swing (swing-fbo) def-mono 160 215 def-gray 2345 247 def-lcd 2803 515 ogl-mono 117 100 100 ogl-gray 115 101 100 ogl-lcd 519 483 6475 ATI Radeon 9600 (AGP), JDS Linux, 1x 3.2GHz P4 awt swing (swing-fbo) def-mono 356 245 def-gray 11304 198 def-lcd 13206 422 ogl-mono 118 119 116 ogl-gray 118 118 116 ogl-lcd 606 604 606 ATI Radeon 9500 Pro (AGP), Windows XP, 2x 2.8GHz P4 awt swing (swing-fbo) def-mono 2188 516 def-gray 2656 250 def-lcd 3516 328 ogl-mono 391 390 390 ogl-gray 391 390 390 ogl-lcd 2125 2125 2125 ATI Radeon x300 SE (PCI-E), Windows XP, 1x 3.4GHz P4 awt swing (swing-fbo) def-mono 532 297 def-gray 610 156 def-lcd 766 250 ogl-mono 94 94 93 ogl-gray 94 94 94 ogl-lcd 1032 954 953 Points of interest: - Performance improves significantly on newer boards (those with better shader support). - Performance is terrible on Nvidia when rendering to an FBO (on all platforms) or to a pbuffer/render-to-texture surface (on Windows only); this is a performance issue with glCopyTexSubImage2D(), which has been filed with Nvidia this morning (#216273). May be related to some other glCopyPixels() issues that are discussed in JDK bugid 6298234. - It is interesting that Nvidia GF 6800 (PCI-Express) does not exhibit any of those performance issues, presumably because the readback bus speeds are much faster with PCI-E than AGP, so driver slow paths that go to sysmem are likely to be less noticeable (I've asked Nvidia about this). - ATI does not have those same performance issues with FBO, although their glCopyTexSubImage2D() performance is generally worse than that of Nvidia on comparable hardware, so I will follow up with ATI about that. - ATI has a bug in glCopyTexSubImage2D() that causes LCD text to look garbled (when rendered to a pbuffer or FBO destination only); that bug will be filed with ATI shortly. Out of all of these configurations, there are only two where LCD text is faster with the OGL pipeline: Nvidia Quadro FX 1100 on Solaris 10, and Nvidia GeForce 6800 on WinXP. Due to this fact and the other issues listed above, I suggest we check this code in now, but disabled by default (it can be enabled by a system property, TBD). This will give us some time to shake out the driver issues, and then once those are resolved we can turn this on by default at a later date.
11-03-2006
EVALUATION The fix for this has been in progress for at least six months because there have been a number of technical hurdles along the way (lots of investigation of fragment shader performance, finding sneaky ways to avoid expensive pow() calls in the shader, etc). At this point, I have a fairly complete implementation that uses a GLSL fragment shader, and depending on which video card is used, it can be about as fast as, or up to 30% faster than the equivalent operation using software loops. In fact, shader performance has been improving so much in recent graphics hardware that I would expect this gap to grow larger and larger over time. Due to time constraints, I've only made this work for hardware that supports the GL_ARB_fragment_shader extension, i.e. there is no software fallback (it would be really slow anyway, as it would require readbacks from the framebuffer into system memory), so for older boards we will continue to just use grayscale AA as we've done up until this point in Mustang. Also, this shader-based implementation only works when the foreground color is opaque, but this should be sufficient for 99% of all cases.
09-03-2006