On 3/26/2015 3:49 PM, Hendrik Schreiber wrote:
Hey there,
I'm in the process of moving some custom code to take advantage of the fairly
new MultiResolutionImage capabilities.
Loading multi resolution stuff works nicely, but I fear drawing is a bit of a
problem.
In my old mechanism, I would
- load images using the toolkit
- create a screen-compatible BufferedImage via
graphicsConfiguration.createCompatibleImage(...)
- draw the image into said buffer
- and then paint the screen-compatible buffer when needed (typically in some
Icon implementation)
The assumption here is that drawing the screen-compatible image is much faster
than the toolkit image (which isn't necessarily screen-compatible, usually
TYPE_INT_ARGB instead of TYPE_INT_ARGB_PRE).
AFAIK, there are no published java.* APIs for MultiResolutionImages.
So if I understand this correctly, there is currently no officially supported,
high performance way to draw MultiResolutionImages.
Therefore, in the spirit of https://bugs.openjdk.java.net/browse/JDK-8059943,
I'd like to suggest, to either move sun.awt.image.MultiResolutionImage to some
java.* package, so that one can write an implementation that is fast.
There is an open discussion about it which you could join:
http://mail.openjdk.java.net/pipermail/2d-dev/2015-March/005187.html
JDK-8029339 Custom MultiResolution image support on HiDPI displays
https://bugs.openjdk.java.net/browse/JDK-8029339
Thanks,
Alexandr.
Or provide a standard way to ensure that Toolkit-loaded images are
screen-compatible. Perhaps a little tweak in sun.awt.image.ImageRepresentation
or the code that calls it is all that's needed (i.e. a change of the default
ColorModel in ToolkitImage). Or is that not possible because of compatibility
reasons?
Does that sound reasonable? Am I missing something?
Thanks,
-hendrik
