On 7/14/2015 3:18 AM, Alan Snyder wrote:
I have a concern about how custom multiresolution images are supported based on
a problem I ran into using the JDK 8 classes, which are similar.
The problem is that the selection of a variant image happens during painting.
That is a very bad time to actually try to render an image, if one is in a
situation where images of arbitrary resolution can be produced by rendering.
If I have code now that uses a background thread to create an image in this
manner, how can I support HiDPI displays? Creating a multiresolution image
defeats the purpose of using a background thread if it defers rendering until
paint time. It seems that the best I can do is to guess what resolutions might
be wanted and generate them all in advance or, alternatively, generate the
highest resolution I expect to need, and have the graphics system scale it down
for lower resolutions when requested. Neither of these alternatives is optimal.
JDK 9 has the fix that includes the scale factor in the
GraphicsConfiguration default transform:
http://hg.openjdk.java.net/jdk9/client/jdk/rev/661136704d07
It is possible to iterate over all graphics devices, decide on which
device the image is supposed to be rendered and generate an image
resolution according to the scale factor from the device graphics
configuration.
Thanks,
Alexandr.
Although the Image class does allow images to be produced in the background,
that API is way too complex for use by an application, and the supporting code
for Toolkit images is not accessible.
It would be nice to have a simple way to return an image that is produced in the
background. Something like Future<Image>?
Alan
