On 7/15/2015 5:09 PM, Alan Snyder wrote:
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.
The information about screen devices are available from the
GraphicsEnvironment.
Something like:
----------------------
public static void main(String[] args) {
GraphicsEnvironment ge =
GraphicsEnvironment.getLocalGraphicsEnvironment();
for(GraphicsDevice device: ge.getScreenDevices()){
for(GraphicsConfiguration config: device.getConfigurations()){
if(!config.getDefaultTransform().isIdentity()){
System.out.println("Start high-resolution image
loading");
}
}
}
}
----------------------
Thanks,
Alexandr.
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
<mailto: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
