JDK-8152309 : Seamless way of using image filters with multi-resolution images
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-03-21
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Description
See the discussion: http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006453.html

The request is to use image filters with multi-resolution images to produce resulted multi-resolution images.

For example it would be good if code below works without changes for multi-resolution images:
---------------
 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     }
--------------- 

Note 1:
MediaTracker is able to load resolution variants if they are provided from a set (like multiResoltuinImage.getResolutionVariants() method and not from method multiResoltuinImage.getResolutionVariant(width, height))

Note2: 
The scheme multi-resolution image -> multi-resolution image producer + image filter -> multi-resolution image
should also provide information about resolution-variant scaling to the filter.

For example using CropImageFilter with given rectangle [x, y, width, height]  in such case will result that from each resolution variant will be cut an constructed an image with the same size which is not what is expected.
Comments
The latest update was a comment from Jim http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html This all snowballed pretty far and wide. The original fix to Swing icons was trivial in comparison. In retrospect it might be better to simply offer the helper method from the original bug fix as a Toolkit solution and force applications to adopt it when dealing with MR sources: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00/ We can revisit this solution in the future if we get a lot of push from the community, but it seems like a lot of complications to add to the code for this small set of use cases...
13-05-2016

The latest discussion on the review alias: http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006743.html
25-04-2016