On 18.12.2013 13:25, Anton V. Tarasov wrote:
Hi Jim,
Thanks for noticing (sorry, but I simply forgot to check we don't export the buffer...) What can
we do about that? I have the following thoughts:
1) We can warn developers to be ready for a HiDPI raster when they call that method under the
following conditions: 1) the interop mode, 2) MacOSX 3) a Retina display.
2) In case the method is called, we can create a "shadow buffer" and start to sync it with the
main buffer. The main buffer will be scaled to the shadow buffer on every repaint cycle.
Just wanted to add, that SunVolatileImage.getSnapshot does the same (it scales the volatile image to
a buffer), however it doesn't need to keep it synchronised...
Thanks,
Anton.
3) We can introduce an internal property which will switch on/off the 2nd scenario. For instance,
a developer may ask for the buffer and don't bother about its hidpi raster.
Yes, I understand the solutions are far from perfect, but please take into account, the interop is
a special mode where we (and developers) should be ready for compromises...
What do you think? Do you have any better solutions in mind?
Thanks,
Anton.
On 18.12.2013 5:03, Jim Graham wrote:
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.