<Swing Dev> [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Mon Mar 21 15:54:09 UTC 2016


The one more thing is that image filters should also be updated to use 
them with multi-resolution images.
For example, consider the case:
----------
     Image mrImage = getMultiResolutionImage();
     ImageProducer mriProducer = new 
FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, 0, w, h));
     Toolkit.getDefaultToolkit().createImage(mriProducer);
----------

The crop image filter applied to each resolution variant just cuts 
images with the same size.
It seems that there should be added API which allows to set a scale for 
a provided image filter to be properly used with the given resolution 
variant.

I have created a separated issue for multi-resolution images filtering 
support:
   JDK-8152309 Seamless way of using image filters with multi-resolution 
images
   https://bugs.openjdk.java.net/browse/JDK-8152309

Thanks,
Alexandr.

On 15/03/16 20:35, Alexander Scherbatiy wrote:
> On 15/03/16 18:06, Sergey Bylokhov wrote:
>> On 15.03.16 17:01, Alexander Scherbatiy wrote:
>>
>>>   One update will be that FilteredImageSource should implement
>>> MultiResolutionImageProducer even it is used for non multi-resolution
>>> images.
>>>
>>>    The MRI can be created using two general ways: using fixed number of
>>> resolution variants or generating a resolution variant with necessary
>>> quality on demand.
>>>
>>>   The current implementation is rely on that MRToolkitImage contains a
>>> fixed number of resolution variants. In this case MediaTracker can
>>> iterate over resolution variants and load them all.
>>>
>>>   Using MultiResolutionImageProducer leads that MRToolkitImage will not
>>> know about number of resolution variants in case when they are 
>>> generated
>>> on the fly and there will be no way to load all of them by 
>>> MediaTracker.
>>
>> Just an idea to thinking about, can we save this filter to the MRI 
>> itself and apply it after some resolution variant will be created on 
>> the fly?
>
> Do you mean that it helps to leave the code in the AquaUtils class 
> unchanged:
> ---------------
>  124     static Image generateLightenedImage(final Image image, final 
> int percent) {
>  125         final GrayFilter filter = new GrayFilter(true, percent);
>  126         final ImageProducer prod = new 
> FilteredImageSource(image.getSource(), filter);
>  127         return Toolkit.getDefaultToolkit().createImage(prod);
>  128     }
> ---------------
>
>   or it is just an a better way for a filtered multi-resolution image 
> generation?
>
>   Thanks,
>   Alexandr.
>>
>>>
>>> As I see, the way to solve it is only using MRI.getResolutionVariants()
>>> method for the MultiResolutionImageProducer creation. So the result of
>>> the call
>>>     toolkit.createImage(new FilteredImageSource(mrImage.getSource(),
>>> filter));
>>>   will be a MRToolkitImage which is based on fixed number of filtered
>>> resolution variants from the original MRI.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>> ...jim
>>>>
>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote:
>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote:
>>>>>> Probably we should enhance 
>>>>>> ImageProducer/Tk.createImage/ImageFilter to
>>>>>> support this functionality? It seems that the number of usage of 
>>>>>> this
>>>>>> check "image instanceof MultiResolutionImage" will grow over time.
>>>>>     ImageProducer produces pixels for an image and is not able to 
>>>>> take
>>>>> an information about the image resolution variants.
>>>>>
>>>>>   May be we can add Toolkit.createImage(Image image, ImageFilter
>>>>> imageFilter) method which takes MultiResolutionImage into account to
>>>>> cover the common case where filtered image is created.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>> I think that at least our own API should support 
>>>>>> MultiResolutionImage
>>>>>> w/o such checks, otherwise the user will need to do the same.
>>>>>>
>>>>>> cc 2d-dev
>>>>>>
>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix:
>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8151303
>>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00
>>>>>>>
>>>>>>>    The AquaUtils does not take into account MultiResolutionImage 
>>>>>>> for
>>>>>>> selected/disabled/lightened images generation.
>>>>>>>    The fix also leaves the MultiResolutionCachedImage check because
>>>>>>> the
>>>>>>> base system icon size can be differ from the requested painted 
>>>>>>> size.
>>>>>>>
>>>>>>>    Thanks,
>>>>>>>    Alexandr.
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>




More information about the swing-dev mailing list