On Nov 12, 2013, at 7:10 PM, Jim Graham <james.gra...@oracle.com> wrote:
> 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?) This check seems correct to me. If either the w or h of the destination rect needs more pixels than is available from w or h of a given representation, the logic should choose the next representation, or fall back to scaling up the available pixels in the largest representation (insert caveats about bit depth, color space, and vector drawing resources like PDF). > 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? In the demo that I sent you — the @2x gets chosen when displaying a scaled up image on a non-Retina display. The @2x is nothing special; it's just another representation. This is how NSImage has always worked long before Retina, since Mac OS X 10.0, AFAIK. > 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, etc.) > > - 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 > surprising... > > ...jim I hope I haven't surprised anyone. :-) Regards, Mike Swingler Apple Inc. > 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.gra...@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.gra...@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. >>>> >>
