<Swing Dev> [9] Review request for 8164032 JViewport backing store image is not scaled on HiDPI display
Sergey Bylokhov
Sergey.Bylokhov at oracle.com
Fri Sep 23 13:25:09 UTC 2016
On 01.09.16 11:25, Alexandr Scherbatiy wrote:
> According to your previous comments:
> - VolatileImage.validate(GraphicsConfiguration) does not return
> IMAGE_INCOMPATIBLE for a graphics configuration which default transform
> was changed.
> This is because the BufImgVolatileSurfaceManager has acceleration
> disabled and it skips check to the valid graphics configuration.
> I have filled an issue on it: JDK-8165212 VolatileImage is compatible
> with GraphicsConfiguration which transform is changed
This looks fine.
>
> - JViewport.backingStoreImage field is protected so it is not possible
> to change its type. Moreover, it is not clear can a someone override
> JViewport and use backingStoreImage as a buffered image so he does not
> expect that the image content can be lost.
>
> Could we just file a new issue that the backing store image can be
> changed to VolatileImage in JViewport and return to discussion where
> graphics scale changing is checked:
> http://cr.openjdk.java.net/~alexsch/8164032/webrev.02
I suggest to thinking about more general solution. The code which you
write is only one correct solution to create a backbuffer in HiDPI
mode(another on is to use VolatileImage). The code itself is not trivial
so it will be good to provide some API for this.
in the same way as createCompatibleImage() takes care about "color model".
> On 8/30/2016 3:54 PM, Alexandr Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.04/
>>
>> The Component.createVolatileImage() is used to create a backing store
>> volatile image.
>>
>> On 8/29/2016 4:18 PM, Sergey Bylokhov wrote:
>>> On 19.08.16 10:15, Alexandr Scherbatiy wrote:
>>>> On 8/18/2016 3:05 PM, Alexandr Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.02
>>>>>
>>>>> The backing store image is recreated for the case where scaled sizes
>>>>> are changed.
>>>>
>>>> A version where a VolatileImage is used as a backing store image:
>>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.03/
>>>
>>> The VI case looks simpler. I guess it can be simplified even more:
>>> Peobably this code is unnecessary?
>>> } else if (vImg instanceof SunVolatileImage) {
>>> 753 SunVolatileImage svImg = (SunVolatileImage)
>>> vImg;
>>> 754 if
>>> (!graphicsConfig.equals(svImg.getGraphicsConfig())) {
>>> 755 backingStoreImage = null;
>>> 756 }
>>> 757 }
>>>
>>> My understanding is that if VI.validate!=IMAGE_INCOMPATIBLE then we
>>> can use it for drawing even if the GC is different?
>> Different graphics configurations can have different default
>> transforms. The backing store image should be recreated in this case.
>>
>> Thanks,
>> Alexandr.
>>> Probably we can reuse Component.createVolatileImage() instead of
>>> createImage()?
>>>
>>> Also can you please check a performance of these two solutions?
>>>
>>>
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>> On 8/17/2016 5:05 PM, Sergey Bylokhov wrote:
>>>>>> On 17.08.16 14:02, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.01
>>>>>>>
>>>>>>> The generic transform is used for the backing store image scaling.
>>>>>>
>>>>>> As far as I understand the current fix will not work if the scale was
>>>>>> changed(the JViewport will use old buffer)?
>>>>>>
>>>>>> It seems that the new local AbstractMultiResolutionImage contain only
>>>>>> one image variant inside and looks quite similar to the
>>>>>> VolatileImage, probably we can change this cache from BufferedImage
>>>>>> to VolatileImage? In this case the scale of the VI will be the same
>>>>>> as "g":
>>>>>> g.getDeviceConfiguration().createCompatibleVolatileImage()
>>>>>>
>>>>>>
>>>>>>> On 8/15/2016 4:58 PM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Alexandr.
>>>>>>>> I doubt that getScaleX/getScaleY can be used here because the scale
>>>>>>>> can be generic(translate+rotate+scale). How this cache will work if
>>>>>>>> transform will be changed after we save "backingStoreImage"?
>>>>>>>>
>>>>>>>> On 15.08.16 16:16, Alexandr Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the fix:
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8164032
>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8164032/webrev.00
>>>>>>>>>
>>>>>>>>> The fix scales the JViewport backing store image when graphics
>>>>>>>>> transform is not identity.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
--
Best regards, Sergey.
More information about the swing-dev
mailing list