<AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Jim Graham
james.graham at oracle.com
Tue Dec 17 17:03:03 PST 2013
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.
More information about the awt-dev
mailing list