<AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting

[Sergey Bylokhov]

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.