<AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

Jim Graham james.graham at oracle.com
Tue Nov 12 19:10:23 PST 2013

So, then, it sounds like on the Mac the "default heuristic" should be to 
take the transform into account and choose @2x based on that.  We don't 
yet know if that matches the default Windows 8 heuristics, but we only 
have 1 platform that has this enabled so far.

One last question (OK 2) for Mike - I want to be sure that we get the 
algorithm right, you said "if the backing store would be the same size 
or smaller than the @1x" which implies that the code in the fix "if (w 
<= imgw && h <= imgh) regular : @2x" matches the heuristics in Cocoa? 
(i.e. && and <= are the correct comparison and logic?)

And question #2, if they are running on a display with pixel scale of 
1.0, does the @2x get chosen when they scale up?  Or do the @2x media 
only even get considered on pixel scaled displays?

Given that, I'd recommend:

- Add the DEFAULT setting for the SunHint which will basically say "do 
as Mac does when on a Mac"  (and eventually as Win8 does while on Win8, 

- the current fix has the choice in the macosx code, which is good

- the current API provides the scaled dimensions, which is good for the 
mac code, but we may need to make more data available once we learn how 
other platforms solve this problem

- we may want to beef up the hints later with "choose based on Screen" 
vs "choose based on pixel size", but for now this API is sun.* private 
so lets just leave it with ON/OFF/DEFAULT.

- Hopefully the answers to the above 2 questions for Mike won't be 


On 11/12/13 6:46 PM, Mike Swingler wrote:
> The story is a little more complicated: NSImage always picks the "best" representation based on the computed size of the backing pixel rect taking all graphics transforms into account. For icons, which usually have dozens of representations, there isn't a single "@2x" representation.
> This means that by switching screens, an icon can flip from a cartoonish 16x16 rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only reps available. The multi-rep support in NSImage can also defer to a PDF representation if available when it can't find an exact dimension and bit-depth match for raster representations.
> This does mean that an icon with 12 or so representations will visually glitch when smooth scaled as bits of detail come and go...but in the general case, most images tend to only have 2 reps and developers don't animate between them.
> So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if the transform causes the rect in the pixel backing store to be the same size or smaller than the @1x.
> I'll privately send along a little app that demonstrates this.
> Regards,
> Mike Swingler
> Apple Inc.
> On Nov 12, 2013, at 5:52 PM, Jim Graham <james.graham at oracle.com> wrote:
>> Hi Mike,
>> Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001?
>> 		...jim
>> On 11/12/2013 5:48 PM, Mike Swingler wrote:
>>> On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:
>>>> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.
>>> The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.
>>> Regards,
>>> Mike Swingler
>>> Apple Inc.

More information about the awt-dev mailing list