JDK-8169976 : Blurry glyph rendering on Windows 7 at 125% screen setting is still there
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2016-11-17
  • Updated: 2017-03-10
  • Resolved: 2017-01-31
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 9
9Resolved
Related Reports
Relates :  
JDK-8167297 - The size of the splash screen should take into account DPI of the screen
Relates :  
JDK-8156149 - Blurry rendering on Windows 7 at 125% screen setting
Relates :  
JDK-8162350 - RepaintManager shifts repainted region when the floating point UI scale is used
Description
FULL PRODUCT VERSION :
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+144)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
I've been told that bug JDK-8156149 has been fixed in ea144 but it isn't. Glyph rendering is blurry when screen options set at 125%. This can be tested with the splash window of jvisualvm.exe.

The only thing mentioned in JDK-8156149 that has been solved is that the menu bullets now looks good.

The splash window is much bigger than with JDK8. In JDK8, it was 470 x 270 Pixels. With jdk9 it is 589 x 339 Pixels.

The same problem can also be seen with the Apache PDFBOX debugger-app-2.0.3.jar (get it at https://pdfbox.apache.org/download.cgi ), run 

java -jar pdfbox-app-2.0.3.jar PDFReader <pdf filename>

The application frame is larger than in jdk8. Displaying a PDF (you can drag a file or open it in the menu) shows the same weird effects with glyphs.

I've tested it with
http://www.ghostscript.com/doc/examples/annots.pdf
but it can be done with any PDF that has glyphs. You can drag a pdf file on it or even open an URL through the "file" menu.

REGRESSION.  Last worked in version 8u112

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
go to the JDK bin directory and enter jvisualvm.exe

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
good quality rendering of glyphs
ACTUAL -
weird blurry rendering of glyphs

REPRODUCIBILITY :
This bug can be reproduced always.
Comments
Fixed on the PDFBox side: https://svn.apache.org/viewvc?view=revision&revision=1781111
31-01-2017
The issue for PDFBox application is created.
30-01-2017
PDFBOX issue is created: PDFBOX-3665 PDFBox text and images are blurry on HiDPI display https://issues.apache.org/jira/browse/PDFBOX-3665
30-01-2017
-Dsun.java2d.uiScale.enabled=false could be a workaround for this. This will work for anything in its own VM Perhaps we should add "-Djdk.disablehidpi=true" as being a synonym for this since then the same could be honoured by JavaFX, so any inter-op code will behave properly.
24-01-2017
> java -jar pdfbox-app-2.0.3.jar PDFReader <pdf filename> > The application frame is larger than in jdk8. Displaying a PDF (you can drag a file or open it in the menu) shows the same weird effects with glyphs. It seems that the problem is that the the pdfbox interpolates an image with text on HiDPI display. See org.apache.pdfbox.rendering.PageDrawer class: http://svn.apache.org/viewvc/pdfbox/branches/2.0/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java?view=markup ------ @Override public void drawImage(PDImage pdImage) throws IOException { Matrix ctm = getGraphicsState().getCurrentTransformationMatrix(); AffineTransform at = ctm.createAffineTransform(); if (!pdImage.getInterpolate()) { Matrix m = new Matrix(xform); m.concatenate(ctm); boolean isScaledUp = pdImage.getWidth() < Math.round(Math.abs(m.getScalingFactorX())) || pdImage.getHeight() < Math.round(Math.abs(m.getScalingFactorY())); // if the image is scaled down, we use smooth interpolation, eg PDFBOX-2364 // only when scaled up do we use nearest neighbour, eg PDFBOX-2302 / mori-cvpr01.pdf // stencils are excluded from this rule (see survey.pdf) if (isScaledUp || pdImage.isStencil()) { graphics.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR); } } ... ------ It should prepare the high-resolution image instead and either draw it into the graphics with the base image size or use the MultiResolutionImage API. http://download.java.net/java/jdk9/docs/api/java/awt/image/MultiResolutionImage.html
24-01-2017
I have passed this info on to PDFbox, I'll let you know if there is any feedback.
09-12-2016
Everything is bigger in JDK 9 because we now support hi-dpi and will display at the size we always should have displayed. In JDK 8u and earlier Windows would have "auto-scaled" Java windows except that we told it not to. Now with very hi-dpi displays that approach is no longer viable so whilst we still tell windows not to auto-scale, we now display at the correct size and display as much as possible at "full" resolution. If you have an image (like splashscreen, or application icons) then *unless* the application provides ones that are at the higher resolution we have no choice but to auto scale just as windows would do itself given the chance. The glyph rendering in splashscreen is therefore not "glyph rendering" at all. It is just whole-image scaling. Perhaps we could make a special case to not auto-scale splashscreen images unless DPI scale of the display is at least 150%. But I somewhat doubt that the splashscreen is on screen long enough to matter *AND* this would cause a tricky problem when that transitions into the API controlled splashscreen. The size would have to change then and it would be all wrong. The apparent rendering glitches in the display of PDF-Debugger suggest that it is rendering to a software BufferedImage it has created at a fixed size like 800x1000 pixels. When we blit that to the display which is at 125% we need to scale it up to 1000x1250 pixels. So again you get artifacts. The only solution is to update the app to "not do that". It should draw to the Swing back-buffer, or query the default transform. This is NOT a new problem. If they'd printed that BufferedImage it would have looked god-awful. So apps have always needed to be aware of the transform. It is just that many ignored it and got away with it - until now. So the bottom line here is there is nothing we can do on the JDK side for these issues. You need to contact the app developers.
06-12-2016
Undeferred as P2
06-12-2016
Approved by component triage team to defer
22-11-2016
SQE: JDK9: OK to defer
22-11-2016
This issue depends on two: JDK-8162350 RepaintManager shifts repainted region when the floating point UI scale is used JDK-8167297 The size of the splash screen should take into account DPI of the screen The first one is on the review right now: http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006988.html The second one has been already deferred.
22-11-2016
Tilman Hausherr <tilman@snafu.de> sent me the four screen shots I've also attached 4 screenshots to this mail, it would be useful to add them to the issue. Tilman
17-11-2016