Re: [OpenJDK 2D-Dev] AWT Dev [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Hi all, Please look at the new version: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2 It contains the following changes: - All the scale related stuff is moved to the new class: OffScreenHiDPIImage.java - JViewport and RepaintManager no longer cache buffers. - JLightweightFrame has new method: createHiDPIImage(w, h). - JViewport, RepaintManager and AbstractRegionPainter goes the new path to create a HiDPI buffered image. - A new internal property is added: swing.jlf.hidpiImageEnabled. False by default. It makes JLF.createImage(w, h) forward the call to JLF.createHiDPIImage(w, h). This can be used by a third party code in case it creates a buffered image via Component.createImage(w, h) and uses the image so that it can benefit from being a HiDPI image on a Retina display. For instance, SwingSet2 has an animating Bezier curve demo. Switching the property on makes the curve auto scale smoothly. Please, look at the screenshots: -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png - SunGraphics2D now draws a HiDPI buffered image the same way it draws a VolatileImage. - I've removed the copyArea() method from the BufImgSurfaceData, and modified the original version. The only question I have is: do I need to check for instanceof OffScreenHiDPIImage.SurfaceData in case when transformState == TRANSFORM_TRANSLATESCALE? If this method is invoked with some other SD, and the transform is SCALE, will it do the job with the coordinates conversion done? - I've left the new methods in FramePeer default... May yet we implement them in other peers when we really need it? - CPlatformLWWindow.getGraphicsDevice() checks for an intersection + scale. This heuristic actually may fail when a Window is moved b/w three or four displays so that it intersects them all at some time. JFX will set a new scale factor in between and AWT may pick up a wrong device. I don't know any simple solution for that. For two monitors this will work. Thanks, Anton.
Re: [OpenJDK 2D-Dev] AWT Dev [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Hi, Anton. Since OffScreenHiDPIImage looks similar to VolatileImage. Why we cannot use VolatileImage inside Swing everywhere? What happens if the graphicsConfig for the particular offscreen image will be changed/remoed/disposed? I suppose Volatile should became invalid in this case. CPlatformLWWindow : Why did you check scale when you try to find a necessary GraphicsDevice? Why not use the one correct device where the peer is located? Probably this code can be moved to the PlatformWindow interface? FramePeer: Do we realy need notifyScaleFactorChanged? Probably notification about replacing GC is better? In this case it should notify all listeners that GC was changed(as a result recreated all buffers). Volatile handle this automatically? I suppose you disable volatile buffer in repaint manager. Why? Note that we have a bug on Swing+retina+scroll, when we use volatiles as a buffer, I am not sure what we will get in case of BI. https://bugs.openjdk.java.net/browse/JDK-8029253 On 17.12.2013 22:21, Anton V. Tarasov wrote: Hi all, Please look at the new version: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2 It contains the following changes: - All the scale related stuff is moved to the new class: OffScreenHiDPIImage.java - JViewport and RepaintManager no longer cache buffers. - JLightweightFrame has new method: createHiDPIImage(w, h). - JViewport, RepaintManager and AbstractRegionPainter goes the new path to create a HiDPI buffered image. - A new internal property is added: swing.jlf.hidpiImageEnabled. False by default. It makes JLF.createImage(w, h) forward the call to JLF.createHiDPIImage(w, h). This can be used by a third party code in case it creates a buffered image via Component.createImage(w, h) and uses the image so that it can benefit from being a HiDPI image on a Retina display. For instance, SwingSet2 has an animating Bezier curve demo. Switching the property on makes the curve auto scale smoothly. Please, look at the screenshots: -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png - SunGraphics2D now draws a HiDPI buffered image the same way it draws a VolatileImage. - I've removed the copyArea() method from the BufImgSurfaceData, and modified the original version. The only question I have is: do I need to check for instanceof OffScreenHiDPIImage.SurfaceData in case when transformState == TRANSFORM_TRANSLATESCALE? If this method is invoked with some other SD, and the transform is SCALE, will it do the job with the coordinates conversion done? - I've left the new methods in FramePeer default... May yet we implement them in other peers when we really need it? - CPlatformLWWindow.getGraphicsDevice() checks for an intersection + scale. This heuristic actually may fail when a Window is moved b/w three or four displays so that it intersects them all at some time. JFX will set a new scale factor in between and AWT may pick up a wrong device. I don't know any simple solution for that. For two monitors this will work. Thanks, Anton. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] AWT Dev [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Hi Anton, javax.swing.RepaintManager.getOffscreenBuffer is a public method that can now return one of the new HiDPI offscreen images which is a subclass of BufferedImage. This was what I was worried about in terms of one of these internal double buffers leaking to developer code. If they test the image using instanceof they will see that it is a BufferdImage and they may try to dig out the raster and get confused... ...jim On 12/17/13 10:21 AM, Anton V. Tarasov wrote: Hi all, Please look at the new version: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2 It contains the following changes: - All the scale related stuff is moved to the new class: OffScreenHiDPIImage.java - JViewport and RepaintManager no longer cache buffers. - JLightweightFrame has new method: createHiDPIImage(w, h). - JViewport, RepaintManager and AbstractRegionPainter goes the new path to create a HiDPI buffered image. - A new internal property is added: swing.jlf.hidpiImageEnabled. False by default. It makes JLF.createImage(w, h) forward the call to JLF.createHiDPIImage(w, h). This can be used by a third party code in case it creates a buffered image via Component.createImage(w, h) and uses the image so that it can benefit from being a HiDPI image on a Retina display. For instance, SwingSet2 has an animating Bezier curve demo. Switching the property on makes the curve auto scale smoothly. Please, look at the screenshots: -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png - SunGraphics2D now draws a HiDPI buffered image the same way it draws a VolatileImage. - I've removed the copyArea() method from the BufImgSurfaceData, and modified the original version. The only question I have is: do I need to check for instanceof OffScreenHiDPIImage.SurfaceData in case when transformState == TRANSFORM_TRANSLATESCALE? If this method is invoked with some other SD, and the transform is SCALE, will it do the job with the coordinates conversion done? - I've left the new methods in FramePeer default... May yet we implement them in other peers when we really need it? - CPlatformLWWindow.getGraphicsDevice() checks for an intersection + scale. This heuristic actually may fail when a Window is moved b/w three or four displays so that it intersects them all at some time. JFX will set a new scale factor in between and AWT may pick up a wrong device. I don't know any simple solution for that. For two monitors this will work. Thanks, Anton.
