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

[Anton V. Tarasov]

The 4th option, previously suggested by Sergey, is to switch off double 
buffering at all. I'm investigating it.

Thanks,
Anton.

On 12/18/13 1:25 PM, 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.
> 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.
>