[OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails
Vadim Pakhnushev
vadim.pakhnushev at oracle.com
Wed Aug 31 13:05:31 UTC 2016
+1
Vadim
On 31.08.2016 16:05, Prem Balakrishnan wrote:
>
> Hi Vadim,
>
> Thankyou for the Review.
>
> I have updated the patch as per review comments,
>
> http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.03/
> <http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.03/>
>
> >According to the comments in the
> TranslucentWindowPainter.createInstance you will get BIWindowPainter
> even for OpenGL pipeline unless you force optimized path via
> >sun.java2d.twp.forceopt so you will need to check these paths in the
> fix for OpenGL.
>
> Yes, BIWindowPainter get called in OpenGl pipleline , I am working on
> OpenGL rendering issue(8164811).
>
> Regards,
>
> Prem
>
> *From:*Vadim Pakhnushev
> *Sent:* Wednesday, August 31, 2016 5:00 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov; 2d-dev at openjdk.java.net
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> Prem,
>
> I believe it's possible to use AccelSurface.getBounds() method and
> skip casting to SurfaceData completely.
> The calculations are basically the same.
>
> According to the comments in the
> TranslucentWindowPainter.createInstance you will get BIWindowPainter
> even for OpenGL pipeline unless you force optimized path via
> sun.java2d.twp.forceopt so you will need to check these paths in the
> fix for OpenGL.
>
> Thanks,
> Vadim
>
> On 30.08.2016 9:17, Prem Balakrishnan wrote:
>
> Reminder
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, August 26, 2016 12:08 PM
> *To:* Prem Balakrishnan; 2d-dev at openjdk.java.net
> <mailto:2d-dev at openjdk.java.net>
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> Ok. so long you are addressing the opengl issue albeit via
> different bugid, it's ok with me. +1.
>
> Regards
> Prasanta
>
> On 8/26/2016 11:56 AM, Prem Balakrishnan wrote:
>
> Hi Prasanta,
>
> Thankyou for the review.
>
> The code compiles , Actual scenario is as below:
>
> public class Temp {
>
> AccelSurface as = new AccelSurface() {};
>
> SurfaceData sd = (SurfaceData)as;
>
> }
>
> class SurfaceData {}
>
> interface Surface {}
>
> interface AccelSurface extends Surface{}
>
> class D3DSurfaceData extends SurfaceData implements AccelSurface{}
>
> class OGLSurfaceData extends SurfaceData implements AccelSurface{}
>
> -------------------
>
> In suggested fix, the SurfaceData is always of type
> D3DSurfaceData.
>
> And hence getDefaultScaleX/Y holds good. OpenGL rendering is
> handled in a different flow.
>
> http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/
> <http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/>
>
> Suggested fix also resolves the following failures on hidpi
> windows 8
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
>
> ----------------------
> OpenGL Rendering issue will be addressed in JDK-8164811
> <https://bugs.openjdk.java.net/browse/JDK-8164811>
>
>
>
> Regards,
>
> Prem
>
> *From:*Prasanta Sadhukhan
> *Sent:* Monday, August 22, 2016 12:32 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal;
> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
> 2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net>
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> I wonder how it compiles?
> I tried a small program
> ------------------
> public class Test {
> AccelSurface b = new AccelSurface();
> SurfaceData c = (SurfaceData)b;
> }
>
> class SurfaceData extends Surface {}
> class Surface {}
> class AccelSurface extends Surface {}
> ---------
> and it fails to compile
> Test.java:3: error: incompatible types: AccelSurface cannot be
> converted to SurfaceData
> SurfaceData c = (SurfaceData)b;
>
> ANyways, did you check with opengl pipeline? It seems
> getDefaultScaleX/Y is not present in OGLSurfaceData which will
> result in falling back to SurfaceData in which case the scale
> will be 1.
>
> Regards
> Prasanta
>
> On 8/18/2016 3:12 PM, Prem Balakrishnan wrote:
>
> Added “2d-dev” team for review
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Thursday, August 18, 2016 2:57 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> Could you also send the review to the 2d-dev alias?
>
> Thanks,
> Alexandr.
>
> On 8/18/2016 9:59 AM, Prem Balakrishnan wrote:
>
> Hi Alexandr,
>
> AccelSurface is implemented by *ONLY* D3DSurfaceData
> and OGLSurfaceData classes,
>
> Both of these classes extend SurfaceData as well.
>
> Hence, casting of 'as' variable which is of type
> AccelSurface object to SurfaceData is always VALID.
>
> Regards,
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Wednesday, August 17, 2016 4:42 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> On 8/17/2016 11:30 AM, Prem Balakrishnan wrote:
>
>
>
>
>
> Hi Alexandr,
>
> Thankyou for the review.
>
> YES scaled SurfaceData returns proper scale values
> from getDefaultScaleX()/getDefaultScaleY(), which I
> have used in the current patch.
>
> Please review the updated patch
>
> http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/
> <http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/>
>
> Is it always true that the 'as' variable which has
> type AccelSurface in the fix is always instance of
> SurfaceData?
>
> Thanks,
> Alexandr.
>
>
>
>
>
> Regards,
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Tuesday, August 16, 2016 10:06 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> On 8/16/2016 7:35 AM, Prem Balakrishnan wrote:
>
>
>
>
>
>
> Reminder
>
> *From:*Prem Balakrishnan
> *Sent:* Friday, August 12, 2016 6:36 PM
> *To:* Alexander Scherbatiy; Rajeev Chamyal;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
> *Subject:* RE: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> Hi Alexandr and Sergey,
>
> Please review the updated patch.
>
> http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/
> <http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/>
>
> >>“It is a little bit strange bug, because
> VolatileImage should handle this scale internally, and
> create double sized surface when necessary”.-Sergey
>
> Yes as you mentioned Volatile Image is getting scaled
> internally. Thanks for the feedback.
>
> *Cause:*In
> VIOptWindowPainter::updateWindowAccel(psdops, w, h)
> call, width and height were passed without scaling,
>
> which was creating a bitmap of specified width and
> height, hence the output was clipped.
>
>
> I just have two general questions.
> - The scaled SurfaceData should return proper scales
> from getDefaultScaleX()/getDefaultScaleY() methods. Do
> these methods return right values after setting the
> scaled image sizes in the fix?
> - Region.clipScale() which is used in many places
> rounds values. The usual rule is to use Math.floor()
> for image coordinates rounding and Math.ceil() for sizes.
> Should the same rule be applicable here?
>
> Thanks,
> Alexandr.
>
>
>
>
>
>
>
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Thursday, August 04, 2016 6:23 PM
> *To:* Prem Balakrishnan; Rajeev Chamyal;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
> *Subject:* Re: Review Request: JDK-8144735 [hidpi]
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> On 8/3/2016 10:04 AM, Prem Balakrishnan wrote:
>
> Hi,
>
> Please review fix for JDK9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735
>
> *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/
> <http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/>
>
>
> *Issue:*
>
> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
> fails
>
> *Cause:*
>
> While creating Transparent VolatileImage, width and
> height was NOT hidpi scaled.
>
> *Fix: *VolatileImage width and height are scaled.
>
>
> I believe this is an issue in AWT and needs to be
> discussed on awt-dev alias.
>
> Should the backbuffer width and height be also
> scaled for the BIWindowPainter?
>
> Thanks,
> Alexandr.
>
> Thanks,
>
> Prem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160831/91f09339/attachment.html>
More information about the 2d-dev
mailing list