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.
