[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos look perfect o
From:       Mike Swingler <swingler () apple ! com>
Date:       2013-12-05 20:07:39
Message-ID: D3C8A49A-260A-4585-AF95-D76AC0BCF32E () apple ! com
[Download RAW message or body]

On Dec 3, 2013, at 10:10 AM, Jim Graham <james.graham@oracle.com> wrote:

> Hi Mike,
> 
> One more question about @2x handling on MacOS.
> 
> Clearly, in the simple case of someone loading an ordinary "foo.png" and painting \
> it on a retina display without doing anything special with the transform, it will \
> be scaled up by 2x to retain proper size. 
> Also, clearly, if a "foo@2x.png" file exists, it will be loaded automatically and \
> found to be twice as large and displayed with no scaling so that it is the same \
> "size". 
> But, what if in the first step they manually specified the image file name as \
> "foo@2x.png" (and assuming there is no "foo@2x@2x.png")?  Will it display with its \
> pixels scaled up to double sized because it was the direct image that they \
> specified?

Yes, explicitly asking for "foo@2x" cause the search machinery to look for \
"foo@2x.png" and "foo@2x@2x.png".

> Or, does the system recognize that it came from a file named @2x and assume that it \
> is a double-screen-resolution image and paint it the same way it would have done if \
> it was implicitly loaded as the higher resolution variant of "foo.png"?

No. Images reps loaded with the @2x suffix are not special — they are just an \
additional representation of the same named image, and could vary unpredictable in \
dimensions, bit depth, and color space. We simply prefer that they not. :-)

> Let me spell out the scenarios:
> 
> Scenario 1:
> - app is retina-enabled
> - app has WxH foo.png media (and no @2x versions)
> - app loads image from "foo.png"
> - app displays image with standard default scaling on a retina screen
> => result is image takes up 2W x 2H pixels on the retina screen
> 
> Scenario 2:
> - app is retina-enabled
> - app has WxH foo.png media
> - app also has 2W x 2H foo@2x.png media
> - app loads image from "foo.png"
> - app displays image with standard default scaling on a retina screen
> => result is system also loads foo@2x.png and displays it with 2W x 2H retina \
> pixels on the retina screen - the same physical size as in the previous example 
> Scenario 3:
> - app is retina-enabled
> - app has WxH foo.png media
> - app also has 2W x 2H foo@2x.png media
> - app loads image from "foo@2x.png" rather than "foo.png"
> - app displays image with standard default scaling on a retina screen
> => result is ???
> => I'm guessing that it gets drawn twice the size as Scenario's 1 and 2 because it \
> is no longer relative to the WxH base image? 
> Scenario 4:
> same as Scenario 3, but foo.png doesn't exist, foo@2x.png is the only version found \
> in the media for the app => result is ???
> => I'm guessing the result is the same as Scenario 3
> 
> Also, the convention is for the @2x image to be twice the pixel size of the regular \
> image, but what if it isn't?  Is it always drawn at a 0.5x relative scale because \
> of the implication of the @2x file name, or will it be dynamically sized for \
> "basew/@2xw, baseh/@2xh" which just usually works out to 0.5x if the author \
> followed conventions? 
> 			...jim

@2x in the file name is just a hack to add more representations to images that are \
not already multi-rep (.png vs. .tiff and .icns). The actual dimensions of the image \
dictate when/how it gets used at runtime. I believe the search for @2x variants is \
only performed if the original image rep is not sufficient to fully fill the rect of \
pixels in the destination.

Regards,
Mike Swingler
Apple Inc.


[prev in list] [next in list] [prev in thread] [next in thread]