How will resolution independence be handled in jdk8?

[Hendrik Schreiber]

Am 29.04.2013 um 12:15 schrieb Artem Ananiev <artem.ananiev at oracle.com>:

> 
> 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.
> 

It would be much preferable, if the app provided multiple resolutions at creation time of the button and the button always picked the best one when it's drawn. Like in Cocoa's NSImage class. Saves the programmer a lot of trouble...

Seriously, as an application programmer, do you really want to keep track of every image in your app, to replace it when the GraphicsDevice changes...? That would be really cumbersome...

-hendrik