Pardeep Sharma added a comment - 2017-10-16 21:20 JDK 9 Windows 10 4k Monitor This need to be checked for 4K monitor. When checked on display with DPI set to 175% with Resolution 1920 * 1080, couldn't reproduce the issue as reported. The buffered images looks fine when checked with JDK 9. See attached screenshots depicting result with JDK 9 and JDK 8u144 with above mentioned resolution. However, the results may vary with 4K monitor as reported by the submitter. Checking for required infra, meanwhile keeping this open for dev. to assess the effect. Reported at stackoverflow: https://stackoverflow.com/questions/46736757/disable-automatic-rescaling-of-bufferedimage-in-jdk9

Philip Race added a comment - 2017-10-17 09:56 This looks like a D3D-specific bug. I can reproduce on Windows with D3D but it works fine with OpenGL or software pipelines.

Philip Race added a comment - 2017-10-17 10:03 The workaround is -Dsun.java2d.d3d=false

Prahalad Kumar Narayanan added a comment - 2017-11-15 00:04 Quick observations on this issue . I tested this issue on a D3D compatible Windows10 desktop running JDK10 build. . Yes the issue could be reproduced & I could see distortions with higher DPI settings. . Interestingly, the distortion was observed only with non-integer scale factors. Scale factors of 2.0, 3.0 didn't distort the image. . I will continue to inspect on this issue and update when I have concrete findings.

Prahalad Kumar Narayanan added a comment - 2017-11-30 22:12 - edited The issue is tricky. Here are my inferences while inspecting this issue- . The output of image rendering (embedded in a Label) differs across multiple iterations-       . Iteration 1:             . The input BufferedImage is blitted onto an accelerated surface using D3DSwToSurfaceScale.             . Artifacts are not observed during this operation.             . However, D3DSurfaceDataProxy attempts to cache the buffered image on GPU.       . Iteration 2:             . In the second iteration, the buffered image gets cached by D3DSurfaceDataProxy using D3DSwToTextureBlit             . Once caching is complete, a valid D3DSurfaceData for cached BufferedImage is returned for the blitting operation.             . Thus, the logic for blitting gets changed to D3DTextureToSurfaceScale. It is here that the artifacts are observed. . While debugging the code, I found that the Blit logic further differs based on the Interpolation type- Nearest Neighbor, Bi-Linear, Bi-cubic . When experimented with different interpolation values, I observed that, the issue is visible with Nearest neighbor interpolation alone.       . With Bi-linear and Bi-cubic interpolations- D3DTextureToSurfaceTransform gets executed.       . Whereas with Nearest neighbor interpolation- D3DTextureToSurfaceScale gets executed. . Both the above methods of D3DBlitLoops- D3DTextureToSurfaceScale, D3DTextureToSurfaceTransform get realized with IsoBlit. Hence the backend logic at the native code is the same. It's the interpolation that results in such artifacts. . Changing the interpolation from Nearest Neighbor to Bilinear in D3DTextureToSurfaceScale fixes the issue. . In another observation, the values for dx1, dx2 were found negative within D3DTextureToSurfaceScale but this did not occur always. . Hence the appearance of artifacts in connection to the above values could not be confirmed.

Prahalad Kumar Narayanan added a comment - 2017-12-11 10:35 - edited . I modified the default interpolation at D3DTextureToSurfaceScale from nearest neighbor to bilinear interpoloation. . While this fixed the issue, it caused a regression failure at- sun/java2d/pipe/InterpolationQualityTest.java . The test failed because, it specifically tested and compared output images with Nearest Neighbor interpolation but the code change silently used bilinear instead in the D3DBlitLoops. . This brings us to a point wherein the fix isn't straight forward. . While user can set either Bilinear or Bicubic interpolation for all custom rendering done with Graphics2D object, it 's not possible (from end-user's program) to set interpolation while rendering swing components that contain images. . I will need time to discuss this issue in detail with the submitter and plan a course of action. Hence deferring this issue.

Prahalad Kumar Narayanan added a comment - 2017-12-19 20:46 . As updated in the comments, the root cause stems from the use of Nearest Neighbor interpolation (chosen as default when no interpolation hint is set) while rendering the swing components. . Nearest neighbor interpolation has been chosen as the default for performance reasons. Setting interpolation to Bilinear or Bicubic will incur huge performance loss for other swing components. . Since the default choice of interpolation cannot be changed, there are different work around options to avoid artifacts. . Unfortunately, the intent of the bug is not clear from the test-case present in the description. . If the submitter's intent is to avoid artifacts while rendering BufferedImages on D3D surfaces, the work around would be to explicitly set rendering hint before drawing an image.       Graphics2D gfx2D = (Graphics2D) g;       RenderingHints rHints = new RenderingHints(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);       gfx2D.addRenderingHints(rHints); . If the submitter's intent is to avoid artifacts while rendering ImageIcons within JLabel, the work around would be one of the two options-       . Disable UI scaling with VM option: -Dsun.java2d.uiScale=1       . Use MRI image (Multi-Resolution Image) instead of BufferedImage for ImageIcon. Note: A multi-resolution image is a collection of individual images at different scale factors.

Prahalad Kumar Narayanan added a comment - 2018-01-07 23:17 . We discussed with the submitter of the issue and got to know the intent - Rendering BufferedImages smooth on scaled resolutions. . One of the workarounds suggested in the comments addresses this need. Hence closing the issue.

Sergey Bylokhov added a comment - 2018-01-08 10:41 Providing a workaround for the user does not mean that the bug is fixed. We can take care of it later since it is not urgent now.