Adding new API to BufferedImage was definitely NOT the way to approach this.
Adding new public API we need to support forever to fix an internal
implementation bug
on one platform in a very atypical scenario is the wrong trade-off.
And anyway as Sergey said BI should have no dependency or relationship
on a BI
TranslucentWindowPainter already had the GraphicsConfiguration anyway so it
does not seem necessary
and you seem to be more along the right lines with this fix but I'd like to try
it ..
Couple of questions :
Why are none of the failing tests referenced with an updated reg-test @bug tag
to indicate this
fix corrects them ?
You say it is observable with GDI .. the bug report refers only to OpenGL.
So is it both ?
If so you don't need to enable the flaky OGL pipeline to verify this .. but then
I am left puzzled since Intel cards don't use D3D so I'd expect more reports.
So does it reproduce with just
-Dsun.java2d.d3d=false
??
-phil.
On 11/3/17, 6:44 AM, Pankaj Bansal wrote:
Hi Sergey,
I have created the BufferedImage of correct size considering the window
dimension and graphics context scale.
I changed BufferedImage just to store graphicsConfig, so that it can be used by
BufImgSurfaceManager while creating BufImgSurfaceData. The scale in
BufImgSurfaceData is used to create config while creating the SunGraphics2D
through getDefaultTransform function. Now when the TranslucentWindowPainter
create scaled BufferedImage and then creates Graphics2D using that, the
Graphics2D has transform scale as (1,1) as the BufImgSurfaceData has scale
(1,1). Then this Graphics2D is used to update the Window in updateWindow in
TranslucentWindowPainter. As the transform is identity, none of the Swing
Components which are added to the window are scaled.
So I modified the BufferedImage to store graphicsConfig which can then be used
by BugImgSurfaceManager to create BugImgSurfaceData with correct scale values
and hence correct transform value in SunGraphics2D.
If this is not the correct way, I have one more way of doing this by
transforming the SunGraphics2D object with transform of peer. So the
SunGraphics2D will have correct transform and objects are properly scaled. I
have updated the webrev for the same. Please have a look. Also if this is also
not the correct way, can you please suggest a way I can do this?
Webrev:
http://cr.openjdk.java.net/~pbansal/8164811/webrev.01/
Regards,
Pankaj Bansal
-----Original Message-----
From: Sergey Bylokhov
Sent: Friday, November 3, 2017 5:34 AM
To: Pankaj Bansal; Prem Kumar Balakrishnan (prem.balakrish...@oracle.com);
swing-...@openjdk.java.net; 2d-dev@openjdk.java.net
Subject: Re: [10] Review Request JDK - 8164811 : [hidpi]Tests fail with OpenGL
Rendering
Hi, Pankaj.
The BufferedImage class is a raster in the memory which should be unrelated to
any grpahics config on the system. So this class should not be changed, but
instead you should create a correct BI-as a back buffer which takes into
account the size of the window and the scale of the GC.
On 31/10/2017 04:59, Pankaj Bansal wrote:
Hi All,
Please review the fix for JDK 10.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8164811
Webrev:
http://cr.openjdk.java.net/~pbansal/8164811/webrev.00/
Issue:
The tests given in the bug were failing when run with OpenGL and GDI.
This bug is related to
https://bugs.openjdk.java.net/browse/JDK-8189257
which states that that HIDPI does not work with swing components when
Translucent window is used. Because of which all the tests in the bug
were failing.
Fix:
The TranslucentWindowPainter class was creating BufferedImage for
OpenGL (when /forceOpt/ is false) and GDI pipeline, but it is not
considering the device HiDPI scale. There is no way to create a scaled
BufferedImage because of which the scale value in BufImgSurfaceData is
always 1. Made changes to store graphics config in Buffered image, so
that the BufImgSurfaceManager can create BufImgSurfaceData with scale set
properly.
This fix also fixes https://bugs.openjdk.java.net/browse/JDK-8189257
Regards,
Pankaj Bansal
--
Best regards, Sergey.
