JDK-8098116 : Support glyph rasterisation to sub-pixel precision
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-06-10
  • Updated: 2015-06-12
  • Resolved: 2013-10-24
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
8Fixed
Related Reports
Blocks :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
Grey scale anti-aliased glyphs that are not grid-fitted (hinted and snapped to a pixel grid) naturally have non-integral advances.
However they are always rasterised in a way that expects they are drawn without any offset into the pixel. ie at whole pixel positions.
This means that the spacing to the subsequent glyph is not ideally spaced.
If glyph advances are all rounded to integrals then the glyphs will be spaced evenly, but this will lead to extra space between
each glyph so that the overall string is now longer than it should be and not uniformly scaling, and most or even all, inter-glyph
spacing will not be ideal. 
The non-uniform scaling means you might as well just do everything hinted as you'll be back to a sitiuation where a 2X scale on
the graphics does NOT mean a 2X scale on the string length.

The answer is to produce glyphs which have images tuned to be rendered at a sub-pixel offset. Probably 0.25 pixels is sufficient.
This will minimise, maybe eliminate, any perceptible uneven glyph spacing, although it does mean that two adjacent instances
of the same code point (glyph) will be subtely different because the greyscale coverage values can be offset by  0.5 pixels.
It also means more overhead in rendering and caching, so we probably want to be able to control when we do this.

LCD glyphs should be able to do the same but there 1/3 of a pixel is the likely precision.
T2K provides enough info to do this I need to check what happens with glyphs produced by Windows GDI.

PS .. I thought we already had this filed somewhere but I can't find it so hence this task.
Comments
The code is there. It's a tweak. So nothing to verify.
12-02-2014

See SubpixelModes.PNG The 'Prism LCD' is the default subpixel mode used JavaFX 8. Where we rasterize the glyph one time and produce 3 subpixel locations using prism shaders. The 'Native LCD' (-Dprism.subpixeltext=native) is the result of using the native rasterizer for each subpixel position (it takes more time and more texture-memory to render) The 3 samples on the left side demonstrate subpixel positioning along the y axis (-Dprism.subpixeltext=vertical).
24-10-2013

See SubpixelGrayscale.png, this is the problem I'm fixing here. The testcase is just this: @Override public void start(Stage stage) throws Exception { Text background = new Text("Background"); VBox vbox = new VBox(background); stage.setScene(new Scene(vbox, 200, 200)); stage.show(); } The window on the back has subpixel enabled, the window on the front subpixel is disabled (-Dprism.subpixeltext=off)
24-10-2013

See the second column 1) Current rendering 2) Current rendering + fix for RT19106 (see the r looks good) 3) Rendering using DirectWrite masks (instead of subpixel produced by Prism using shaders) 4) (3) + fix for RT19106
06-09-2013

Hi Robert, In the screenshot you posted I think the worse problem there is that the 'y' took a byte of the 'r', this is a different bug: RT-19106
06-09-2013

I've done a few tests to compare font rendering between JavaFX and something native on my 64bit Windows 7 machine. I used Firefox to test native font rendering, and JavaFX 8 b100 (my apologies if something's been fixed since then), using the code Phil just posted to create a Label, explicitly specifying black text & a white background. The font is the default one: Segoe UI, size 12. Below is a link to a screenshot of the word 'Entry' blown up 400%, with the native text on the left. They are similar but the native text is slightly darker. This is actually quite significant - when viewed at 100% the native text looks clearer and more vibrant. http://imgur.com/d5AiHFk
29-08-2013

Some interesting links for comparison (form jfx mailing list) prism.lcdtext=false http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png prism.lcdtext=true http://ukyo.xs4all.nl/LCDSmoothed.png prism.lcdtext=true, prism.text=t2k http://ukyo.xs4all.nl/LCDSmoothedT2K.png prism.lcdtext=false, prism.text=t2k http://ukyo.xs4all.nl/GrayscaleT2K.png
27-08-2013

Hi Marco, I want to have a go trying to fix this bug for Lombard. On the Mac we changed to CoreText to rasterizer glyphs and there we already have sub-pixel position text for LCD and grayscale. Smaller fonts (<10px) it has 4 subpixel postions, med size 3, and large only 2 (this is how Apple designed CoreText but I think it works pretty well). On Windows we are using DirectWrite and I have verified we can provide at least 3 subpixel positions for LCD and grayscale. On Linux we are providing a freetype backend but likely it won't be enable by defaults (which means we will be using T2K there). I don't think I'll have the time to fix Linux this time around. Note that LCD text already has 3 subpixel positions (at least for hardware enabled platforms).
05-07-2013

Is there a plan when to have this fixed? We are using JavaFX with a customer owned font and this font looks really ugly regarding the letter spacing. Any comment is highly appreciated as we really don't want to go away from JavaFX just because of this font behaviour. Also any comment on how to possibly built a workaround would help.
22-04-2013

Any chance to have this for Lombard? :(
02-02-2013

This also has a very significant impact on the Scene Builder UI, which is obviously a heavy consumer of text. It is critical to have this addressed in FX 2.2 (hence the sb-22-critical label) in order for our SB 1.0 UI to look good.
17-02-2012

This is super important as its really letting down the look of text in JavaFX.
07-02-2012