I am commenting on your suggestion that I can determine which display the image
will displayed on.
> On Jul 15, 2015, at 7:42 AM, Alexander Scherbatiy
> <alexandr.scherba...@oracle.com> wrote:
>
> 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>
>>> <mailto: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
