How will resolution independence be handled in jdk8?

Artem Ananiev artem.ananiev at oracle.com
Mon Apr 29 03:15:58 PDT 2013


On 4/27/2013 1:42 AM, Hendrik Schreiber wrote:
> On Apr 23, 2013, at 8:55 PM, Hendrik Schreiber wrote:
>
>> [...]
>> Back to loading and drawing images.
>>
>> Apple supported the @2x hack. That is, one could load images using
>> a resource name (e.g. "image") and the system would use
>> automatically either "image.png" or "image at 2x.png" when drawing,
>> depending on the current scale factor. Perhaps this kind of Image
>> class that is backed by multiple resolution optimized Images and a
>> corresponding loading mechanism is something nice to have, too.
>> Mike Swingler can describe the mechanism probably much better...
>
> BTW - something like this will be a necessity. Just think of images
> in JButtons. You have to be able to pass some image into the button,
> and the button needs to be able to correctly draw either a low or a
> high resolution version. Automatically. Because it is close to
> impossible to mess around with the actual drawing mechanism inside of
> the ButtonUI...

As you wrote above, @2x looks like a hack. Although we can support 
something like this in JDK7/8, I would prefer to have clear API to 
handle different scale factors. For example, API to listen for Window's 
graphics configuration changes and getter for the current scale factor 
value. In this case, application will be able to load a new image for 
the new scale factor and assign it to the button. A little piece of 
trivial code vs magic NSImage:// images.

Of course, if we decide to provide any new public APIs, it can only be 
done in JDK8 or later. JDK7 API is frozen.

Thanks,

Artem

> -hendrik


More information about the macosx-port-dev mailing list