It seems you are making an assumption that the code that creates the image is somehow initiated from a paint method so that the display scale factor can be obtained from the graphics context and used to determine the required image resolution. That is not the scenario I am concerned about.
I am talking about what I would consider a common case: a program that was written before the concept of HiDPI displays existed and is being adapted to support HiDPI displays. In this case, because the image creation is potentially a long running process, the program is written to use a background thread to create the image. Once the image is created, it is stored somewhere that can be accessed by a painting method of a component. Prior to the image becoming available, the component will paint some default background or perhaps paint a default image. I do not want to rearchitect the program to support HiDPI displays. Using the display scale information for the available displays, I could create a multiresolution image in the background thread that either contains multiple images for all available displays or contains one image at the maximum required resolution of the available displays. However, these solutions are non-optimal. Either images may be created that will never be used or image scaling may be used to reduce the resolution, which may result in a lower quality image. What I would like to do is create a multiresolution image that tells my code what resolution image is needed and allows me to create that image on a background thread. In additional to solving the HiDPI problem optimally, this solution would support less common cases, such as displays added to the system at run time and graphics contexts that are scaled for some reason other than supporting a HiDPI display. I am assuming this capability already exists to support toolkit images. It would be nice to make that capability available to applications. Alan > On Jul 15, 2015, at 4:07 AM, Alexander Scherbatiy > <alexandr.scherba...@oracle.com> wrote: > > 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 >> >
