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