How will resolution independence be handled in jdk8?

Hendrik Schreiber hs at
Tue Apr 23 11:55:43 PDT 2013

On Apr 23, 2013, at 7:03 PM, Sergey Bylokhov wrote:

> Hi, Hendrik.
> On 23.04.2013 19:05, Hendrik Schreiber wrote:
>> Will we simply be able to call
>> 	graphics.drawImage(img, x, y, w, h, obs);
>> and if the image is twice the size of w/h (=4xarea) and a Retina display is present, the image is drawn with sub-pixel resolution? I.e. in effect not scaled, but simply drawn?
> Yes, it should work in this way.
>> If so, will there be a way to find out the scale factor, i.e. the factor between pixel based resolution and true display sub-pixel capability? To illustrate, for Retina this factor is 2x. After all, we need to know, what kind of images to load for a high resolution capable app.
> Currently there is no such info, but it will be added. Therefore while it is not implemented, any suggestions are welcome.

In the Apple 6 JVM this was available as 

final Float scaleFactor = (Float) Toolkit.getDefaultToolkit().getDesktopProperty("apple.awt.contentScaleFactor");

I'd prefer this to be exposed via a method, perhaps in java.awt.GraphicsDevice - looks like sun.awt.CGraphicsDevice already has a method called:

public int getScaleFactor();

Perhaps it makes sense to make this public through java.awt.GraphicsDevice? Should it be int? Or float?

In any case, the Apple JVM was lacking the ability to detect changes. I.e. there was no way to be notified when the user changed from Retina mode to regular mode. But there should be some kind of property change support.

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

Something else missing from the (public) Apple implementation was the ability to create such multiresolution images programmatically. I.e. something like new MultiResImage(regImage, hiResImage);
To make this kind of API complete, you might also want to add a property scaleFactor to the Image class (or a subclass), which is honored by graphics.drawImage(img, x, y, obs), so one does not always have to specify width and height, but scaling is done automatically for you...

Well, as you probably realized by now, I am no expert when it comes to resolution independence, nor have I thought this all the way through - but I guess it's a start...


More information about the macosx-port-dev mailing list