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. 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
