[OpenJDK 2D-Dev] <AWT Dev> Review request for 8029339 Custom MultiResolution image support on HiDPI displays

[Alexander Scherbatiy]

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.scherbatiy at oracle.com 
>> <mailto:alexandr.scherbatiy at 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
>>>
>>
>