From joe.darcy at oracle.com  Wed Dec 10 00:41:34 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 09 Dec 2014 16:41:34 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
Message-ID: <548796BE.2030504@oracle.com>

Hello,

In support of JEP 212: Resolve Lint and Doclint Warnings 
(http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please 
review the large but straightforward set of changes in the webrev:

     http://cr.openjdk.java.net/~darcy/8066621.0/

Some background of the approach being taken to address this part of JEP 
212 was discussed on core-libs:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html

Briefly, to allow the deprecation warnings to be dealt with and that 
sole remaining lint warning category enabled in the build, a two-step 
approach is being taken. The first step is to suppress the deprecation 
warnings and the second step is for area-experts to examine the specific 
uses of deprecated APIs in their code. This webrev only attempts to 
cover the first step.

The webrev is based off of the JDK 9 "dev" forest rather than the 
"client" forest. Since the change only involves copyright updates and 
adding annotations, there would be no functional modification in the 
changeset. Therefore, I would strongly prefer to push these changes 
directly to dev rather than pushing them to client and waiting for them 
to propagate to dev to expedite the time when the build warning can be 
enabled. (If a warning is not enabled in the build, new instances of the 
warning tend to creep into the code base.)

Thanks,

-Joe


From alexandr.scherbatiy at oracle.com  Wed Dec 10 11:29:42 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 10 Dec 2014 14:29:42 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <53F4D680.60902@oracle.com>
References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com>
	<52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com>
	<52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com>
	<53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com>
	<530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com>
	<532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com>
	<532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com>
	<53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com>
	<533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com>
	<535A7509.6050802@oracle.com> <5370DC41.5080608@oracle.com>
	<537639D5.9000206@oracle.com> <53764700.2060309@oracle.com>
	<5379E117.6010202@oracle.com> <538F2D56.80609@oracle.com>
	<5396220E.9030708@oracle.com> <5397180C.5040105@oracle.com>
	<53987361.5040903@oracle.com> <53BC0803.6090704@oracle.com>
	<53D7B35B.1010703@oracle.com> <53F4D680.60902@oracle.com>
Message-ID: <54882EA6.5030405@oracle.com>



   Hi Phil,

   Could you look at the two suggested ways of the multi-resolution 
image support API implementation?

   Thanks,
   Alexandr.

On 8/20/2014 8:10 PM, Alexander Scherbatiy wrote:
>
>   Hi Phil,
>
>   I have prepared the fix where resolution variants are added directly 
> to the Image:
>    http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
>
>   You could compare this with the previous version where 
> MultiResolutionImage interface is used:
>     http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
>
>   It could help to decide in which way it is better to provide the 
> multi-resolution image support.
>
>   Below are some comments:
>
>   1. High level goal:
>      Introduce an API that allows to create and handle an image with 
> resolution variants.
>
>   2. What is not subject of the provided API
>     - Scale naming convention for high-resolution images
>     - Providing pixel scale factor for the screen/window
>
>   3. Use cases
>
>    3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
>      A high-resolution image is loaded from resources and stored in 
> JBHiDPIScaledImage class  which is a subclass of the buffered image.
>      The high-resolution image is used to create a disabled icon in 
> the IconLoader.getDisabledIcon(icon) method.
> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java 
>
>
>    3.2 Loading and drawing high-resolution icons in NetBeans
>      NetBeans does not have support for the high-resolution icons 
> loading.
>      It loads an icon from the file system using 
> Toolkit.getDefaultToolkit().getImage(url) method or from resources
>      by  ImageReader  and store it in ToolTipImage class which is 
> subclass of the buffered image.
>      ImageUtilities.createDisabledIcon(icon) method creates a disabled 
> icon by applying  RGBImageFilter to the icon.
> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java 
>
>
>    3.3 Loading system icons in JDK 1.8
>      JDK requests icons from the native system for system L&Fs and 
> applies filters for them.
>      See for example AquaUtils.generateLightenedImage() method:
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java 
>
>
>   4. HiDPI support for Images on different OSes
>
>     4.1 Mac OS X
>       Cocoa API contains NSImage that allows to work with image 
> representations: add/remove/get all representations.
>       It picks up an image with necessary resolution based on the 
> screen backing store pixel scale factor and applied transforms.
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html 
>
>
>     4.2 Linux
>       GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not 
> public/stable)
>       that parses the -gtk-scaled css property and draws a GtkCssImage 
> according to the given scale factor.
>
>       I have not found information about the HiDPI support in Xlib.
>
>     4.3 Windows
>       I have only found the tutorial that suggests to select and draw 
> a bitmap using the queried DPI
>       and scale the coordinates for drawing a rectangular frame
> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
>
>       Windows also provides the horizontal and vertical DPI of the 
> desktop
> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>
>   5. Pseudo API
>      Below are some ways which illustrates how multi-resolution images 
> can be created and used.
>
>     5.1 Resolution variants are stored directly in Image class.
>     To query a resolution variant it needs to compare the resolution 
> variant width/height
>     with the requested high-resolution size.
>     ------------
>     public abstract class Image {
>
>         public void addResolutionVariant(Image image) {...}
>         public List<Image> getResolutionVariants() {...}
>     }
>     ------------
>     // create a disabled image with resolution variants
>
>     Image disabledImage = getDisabledImage(image);
>
>     for (Image rv : image.getResolutionVariants()) {
>         disabledImage.addResolutionVariant(getDisabledImage(rv));
>     }
>     ------------
>     This approach requires that all resolution variants have been 
> created even not of them are really used.
>
>     5.2  Resolution variants are stored in a separate object that 
> allows to create them by demand.
>     To query a resolution variant it needs to compare the resolution 
> variant scale factor
>     with the requested scale (that can include both screen DPI scale 
> and applied transforms).
>     ------------
>     public abstract class Image {
>
>         public static interface ResolutionVariant {
>             Image getImage();
>             float getScaleFactor();
>         }
>
>         public void addResolutionVariant(ResolutionVariant 
> resolutionVariant) {...}
>         public List<ResolutionVariant> getResolutionVariants() {...}
>     }
>     ------------
>     // create a disabled image with resolution variants
>     Image disabledImage = getDisabledImage(image);
>
>     for (Image.ResolutionVariant rv : image.getResolutionVariants()) {
>         disabledImage.addResolutionVariant(new 
> Image.ResolutionVariant() {
>
>             public Image getImage() {
>                 return getDisabledImage(rv.getImage());
>             }
>
>             public float getScaleFactor() {
>                 return rv.getScaleFactor();
>             }
>         });
>     }
>     ------------
>
>     It does not have problem if a predefined set of images is provided 
> (like image.png and image at 2x.png on the file system).
>     This does not cover cases where a resolution variant can be 
> created using the exact requested size (like loading icons from the 
> native system).
>     A resolution variant can be queried based on a scale factor and 
> applied transforms.
>
>     5.3 The provided example allows to create a resolution variant 
> using the requested high-resolution image size.
>     ------------
>     public interface MultiResolutionImage {
>         Image getResolutionVariant(float width, float height);
>     }
>     ------------
>     // create a multi-resolution image
>     Image mrImage = new AbstractMultiResolutionImage() {
>
>             public Image getResolutionVariant(float width, float 
> height) {
>                 // create and return a resolution variant with exact 
> requested width/height size
>             }
>
>             protected Image getBaseImage() {
>                 return baseImage;
>             }
>         };
>     ------------
>     // create a disabled image with resolution variants
>     Image disabledImage = null;
>     if (image instanceof MultiResolutionImage) {
>         final MultiResolutionImage mrImage = (MultiResolutionImage) 
> image;
>         disabledImage = new AbstractMultiResolutionImage(){
>
>             public Image getResolutionVariant(float width, float 
> height) {
>                 return 
> getDisabledImage(mrImage.getResolutionVariant(width, height));
>             }
>
>             protected Image getBaseImage() {
>                 return getDisabledImage(mrImage);
>             }
>         };
>     } else {
>         disabledImage = getDisabledImage(image);
>     }
>     ------------
>
>   Thanks,
>   Alexandr.
>
>
> On 7/29/2014 6:44 PM, Alexander Scherbatiy wrote:
>>> On 6/11/2014 7:18 PM, Alexander Scherbatiy wrote:
>>>>
>>>>  Hi Phil ,
>>>>
>>>>  I just prepared a simple FAQ about the Custom MultiResolution 
>>>> image API. Hope it will be helpful.
>>>>
>>>> 1. Scale naming convention for high-resolution images.
>>>>
>>>>  Different OSes use different "scale" naming convention for 
>>>> high-resolution images:
>>>>  Mac OS X: image.ext, image at 2x.ext
>>>>  Windows: image.scale-100.ext, image.scale-140.ext, 
>>>> image.scale-180.ext
>>>>
>>>>  Q: Does "scale" naming convention supported in JDK?
>>>>  A: Mac OS X "scale" naming convention are supported in JDK 8u20 
>>>> (see JDK-8011059)
>>>>       It is planned to support the Windows "scale" naming 
>>>> convention as well.
>>>>
>>>>  Q. How does it work in JDK?
>>>>  A. Bundle image.ext and image at 2x.ext images with your app on Mac 
>>>> OS X and call Toolkit.getImage(...) method:
>>>>         Image image = 
>>>> Toolkit.getDefaultToolkit().getImage("image.ext");
>>>>         Graphics2D g2d = // get graphics
>>>>         g2d.drawImage(image, 0, 0, null)
>>>>   SunGraphics2D automatically queries and draws the provided 
>>>> high-resolution image.
>>>>
>>>>   Q: There are different "scale" naming conventions on Mac OS X and 
>>>> Windows.
>>>>        May be it is better to have unified "scale" naming 
>>>> conventions for all OSes in Java like image[java-scale-Nx].ext?
>>>>   A: It seems reasonable and can be filled as a new JDK enhancement.
>>>>
>>>>   Q: Does using "scale" naming conventions solves all problems.
>>>>   A: There are tasks like image processing/programmatically 
>>>> generated images/loading images from non-standard sources
>>>>        that can't be solved with predefined set of images.
>>>>   Q: Are there any tools that support these tasks?
>>>>   A: Cocoa API contains NSImage that allows to work with image 
>>>> representations: 
>>>> addRepresentation/removeRepresentation/representations
>>>>       JDK uses these methods to get/set multi-resolution images for 
>>>> the Native system (see sun.lwawt.macosx.CImage class).
>>>>
>>>> 2. Graphics2D
>>>> Q: How SunGraphics2D deals with multi-resolution images?
>>>> A: SunGraphics2D queries a resolution variant using DPI scale 
>>>> factors and transformed base image sizes
>>>>        //   logicalDPIX, logicalDPIY - DPI scale factors
>>>>        //   destImageWidth, destImageHeight - transformed base 
>>>> image sizes including DPI scale factors
>>>> multiResolutionImage.getResolutionVariant(logicalDPIX, logicalDPIY, 
>>>> destImageWidth, destImageHeight);
>>>>
>>>> Q: Which algorithm multi-resolution image is used in 
>>>> getResolutionVariant(...) method?
>>>> A:  ToolkitImage returned by toolkit.loadImage() method should 
>>>> behave like the native system.
>>>>      It means that it should use transformed image sizes on Mac OS 
>>>> X and only DPI scale factors on Windows.
>>>>      it looks like:
>>>>         -----------------
>>>>        //   logicalDPIX, logicalDPIY - DPI scale factors
>>>>        //   destImageWidth, destImageHeight - transformed base 
>>>> image sizes including DPI scale factors
>>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>>> logicalDPIY,
>>>>                 float destImageWidth, float destImageHeight) {
>>>>                   if (Mac OS X) {
>>>>                        return resolution variant best fitted to the 
>>>> destImageWidth and destImageHeight
>>>>                   } else if (Windows){
>>>>                        return resolution variant best fitted to the 
>>>> logicalDPIX and logicalDPIY scale factors
>>>>                   }
>>>>         }
>>>>         -----------------
>>>>
>>>>  3. Custom multi-resolution image.
>>>>  Q: The custom multi-resolution image should be able to return an 
>>>> image according to the requested
>>>>       transformed image size and DPI scale factors. Is it enough?
>>>>   A: There are task like setting custom cursor that require to get 
>>>> all resolution variants.
>>>>       So the custom multi-resolution image should also contain the 
>>>> getResolutionVariants():
>>>>
>>>>  Q: Should the custom multi-resolution image be class or interface?
>>>>  A: There is ToolkitImage that should also have resolution variants.
>>>>    It is not possible to extend it from MultiResolutionImage class.
>>>>    The current proposal introduces the MultiResolutionImage as an 
>>>> interface.
>>>>
>>>>  Q: MultiResolutionImage interface sounds strange for me.
>>>>  A: The better name can be suggested.
>>>>
>>>>   Q: What does the Custom MultiResolution image API suggest?
>>>>   A:  The current proposal provides MultiResolutionImage interface 
>>>> with the following methods:
>>>>     ---------------------------
>>>>     Image getResolutionVariant(float logicalDPIX, float logicalDPIY,
>>>>             float destImageWidth, float destImageHeight);
>>>>
>>>>     List<Image> getResolutionVariants();
>>>>     ---------------------------
>>>>   and AbstractMultiResolutionImage class. See samples below.
>>>>
>>>>
>>>>  4. Memory cost
>>>>  Q: Can the the implementation be "lazy"?
>>>>  A: SunGraphics2D does not require full list of resolution 
>>>> variants. It queries only the image with necessary resolution.
>>>>      It means that resolution variants can be loaded by demand.
>>>>    Setting a custom cursor requires all resolution variants.
>>>>
>>>>  5. Rendering hints.
>>>>  Q: Why rendering hints are added.
>>>>  A: Provided rendering hints affects only multi-resolution images 
>>>> and allows to disable
>>>>      resolution variants usage in app. It can be useful for 
>>>> performance reasons.
>>>>
>>>>  6. Samples.
>>>>  Q: It is interesting to look at samples.
>>>>  A: Below are 3 samples:
>>>>      1. Draw an image with "Hello World!" text
>>>>      2. Set a lightened custom cursor
>>>>      3. Draw a multi-resolution image created from the program
>>>>
>>>>    Sample 1. Draw a image with "Hello World!" text. The text is 
>>>> drawn both on the base image and on high-resolution image.
>>>>        disk: duke.png, duke at 2x.png
>>>>    -------------------------------
>>>>     public static void main(String[] args) {
>>>>
>>>>         Image image = 
>>>> Toolkit.getDefaultToolkit().getImage("duke.png"); // duke.png and 
>>>> duke at 2x.png images are loaded by MR-ToolkitImage
>>>>
>>>>         Image imagewithText = image instanceof MultiResolutionImage
>>>>                 ? new TextMultiresolutionImage(image) : 
>>>> drawText(image);
>>>>
>>>>         Graphics2D g2d = // get graphics 2D
>>>>         g2d.drawImage(imagewithText, x, y, null);
>>>>     }
>>>>
>>>>     static Image drawText(Image image) {
>>>>         // return an image with "Hello World!" text
>>>>     }
>>>>
>>>>     static class TextMultiresolutionImage extends 
>>>> AbstractMultiResolutionImage {
>>>>
>>>>         private final Image baseImage;
>>>>
>>>>         public TextMultiresolutionImage(Image baseImage) {
>>>>             this.baseImage = baseImage;
>>>>         }
>>>>
>>>>         @Override
>>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>>> logicalDPIY,
>>>>                 float destImageWidth, float destImageHeight) {
>>>>             Image rvImage = ((MultiResolutionImage) baseImage).
>>>>                     getResolutionVariant(logicalDPIX, logicalDPIY,
>>>>                             destImageWidth, destImageHeight);
>>>>             return drawText(rvImage);
>>>>         }
>>>>
>>>>         @Override
>>>>         public List<Image> getResolutionVariants() {
>>>>                // this method is not used by SunGraphics2D to draw 
>>>> the image.
>>>>               // we just skip it in this example
>>>>         }
>>>>
>>>>         @Override
>>>>         protected Image getBaseImage() {
>>>>             return drawText(baseImage);
>>>>         }
>>>>     }
>>>>    -------------------------------
>>>>
>>>>   Sample 2. Using filters to create a lightened  custom cursor.
>>>>   The filter is applied to both the base and high-resolution image.
>>>>    -------------------------------
>>>>     public static void main(String[] args) {
>>>>
>>>>         Image image = 
>>>> Toolkit.getDefaultToolkit().getImage("cursor.png"); // cursor.png 
>>>> and cursor at 2x.png files are provided
>>>>         Image lightenedImage = image instanceof MultiResolutionImage
>>>>                 ? new LigtenedMultiresolutionImage(image) : 
>>>> applyFilter(image);
>>>>
>>>>         Cursor lightenedCursor = Toolkit.getDefaultToolkit().
>>>>                 createCustomCursor(lightenedImage, new Point(0, 0), 
>>>> "Lightened Cursor");
>>>>         JFrame frame = new JFrame("Frame with lightened cursor");
>>>>         frame.setCursor(lightenedCursor);
>>>>     }
>>>>
>>>>     static Image applyFilter(Image image) {
>>>>         GrayFilter filter = new GrayFilter(true, 50);
>>>>         final ImageProducer prod = new 
>>>> FilteredImageSource(image.getSource(), filter);
>>>>         return Toolkit.getDefaultToolkit().createImage(prod);
>>>>     }
>>>>
>>>>     static class LigtenedMultiresolutionImage extends 
>>>> AbstractMultiResolutionImage {
>>>>
>>>>         private final Image baseImage;
>>>>
>>>>         public LigtenedMultiresolutionImage(Image baseImage) {
>>>>             this.baseImage = baseImage;
>>>>         }
>>>>
>>>>         @Override
>>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>>> logicalDPIY,
>>>>                 float destImageWidth, float destImageHeight) {
>>>>               // this method is not necessary for the custom cursor 
>>>> creation
>>>>              // we just skip it
>>>>         }
>>>>
>>>>         // all resolution variants are created to pass them to 
>>>> NSImage for the custom cursor on Mac OS X.
>>>>         @Override
>>>>         public List<Image> getResolutionVariants() {
>>>>             List<Image> resolutionVariants = new LinkedList<>();
>>>>             for (Image rvImage : ((MultiResolutionImage) baseImage).
>>>>                     getResolutionVariants()) {
>>>> resolutionVariants.add(applyFilter(rvImage));
>>>>             }
>>>>             return resolutionVariants;
>>>>         }
>>>>
>>>>         @Override
>>>>         protected Image getBaseImage() {
>>>>             return applyFilter(baseImage);
>>>>         }
>>>>     }
>>>>    -------------------------------
>>>>
>>>>    Sample 3. Draw a multi-resolution image created from the program:
>>>>    -------------------------------
>>>>     public static void main(String[] args) {
>>>>
>>>>         Image image = generateImage(1);
>>>>         Image image2x = generateImage(2);
>>>>         Image mrImage = new CustomMultiresolutionImage(image, 
>>>> image2x);
>>>>
>>>>         Graphics2D g2d = // get graphics2D
>>>>         g2d.drawImage(mrImage, 0, 0, null);
>>>>     }
>>>>
>>>>     static Image generateImage(float scaleFactor) {
>>>>         // generate image according to the scale factor
>>>>     }
>>>>
>>>>     static class CustomMultiresolutionImage extends 
>>>> AbstractMultiResolutionImage {
>>>>
>>>>         private final Image image;
>>>>         private final Image highResolutionImage;
>>>>
>>>>         public CustomMultiresolutionImage(Image baseImage, Image 
>>>> highResolutionImage) {
>>>>             this.image = baseImage;
>>>>             this.highResolutionImage = highResolutionImage;
>>>>         }
>>>>
>>>>         @Override
>>>>         public Image getResolutionVariant(float logicalDPIX, float 
>>>> logicalDPIY,
>>>>                 float destImageWidth, float destImageHeight) {
>>>>             // destImageWidth and destImageHeight includes both 
>>>> transforms
>>>>             // DPI scale factors from Graphics
>>>>             if (destImageWidth <= image.getWidth(null)
>>>>                     && destImageHeight <= image.getHeight(null)) {
>>>>                 return image;
>>>>             }
>>>>             return highResolutionImage;
>>>>         }
>>>>
>>>>         @Override
>>>>         public List<Image> getResolutionVariants() {
>>>>             return Arrays.<Image>asList(image, highResolutionImage);
>>>>         }
>>>>
>>>>         @Override
>>>>         protected Image getBaseImage() {
>>>>             return image;
>>>>         }
>>>>     }
>>>> -------------------------------
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>
>>>> On 6/10/2014 6:37 PM, Alexander Scherbatiy wrote:
>>>>> On 6/10/2014 1:07 AM, Phil Race wrote:
>>>>>> Why the split ?
>>>>>> If you look only at the first part. If you can do that then why 
>>>>>> is the 2nd part needed ?
>>>>>    The second part introduces algorithms that can be used to 
>>>>> retrieve a resolution variant
>>>>>    from a set of images. It can be DPI based, transform based, OS 
>>>>> based and so on.
>>>>>    The first part can be implemented without the second part.
>>>>>
>>>>>> The name "MultiResolutionImage" implies to me that this is a 
>>>>>> sub-class of Image.
>>>>>> But its not, its a way to get images. 
>>>>>> AbstractMultiResolutionImage, however is
>>>>>> a subclass and it implements the former.
>>>>>
>>>>>    Could you suggest the better name? It really needs to have an 
>>>>> interface if existed image implementation
>>>>>    is supposed to have resolution variants. The example which is 
>>>>> used in JDK is ToolkitImage.
>>>>>    Toolkit.getImage(filename) method returns ToolkitImage which is 
>>>>> loaded by demand.
>>>>>    LWCToolkit should return an image with resolution variants on 
>>>>> Mac OS X if both image and  image at 2x
>>>>>    are provided. What we need here is the  ToolkitImage that 
>>>>> contains resolution  variants.
>>>>>    It can be done if the MultiResolutionImage is an interface and 
>>>>> it is not possible to do if MultiResolutionImage is a class.
>>>>>    Here is the MultiResolutionToolkitImage implementation:
>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b7ef5e2d252c/src/share/classes/sun/awt/image/MultiResolutionToolkitImage.java 
>>>>>
>>>>>
>>>>>> I am supposing (since you don't explain) that you want an Image 
>>>>>> sub-class here
>>>>>> so that the app can specify it where ever an Image is currently 
>>>>>> accepted by API
>>>>>> and the API that is "aware" can accept it.
>>>>>     If an image implements the MultiResolutionImage interface, 
>>>>> SunGraphics2D can use it
>>>>>     to draw an image with necessary resolution on HiDPI display.
>>>>>
>>>>>> I worry about the memory cost of all of this. Can the the 
>>>>>> implementation be "lazy"?
>>>>>     Yes. See the MultiResolutionCachedImage implementation:
>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b7ef5e2d252c/src/share/classes/sun/awt/image/MultiResolutionCachedImage.java 
>>>>>
>>>>>> ie even if I call getResolutionVariants() do those images all 
>>>>>> have to be fully initialised before
>>>>>> they are used? It looks like the app probably has to do so ..
>>>>>     If it needs to pass resolution variants to the native system 
>>>>> like setting a custom cursor on Mac OS X
>>>>>     it really needs to initialize all resolution variants.
>>>>>
>>>>>      If it needs to create one multi-resolution image based on 
>>>>> another multi-resolution image like
>>>>>      generating a lightening image using a filter, it possible to 
>>>>> do this lazy.
>>>>>      See the map(Function<Image, Image> mapper) method in the 
>>>>> MultiResolutionCachedImage.
>>>>>
>>>>>    SunGraphics2D class uses only getResolutionVariant( ...) method 
>>>>> to retrieve necessary resolution variant.
>>>>>    It does not call getResolutionVariants() methods so all 
>>>>> resolution variants are not created during image drawing.
>>>>>
>>>>>>
>>>>>> Also it precludes being able to return "on demand" an image that 
>>>>>> is rendered to
>>>>>> be exactly the size requested. That could be created, drawn using 
>>>>>> graphics primitives
>>>>>> and created precisely and only if needed.
>>>>>>
>>>>>> Instead we have an API that requires you to apparentlty eagerly 
>>>>>> create even the
>>>>>> highest res image when you are on a device that has no need for it.
>>>>>>
>>>>>> Who will actually call getResolutionVariants() ? 
>>>>>     Both.
>>>>>> Is it us (the implementation) because we
>>>>>     We use it to create an NSImage from a custom cursor. See 
>>>>> Toolkit.createCustomCursor()
>>>>>    and CImage.createFromImage(final Image image) methods.
>>>>>
>>>>>    Developers can use it to show all resolution variants in some 
>>>>> image tool.
>>>>>
>>>>>> don't trust the app to make the right selection based on the 
>>>>>> parameterised call
>>>>>> getResolutionVariant() ?
>>>>>    As it shown, the getResolutionVariant(...) and 
>>>>> getResolutionVariants() methods are used
>>>>>    for different purposes.
>>>>>    getResolutionVariant(...) method is used by SunGraphics2D class 
>>>>> to pickup an image
>>>>>    with necessary resolution variant.
>>>>>    getResolutionVariants() method is used when an application 
>>>>> needs to use all resolution variants.
>>>>>
>>>>>>
>>>>>> Which approach do we use to pick the image ? If its the former, 
>>>>>> the app controls it,
>>>>>     It is the former.
>>>>>     We also use it MR-ToolkitImage to get a resolution variant 
>>>>> according to the current system (for example, transforms
>>>>>      are included to get resolution variant size on Mac OS X).
>>>>>
>>>>>> if its the latter its us. But which ?
>>>>>>
>>>>>> I am still stuck on the parameters to getResolutionVariant
>>>>>>
>>>>>>  * @param baseImageWidth the width of the base image.
>>>>>>
>>>>>>
>>>>>> Isn't the base image always the smallest ? 
>>>>>     No for general case. May be it would be possible to print a 
>>>>> multi-resolution image
>>>>>     on a printer that can have low DPI.
>>>>>
>>>>>> Why are we, the caller, supposed
>>>>>> to say what that size to the class that has that image.
>>>>>
>>>>>    This question has already had long discussion. The answer is 
>>>>> that we do it because it is free for us.
>>>>>    SunGraphics2D already gets the base image size because it uses 
>>>>> it for resolution image size calculation.
>>>>>    If you have objections against this, let's remove the base 
>>>>> image size parameters.
>>>>>    Developer always can obtain this information calling 
>>>>> getWidth()/Height() methods.
>>>>>
>>>>>> So I'd really like to see the example of that method in 
>>>>>> CustomMultiResolutionImage
>>>>>> filled out so we can see what is imagined here ..
>>>>>
>>>>>    Below are two samples.
>>>>>    The first one loads a multi-resolution image from disk, and 
>>>>> writes text "Hello World!" on it. Only getResolutionVariant(...) 
>>>>> method is used
>>>>>    by system in SunGraphics2D. The getResolutionVariants() method 
>>>>> is not used.
>>>>>
>>>>>    The second one creates a lightened custom cursor. The 
>>>>> getResolutionVariants() method is called by system to create 
>>>>> NSImage with necessary image representations.
>>>>>
>>>>>    Note that Toolkit.getImage(filename) method is already able to 
>>>>> load both image and image at 2x  images on Mac OS X.
>>>>>
>>>>>    Sample 1. Draw an image with "Hello World!" text:
>>>>>        disk: duke.png, duke at 2x.png
>>>>>    -------------------------------
>>>>>     public static void main(String[] args) {
>>>>>
>>>>>         Image image = 
>>>>> Toolkit.getDefaultToolkit().getImage("duke.png"); // duke.png and 
>>>>> duke at 2x.png images are loaded by MR-ToolkitImage
>>>>>
>>>>>         Image imagewithText = image instanceof MultiResolutionImage
>>>>>                 ? new TextMultiresolutionImage(image) : 
>>>>> drawText(image);
>>>>>
>>>>>         Graphics2D g2d = // get graphics 2D
>>>>>         g2d.drawImage(imagewithText, x, y, null);
>>>>>     }
>>>>>
>>>>>     static Image drawText(Image image) {
>>>>>         // return an image with "Hello World!" text
>>>>>     }
>>>>>
>>>>>     static class TextMultiresolutionImage extends 
>>>>> AbstractMultiResolutionImage {
>>>>>
>>>>>         private final Image baseImage;
>>>>>
>>>>>         public TextMultiresolutionImage(Image baseImage) {
>>>>>             this.baseImage = baseImage;
>>>>>         }
>>>>>
>>>>>         @Override
>>>>>         public Image getResolutionVariant(float destImageWidth, 
>>>>> float destImageHeight) {
>>>>>             Image rvImage = ((MultiResolutionImage) baseImage).
>>>>>                     getResolutionVariant(destImageWidth, 
>>>>> destImageHeight);
>>>>>             return drawText(rvImage);
>>>>>         }
>>>>>
>>>>>         // this method is not used by SunGraphics2D to draw the image
>>>>>         @Override
>>>>>         public List<Image> getResolutionVariants() {
>>>>>             List<Image> resolutionvariants = new LinkedList<>();
>>>>>             for (Image image : ((MultiResolutionImage) baseImage).
>>>>>                     getResolutionVariants()) {
>>>>>                 resolutionvariants.add(drawText(image));
>>>>>             }
>>>>>             return resolutionvariants;
>>>>>         }
>>>>>
>>>>>         @Override
>>>>>         protected Image getBaseImage() {
>>>>>             return drawText(baseImage);
>>>>>         }
>>>>>     }
>>>>>    -------------------------------
>>>>>
>>>>>   Sample 2. Using filters to create a lightened  custom cursor.
>>>>>    -------------------------------
>>>>>     public static void main(String[] args) {
>>>>>
>>>>>         Image image = 
>>>>> Toolkit.getDefaultToolkit().getImage("cursor.png"); // cursor.png 
>>>>> and cursor at 2x.png files are provided
>>>>>         Image lightenedImage = image instanceof MultiResolutionImage
>>>>>                 ? new LigtenedMultiresolutionImage(image) : 
>>>>> applyFilter(image);
>>>>>
>>>>>         Cursor lightenedCursor = Toolkit.getDefaultToolkit().
>>>>>                 createCustomCursor(lightenedImage, new Point(0, 
>>>>> 0), "Lightened Cursor");
>>>>>         JFrame frame = new JFrame("Frame with lightened cursor");
>>>>>         frame.setCursor(lightenedCursor);
>>>>>     }
>>>>>
>>>>>     static Image applyFilter(Image image) {
>>>>>         // apply a filter to create ligtened image
>>>>>     }
>>>>>
>>>>>     static class LigtenedMultiresolutionImage extends 
>>>>> AbstractMultiResolutionImage {
>>>>>
>>>>>         private final Image baseImage;
>>>>>
>>>>>         public LigtenedMultiresolutionImage(Image baseImage) {
>>>>>             this.baseImage = baseImage;
>>>>>         }
>>>>>
>>>>>         @Override
>>>>>         public Image getResolutionVariant(float destImageWidth, 
>>>>> float destImageHeight) {
>>>>>             Image rvImage = ((MultiResolutionImage) baseImage).
>>>>>                     getResolutionVariant(destImageWidth, 
>>>>> destImageHeight);
>>>>>             return applyFilter(rvImage);
>>>>>         }
>>>>>
>>>>>         // all resolution variants are created to pass them to 
>>>>> NSImage
>>>>>         @Override
>>>>>         public List<Image> getResolutionVariants() {
>>>>>             List<Image> resolutionvariants = new LinkedList<>();
>>>>>             for (Image image : ((MultiResolutionImage) baseImage).
>>>>>                     getResolutionVariants()) {
>>>>> resolutionvariants.add(applyFilter(image));
>>>>>             }
>>>>>             return resolutionvariants;
>>>>>         }
>>>>>
>>>>>         @Override
>>>>>         protected Image getBaseImage() {
>>>>>             return applyFilter(baseImage);
>>>>>         }
>>>>>     }
>>>>>    -------------------------------
>>>>>>
>>>>>> Based solely on the usage I see here, its not clear why 
>>>>>> MultiResolutionImage needs
>>>>>> to separately exist. what would implement MultiResolutionImage 
>>>>>> except for
>>>>>> a class that extends AbstractMultiResolutionImage  ? Where would 
>>>>>> you use
>>>>>> a straight implementation of MultiResolutionImage ?
>>>>>     See sun.awt.image.MultiResolutionToolkitImage in JDK 9. Both 
>>>>> ToolkitImage and MultiResolutionImage should be used in this case.
>>>>>
>>>>>>
>>>>>> Actually I am not sure you answered Jim's question as to who is 
>>>>>> requesting these APIs.
>>>>>> "The AWT team" doesn't need them as they won't be writing the apps.
>>>>>
>>>>>   There was a long thread about the image with sub-pixel 
>>>>> resolution drawing  on Mac OS X:
>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>>>>>
>>>>>
>>>>>  It was pointed out that Icon images that can be programmatically 
>>>>> generated also need to have HiDPI support:
>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>>>>>
>>>>>
>>>>>  All requests about Mac OS X HiDPI support were included to the 
>>>>> umbrella issue:
>>>>>    7124410 [macosx] Lion HiDPI support
>>>>> https://bugs.openjdk.java.net/browse/JDK-7124410
>>>>>
>>>>>>
>>>>>> If the 99% use case will be to provide a way for apps to provide 
>>>>>> images at custom sizes
>>>>>> then we seem to be making them write new code. SFAIK FX found a 
>>>>>> way to do something
>>>>>> similar to what OS X and Windows do which is to load based on file
>>>>>> name convention. 
>>>>>       JDK 8 have already loaded images with @2x name convention on 
>>>>> Mac OS X.
>>>>>       See the fix for the issue JDK-8011059 [macosx] Support 
>>>>> automatic @2x images loading on Mac OS X
>>>>>        https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>> If we can do that, we load just the one we need. Is the point
>>>>>> of use so far removed from the loading logic that we can't do this ?
>>>>>
>>>>>     Mac OS X has both ways to create images: using @2x name 
>>>>> convention for files
>>>>>     and NSImage with methods 
>>>>> addRepresentation/removeRepresentation/representations.
>>>>>
>>>>>     The current API is proposed to dial with images that can have 
>>>>> source that is different  from files.
>>>>>     It is also used to process already loaded images.
>>>>>     See the provided two samples with lightened custom cursor and 
>>>>> text on image.
>>>>>     Is it possible to write the same samples on JavaFX?
>>>>>
>>>>>> And none of this seems to help anyone who calls new 
>>>>>> BufferedImage(w, h, type) ..
>>>>>
>>>>>    Yes. It needs to create a BufferedImage for each screen 
>>>>> resolution and put them to a multi-resolution image.
>>>>>
>>>>>>
>>>>>> BTW I am not sold on the need for the RenderingHint. Where did 
>>>>>> the idea come from ?
>>>>>> It would affect all rendering using that graphics instance, not 
>>>>>> just a specific image and
>>>>>> if someone doesn't want a MultiRes image used, then maybe they 
>>>>>> just don't provide one ..
>>>>>
>>>>>     KEY_RESOLUTION_VARIANT is used to switch on/off resolution 
>>>>> variants usage.
>>>>>     VALUE_RESOLUTION_VARIANT_ON - SunGraphics2D queries resolution 
>>>>> variants from multi-resolution image on HiDPI displays.
>>>>>     VALUE_RESOLUTION_VARIANT_OFF - SunGraphics2D does not use 
>>>>> resolution variants. Only base image is used.
>>>>>
>>>>>> In any case, without a solid demonstrated need I would not add 
>>>>>> the API.
>>>>>>
>>>>>     See provided 2 samples.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 6/4/2014 7:29 AM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Hi Phil,
>>>>>>>
>>>>>>>   Could you review the fix where only new MultiResolutionImage 
>>>>>>> interface and AbstractMultiResolutionImage class are added:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> On 5/19/2014 2:46 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   Hi Phil,
>>>>>>>>
>>>>>>>> On 5/16/2014 9:12 PM, Phil Race wrote:
>>>>>>>>> I think Jim was looking at this. I am not sure if you yet 
>>>>>>>>> answered all his questions/concerns.
>>>>>>>>>
>>>>>>>>> There's a lot of API here and it will take more time than I 
>>>>>>>>> have right now just to get
>>>>>>>>> my head around it so do not expect a quick answer.
>>>>>>>>>
>>>>>>>>> 1. Why is there no javadoc on the new API on Toolkit ?
>>>>>>>>   It was decided to split the original issue on two parts:
>>>>>>>>        - this fix adds only MultiResolutionImage interface and 
>>>>>>>> AbstractMultiResolutionImage class.
>>>>>>>>            Here is the webrev for it: 
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
>>>>>>>>       - the Toolkit related API is moved to the separate issue
>>>>>>>>
>>>>>>>>   Could you review the current fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
>>>>>>>>
>>>>>>>>> 2. What kinds of classes are expected to implement 
>>>>>>>>> MultiResolutionImage
>>>>>>>>> Application ones or platform ones ?
>>>>>>>>     Both.
>>>>>>>>     - Application: A developer can provide a set of images with 
>>>>>>>> different resolutions to create a multi-resolution image. An 
>>>>>>>> image with best-fitting resolution
>>>>>>>>         will be drawn on HiDPI display.
>>>>>>>>     - Platform: we used it to support Aqua L&F on HiDPI displays.
>>>>>>>>
>>>>>>>>> 3. can you better explain all these parameters :
>>>>>>>>>
>>>>>>>>>   49      * @param logicalDPIX the logical horizontal DPI of 
>>>>>>>>> the desktop.
>>>>>>>>>   50      * @param logicalDPIY the logical vertical DPI of the 
>>>>>>>>> desktop.
>>>>>>>>>   51      * @param baseImageWidth the width of the base image.
>>>>>>>>>   52      * @param baseImageHeight the height of the base image.
>>>>>>>>>   53      * @param destImageWidth the width of the destination 
>>>>>>>>> image.
>>>>>>>>>   54      * @param destImageHeight the height of the 
>>>>>>>>> destination image.
>>>>>>>>>   55      * @return image resolution variant.
>>>>>>>>
>>>>>>>>     Could we postpone it to the CCC request?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4.    public List<Image> getResolutionVariants();
>>>>>>>>>
>>>>>>>>> So this implies a fixed, known ahead of time set of images ?
>>>>>>>>> Why is it required to have this API ? How will anyone be able to
>>>>>>>>> tell which is which and use the list ?
>>>>>>>>
>>>>>>>>    Here are some usages from the JDK code:
>>>>>>>>     - AquaImagefactory.getAppIconCompositedOn(final Image 
>>>>>>>> background)
>>>>>>>>        The original multi-resolution image is used to create 
>>>>>>>> another multi-resolution image with the background
>>>>>>>>     - AquaUtils.generateLightenedImage(Image image, ImageFilter 
>>>>>>>> filter)
>>>>>>>>       The original multi-resolution image is used to create 
>>>>>>>> lightening multi-resolution image
>>>>>>>>     - CImage.createFromImage(final Image image)
>>>>>>>>         Resolution variants from a multi-resolution image are 
>>>>>>>> used to create an NSImage
>>>>>>>>     - CCustomCursor:  it is possible set a custom cursor which 
>>>>>>>> contains resolution variants to the native system
>>>>>>>>
>>>>>>>>     Usually the getResolutionVariants() method is used to 
>>>>>>>> create one multi-resolution image based on the another 
>>>>>>>> multi-resolution image.
>>>>>>>>
>>>>>>>>> 5. Why is the rendering hint needed ?
>>>>>>>>       Someone can manually switch off the multi-resolution 
>>>>>>>> image drawing from graphics so only the base image will be drawn.
>>>>>>>>       It is useful for the performance reason. There is a 
>>>>>>>> choice to draw the high-resolution image slowly or the 
>>>>>>>> low-resolution image faster.
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/16/2014 9:16 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>   Hi Phil,
>>>>>>>>>>
>>>>>>>>>>   I need a reviewer from the 2d group for the fix. Could you 
>>>>>>>>>> take a look at the fix and review it?
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/12/2014 6:35 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>   There was a long thread about the image with sub-pixel 
>>>>>>>>>>> resolution drawing  on Mac OS X:
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  It was pointed out that Icon images that can be 
>>>>>>>>>>> programmatically generated also need to have HiDPI support:
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>>>>>>>>>>>
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  All requests about Mac OS X HiDPI support were included to 
>>>>>>>>>>> the umbrella issue:
>>>>>>>>>>>    7124410 [macosx] Lion HiDPI support
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7124410
>>>>>>>>>>>
>>>>>>>>>>>  Thanks,
>>>>>>>>>>>  Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> On 4/25/2014 6:45 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 4/25/2014 2:17 AM, Jim Graham wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I asked for who was requesting these facilities and you 
>>>>>>>>>>>>> responded with the solution you are planning to provide.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't care what the solution looks like if we have 
>>>>>>>>>>>>> nobody asking for the feature - I am asking who is asking 
>>>>>>>>>>>>> for these capabilities?
>>>>>>>>>>>>
>>>>>>>>>>>>    This is the request from the AWT team for the HiDPI 
>>>>>>>>>>>> support.
>>>>>>>>>>>>
>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>> On 4/3/2014 2:23 AM, Jim Graham wrote:
>>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The back and forth is getting confusing here, so I 
>>>>>>>>>>>>>>> thought I'd try to
>>>>>>>>>>>>>>> summarize and start fresh(ish):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. We need to support @2x internally for MacOS 
>>>>>>>>>>>>>>> compatibility (done).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. We will need to support _DPI images for Win-DPI 
>>>>>>>>>>>>>>> compatibility (TBD).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3. Customers may have their own collection of images to 
>>>>>>>>>>>>>>> bundle
>>>>>>>>>>>>>>> together into an MR image (working on that here). What 
>>>>>>>>>>>>>>> is the push
>>>>>>>>>>>>>>> for this?  Is this simply parity with Mac interfaces?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          ----------
>>>>>>>>>>>>>>          Image[] resolutionVariants = // get sorted by 
>>>>>>>>>>>>>> sizes array of
>>>>>>>>>>>>>> resolution variants;
>>>>>>>>>>>>>>          Image mrImage =
>>>>>>>>>>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex,
>>>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>>>          ----------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       Here is the proposed patch:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4. Customers may want to synthetically generate images 
>>>>>>>>>>>>>>> at arbitrary
>>>>>>>>>>>>>>> resolutions (a variation that is impacting this 
>>>>>>>>>>>>>>> solution). What is
>>>>>>>>>>>>>>> the push for this?
>>>>>>>>>>>>>>          ----------
>>>>>>>>>>>>>>          Image mrImage =
>>>>>>>>>>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, 
>>>>>>>>>>>>>> baseImageHeight,
>>>>>>>>>>>>>>                  new float[][]{{100, 100}, {150, 150}, 
>>>>>>>>>>>>>> {200, 200}}, //
>>>>>>>>>>>>>> resolution variants sizes
>>>>>>>>>>>>>>                  (rvWidth, rvHeight) -> { /* generate a 
>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>> variant */  });
>>>>>>>>>>>>>>         ----------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5. I'm guessing that customers might want to override 
>>>>>>>>>>>>>>> the logic to
>>>>>>>>>>>>>>> choose from among multiple resolutions. That came from 
>>>>>>>>>>>>>>> me based on
>>>>>>>>>>>>>>> seeing Mac and Win using different selection logic and 
>>>>>>>>>>>>>>> our history of
>>>>>>>>>>>>>>> developers split between those wanting cross-platform 
>>>>>>>>>>>>>>> consistency and
>>>>>>>>>>>>>>> those wanting consistency with native apps on each 
>>>>>>>>>>>>>>> platform. Also,
>>>>>>>>>>>>>>> the needs of an animator may differ from the needs of a
>>>>>>>>>>>>>>> resolution-settable-document editor as to how 
>>>>>>>>>>>>>>> dynamically the images
>>>>>>>>>>>>>>> shift between resolution variants.
>>>>>>>>>>>>>>         ----------
>>>>>>>>>>>>>>          Image[] resolutionVariants = // get sorted by 
>>>>>>>>>>>>>> sizes array of
>>>>>>>>>>>>>> resolution variants;
>>>>>>>>>>>>>>          Image mrImage = 
>>>>>>>>>>>>>> ImageResolutionHelper.createMRImage(
>>>>>>>>>>>>>>                  (rvWidth, rvHeight, resolutionVariants) 
>>>>>>>>>>>>>> -> { /*use a
>>>>>>>>>>>>>> custom logic to choose a resolution variant from an array 
>>>>>>>>>>>>>> of images*/},
>>>>>>>>>>>>>>                  (logicalDPI, baseImageSize, 
>>>>>>>>>>>>>> destImageSize) ->
>>>>>>>>>>>>>> destImageSize, // calculate the custom aware resolution 
>>>>>>>>>>>>>> variant size
>>>>>>>>>>>>>>                  baseImageIndex, resolutionVariants);
>>>>>>>>>>>>>>         ----------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     or just extend the CustomMultiResolutionImage which 
>>>>>>>>>>>>>> has Image as the
>>>>>>>>>>>>>> parent class:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------
>>>>>>>>>>>>>>   public class CustomMultiResolutionImage extends
>>>>>>>>>>>>>> AbstractMultiResolutionImage {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>>> float
>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>              float baseImageWidth, float baseImageHeight,
>>>>>>>>>>>>>>              float destImageWidth, float destImageHeight) {
>>>>>>>>>>>>>>          // return a resolution variant based on the 
>>>>>>>>>>>>>> given logical DPI,
>>>>>>>>>>>>>>          // base image size, or destination image size
>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>          // return a list of resolution variants
>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>      protected Image getBaseImage() {
>>>>>>>>>>>>>>          // return the base image
>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> --------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is that a fair summary of all of the considerations so 
>>>>>>>>>>>>>>> far, or did I
>>>>>>>>>>>>>>> miss something?
>>>>>>>>>>>>>>     I think it should cover the main needs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Below are some thoughts about TK.createMRImage(...) 
>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Could you review the updated fix:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   - baseImageWidth/Height arguments are added to the
>>>>>>>>>>>>>>>>> getResolutionVariant(...) method
>>>>>>>>>>>>>>>>>   - dest image sizes are reverted to included DPI scale
>>>>>>>>>>>>>>>>>   - AbstractMultiResolutionImage is added. It needs 
>>>>>>>>>>>>>>>>> only to implement
>>>>>>>>>>>>>>>>> only 3 methods from the AbstractMultiResolutionImage 
>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>     to create a custom multi-resolution image. For 
>>>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 3/22/2014 3:57 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your code example below can be expressed as an 
>>>>>>>>>>>>>>>>>> implementation of the
>>>>>>>>>>>>>>>>>> single-method, lambda-compatible interface that 
>>>>>>>>>>>>>>>>>> expresses just the
>>>>>>>>>>>>>>>>>> getRV() method. They could easily do:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> final Image baseImage = ...;
>>>>>>>>>>>>>>>>>> TK.createMRImage(new RVInterface() {
>>>>>>>>>>>>>>>>>>     public Image getRV(...) {
>>>>>>>>>>>>>>>>>>         // calculate rvWidth and rvHeight
>>>>>>>>>>>>>>>>>>         // look up rvWidth/rvHeight in a database of 
>>>>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>>>>         // possibly contruct a new image
>>>>>>>>>>>>>>>>>>         return rvImage;
>>>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>>>> }, baseImage);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       The RVInterface mixes the logic that construct an 
>>>>>>>>>>>>>>>> image and
>>>>>>>>>>>>>>>> chooses the necessary resolution variant.
>>>>>>>>>>>>>>>>       It is ok if a developer always implements this 
>>>>>>>>>>>>>>>> interface. If it
>>>>>>>>>>>>>>>> needs to have DPI/Transform/Platform aware RVInterface 
>>>>>>>>>>>>>>>> the image
>>>>>>>>>>>>>>>> construction logic should be separated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      Does  TK.createMRImage() method implies that 
>>>>>>>>>>>>>>>> Platform aware logic
>>>>>>>>>>>>>>>> should be used for a resolution-variant choosing?
>>>>>>>>>>>>>>>>      If so, may be general createMRImage() can be 
>>>>>>>>>>>>>>>> placed in the
>>>>>>>>>>>>>>>> ImageResolutionHelper.
>>>>>>>>>>>>>>>>>> The main issue I see is if you might want the newly 
>>>>>>>>>>>>>>>>>> constructed
>>>>>>>>>>>>>>>>>> variants to appear in the List returned from the 
>>>>>>>>>>>>>>>>>> getVariants()
>>>>>>>>>>>>>>>>>> method.  I'm not sure what value that would have 
>>>>>>>>>>>>>>>>>> beyond simply
>>>>>>>>>>>>>>>>>> returning the base media that the object uses from 
>>>>>>>>>>>>>>>>>> which to construct
>>>>>>>>>>>>>>>>>> its variants...?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    It can be solved by using something like array of 
>>>>>>>>>>>>>>>> image sizes or
>>>>>>>>>>>>>>>> other seeds and a mapper that can create an image from 
>>>>>>>>>>>>>>>> the given seed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   It can look like:
>>>>>>>>>>>>>>>> -------------------------
>>>>>>>>>>>>>>>> public class ImageResolutionHelper {
>>>>>>>>>>>>>>>>      public interface RVChooser {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>          public Image getRV(
>>>>>>>>>>>>>>>>                  float logicalDPIX, float logicalDPIY,
>>>>>>>>>>>>>>>>                  float baseImageWidth, float 
>>>>>>>>>>>>>>>> baseImageHeight,
>>>>>>>>>>>>>>>>                  float destImageWidth, float 
>>>>>>>>>>>>>>>> destImageHeight,
>>>>>>>>>>>>>>>>                  final Image... resolutionVariants);
>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      public static final RVChooser DPI_AWARE = ...;
>>>>>>>>>>>>>>>>      public static final RVChooser TRANSFORM_AWARE = ...;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      // resolutionVariants is an array of sorted by 
>>>>>>>>>>>>>>>> width/height images
>>>>>>>>>>>>>>>>      static Image createMRImage(final RVChooser rvChooser,
>>>>>>>>>>>>>>>>              final int baseImageIndex, final Image...
>>>>>>>>>>>>>>>> resolutionVariants) { ... }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      // sorted by width/height images should be 
>>>>>>>>>>>>>>>> generated from seeds
>>>>>>>>>>>>>>>>      static <Type> Image createMRImage(final RVChooser 
>>>>>>>>>>>>>>>> rvChooser,
>>>>>>>>>>>>>>>>              final Type baseImageSeed, final 
>>>>>>>>>>>>>>>> Function<Type, Image>
>>>>>>>>>>>>>>>> mapper, final Type... rvSeeds) {...}
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public abstract class Toolkit {
>>>>>>>>>>>>>>>>      public abstract Image createMRImage(int 
>>>>>>>>>>>>>>>> baseImageIndex, Image...
>>>>>>>>>>>>>>>> resolutionVariants); // Platform aware rv chooser is used
>>>>>>>>>>>>>>>>      public abstract RVChooser getPlatformRVChooser() ;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      I think it is better to provide both the 
>>>>>>>>>>>>>>>>>>> MultiResolutionImage
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> its implementation based on the given resolution 
>>>>>>>>>>>>>>>>>>> variants array.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It occurs to me that even if we don't go with a 
>>>>>>>>>>>>>>>>>> lambda-factory-based
>>>>>>>>>>>>>>>>>> approach like what I'm describing, it might make 
>>>>>>>>>>>>>>>>>> sense to provide a
>>>>>>>>>>>>>>>>>> baseMR implementation that they can subclass to keep 
>>>>>>>>>>>>>>>>>> them from trying
>>>>>>>>>>>>>>>>>> to subclass off of BufferedImage instead. I really 
>>>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>>>> avoid "custom MR images are subclasses of BufImg" if 
>>>>>>>>>>>>>>>>>> we can as I
>>>>>>>>>>>>>>>>>> think the mix of concepts is a little jarring...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     The implementation could look like:
>>>>>>>>>>>>>>>>>>> ---------------------------------
>>>>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends 
>>>>>>>>>>>>>>>>>>> Image implements
>>>>>>>>>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      int baseImageIndex;
>>>>>>>>>>>>>>>>>>>      Image[] resolutionVariants;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      public CustomMultiResolutionImage(int 
>>>>>>>>>>>>>>>>>>> baseImageIndex,
>>>>>>>>>>>>>>>>>>>              Image... resolutionVariants) {
>>>>>>>>>>>>>>>>>>>          this.baseImageIndex = baseImageIndex;
>>>>>>>>>>>>>>>>>>> this.resolutionVariants = resolutionVariants;
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public int getWidth(ImageObserver observer) {
>>>>>>>>>>>>>>>>>>>          return getBaseImage().getWidth(null);
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public int getHeight(ImageObserver observer) {
>>>>>>>>>>>>>>>>>>>          return getBaseImage().getHeight(null);
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public ImageProducer getSource() {
>>>>>>>>>>>>>>>>>>>          return getBaseImage().getSource();
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public Graphics getGraphics() {
>>>>>>>>>>>>>>>>>>>          return getBaseImage().getGraphics();
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public Object getProperty(String name, 
>>>>>>>>>>>>>>>>>>> ImageObserver observer) {
>>>>>>>>>>>>>>>>>>>          return getBaseImage().getProperty(name, 
>>>>>>>>>>>>>>>>>>> observer);
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>>> logicalDPIX, float
>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>              float destinationImageWidth, float
>>>>>>>>>>>>>>>>>>> destinationImageHeight) {
>>>>>>>>>>>>>>>>>>>              // calculate resolution variant 
>>>>>>>>>>>>>>>>>>> width/height
>>>>>>>>>>>>>>>>>>>          return getResolutionVariant(rvWidth, 
>>>>>>>>>>>>>>>>>>> rvHeight);
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      private Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>>> rvWidth, float
>>>>>>>>>>>>>>>>>>> rvHeight) {
>>>>>>>>>>>>>>>>>>>          // return a resolution variant based on the 
>>>>>>>>>>>>>>>>>>> given width and
>>>>>>>>>>>>>>>>>>> height
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      private Image getBaseImage() {
>>>>>>>>>>>>>>>>>>>          return resolutionVariants[baseImageIndex];
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>> ---------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Then we provide one of these from 
>>>>>>>>>>>>>>>>>>>> TK.get/createImage() when the
>>>>>>>>>>>>>>>>>>>> platform detects @2x, or Win8-style variants.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For custom images we provide 
>>>>>>>>>>>>>>>>>>>> TK.createMRImage(lambda getRV, Image
>>>>>>>>>>>>>>>>>>>> variants...) and TK.createMRImage(Image variants...);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since the get<List> method is just bookkeeping, I 
>>>>>>>>>>>>>>>>>>>> don't see them
>>>>>>>>>>>>>>>>>>>> needing to override it, so the getRV() method is 
>>>>>>>>>>>>>>>>>>>> really the only
>>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>>> they might want to override, and we can tie into 
>>>>>>>>>>>>>>>>>>>> the new Lambda
>>>>>>>>>>>>>>>>>>>> capabilities by making a single-method interface 
>>>>>>>>>>>>>>>>>>>> for it that they
>>>>>>>>>>>>>>>>>>>> supply in a factory method.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I realize that the interface you created is more 
>>>>>>>>>>>>>>>>>>>> fundamentally
>>>>>>>>>>>>>>>>>>>> OO, but
>>>>>>>>>>>>>>>>>>>> the Image class has always been special in this 
>>>>>>>>>>>>>>>>>>>> regard in the AWT
>>>>>>>>>>>>>>>>>>>> ecosystem (in so far as we do not support someone 
>>>>>>>>>>>>>>>>>>>> implementing their
>>>>>>>>>>>>>>>>>>>> own Image subclass even though it is technically 
>>>>>>>>>>>>>>>>>>>> possible).
>>>>>>>>>>>>>>>>>>>> Because of
>>>>>>>>>>>>>>>>>>>> this special nature of Image, we end up with the 
>>>>>>>>>>>>>>>>>>>> situation that if
>>>>>>>>>>>>>>>>>>>> someone were given a need to create a subclass of 
>>>>>>>>>>>>>>>>>>>> Image, then they
>>>>>>>>>>>>>>>>>>>> would turn to BufImg as their superclass even 
>>>>>>>>>>>>>>>>>>>> though BufImg is
>>>>>>>>>>>>>>>>>>>> essentially an implementation-specific leaf node on 
>>>>>>>>>>>>>>>>>>>> the Image class
>>>>>>>>>>>>>>>>>>>> hierarchy.  This approach with a factory method to 
>>>>>>>>>>>>>>>>>>>> create an
>>>>>>>>>>>>>>>>>>>> internal
>>>>>>>>>>>>>>>>>>>> subclass of the new MRI class mirrors the existing 
>>>>>>>>>>>>>>>>>>>> cases of Image
>>>>>>>>>>>>>>>>>>>> objects that come from factories as well.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    Hello,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    Could you review the updated version of the fix:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/ 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   - The "getResolutionVariant(int width, int 
>>>>>>>>>>>>>>>>>>>>> height)" method from
>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage class is changed to
>>>>>>>>>>>>>>>>>>>>>     Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>>>>>>>>>> float
>>>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>>> float width, float height, AffineTransform 
>>>>>>>>>>>>>>>>>>>>> transform);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   - sun.awt.image.ImageResolutionHelper class is 
>>>>>>>>>>>>>>>>>>>>> added. The
>>>>>>>>>>>>>>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and
>>>>>>>>>>>>>>>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes 
>>>>>>>>>>>>>>>>>>>>> are used
>>>>>>>>>>>>>>>>>>>>> PLATFORM ImageResolutionHelper.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   The MultiResolutionImage interface 
>>>>>>>>>>>>>>>>>>>>> implementation could look
>>>>>>>>>>>>>>>>>>>>> like:
>>>>>>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>>>>>>> public class CustomMultiResolutionImage extends 
>>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>>> implements
>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      private final Image[] resolutionVariants;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      public CustomMultiResolutionImage(int 
>>>>>>>>>>>>>>>>>>>>> baseIndex, Image...
>>>>>>>>>>>>>>>>>>>>> images) {
>>>>>>>>>>>>>>>>>>>>> super(images[baseIndex].getWidth(null),
>>>>>>>>>>>>>>>>>>>>> images[baseIndex].getHeight(null),
>>>>>>>>>>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>>>>>>>>>>> this.resolutionVariants = images;
>>>>>>>>>>>>>>>>>>>>>          Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>>> g.drawImage(images[baseIndex], 0, 0, null);
>>>>>>>>>>>>>>>>>>>>>          g.dispose();
>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>>>      public Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>>>>> logicalDPIX, float
>>>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>>>              float width, float height, 
>>>>>>>>>>>>>>>>>>>>> AffineTransform
>>>>>>>>>>>>>>>>>>>>> transform) {
>>>>>>>>>>>>>>>>>>>>>          return getResolutionVariant(logicalDPIX * 
>>>>>>>>>>>>>>>>>>>>> width,
>>>>>>>>>>>>>>>>>>>>> logicalDPIY *
>>>>>>>>>>>>>>>>>>>>> height);
>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      public Image getResolutionVariant(double 
>>>>>>>>>>>>>>>>>>>>> width, double
>>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>>          for (Image image : resolutionVariants) {
>>>>>>>>>>>>>>>>>>>>>              if (width <= image.getWidth(null) && 
>>>>>>>>>>>>>>>>>>>>> height <=
>>>>>>>>>>>>>>>>>>>>> image.getHeight(null)) {
>>>>>>>>>>>>>>>>>>>>>                  return image;
>>>>>>>>>>>>>>>>>>>>>              }
>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>          return this;
>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>   Let's divide the discussion into two part.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>   1. Where it is better to hold resolution 
>>>>>>>>>>>>>>>>>>>>>>>> variants?
>>>>>>>>>>>>>>>>>>>>>>>>      Putting resolution variants in Image class 
>>>>>>>>>>>>>>>>>>>>>>>> brings some
>>>>>>>>>>>>>>>>>>>>>>>> questions like:
>>>>>>>>>>>>>>>>>>>>>>>>    - Some type of images do not need to have 
>>>>>>>>>>>>>>>>>>>>>>>> resolution variants
>>>>>>>>>>>>>>>>>>>>>>>>    - Should resolution variants have the same 
>>>>>>>>>>>>>>>>>>>>>>>> type as the base
>>>>>>>>>>>>>>>>>>>>>>>> image?
>>>>>>>>>>>>>>>>>>>>>>>>    - getResolutionVariants() method can return 
>>>>>>>>>>>>>>>>>>>>>>>> copy of the
>>>>>>>>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>>>>>>>> so add/removeRV methods should be also added.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>    There are pros and cons for placing 
>>>>>>>>>>>>>>>>>>>>>>>> resolution variants to
>>>>>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>>>>>> class or to a separate intreface.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I agree that this could be a separate interface. 
>>>>>>>>>>>>>>>>>>>>>>> In my examples
>>>>>>>>>>>>>>>>>>>>>>> below I was just sticking them inside an 
>>>>>>>>>>>>>>>>>>>>>>> "Image{}" to show where
>>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>> lived in the set of involved objects, not a 
>>>>>>>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>>>> recommendation
>>>>>>>>>>>>>>>>>>>>>>> that they actually be new methods on the base 
>>>>>>>>>>>>>>>>>>>>>>> class itself. I
>>>>>>>>>>>>>>>>>>>>>>> probably should have put a comment there about 
>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> With respect to add/remove - that is assuming a 
>>>>>>>>>>>>>>>>>>>>>>> need for manual
>>>>>>>>>>>>>>>>>>>>>>> construction of an image set, right? Forgive me 
>>>>>>>>>>>>>>>>>>>>>>> if I'm
>>>>>>>>>>>>>>>>>>>>>>> forgetting
>>>>>>>>>>>>>>>>>>>>>>> something, but I seem to recall that manual 
>>>>>>>>>>>>>>>>>>>>>>> Multi-Res images was
>>>>>>>>>>>>>>>>>>>>>>> proposed as a way for developers to introduce 
>>>>>>>>>>>>>>>>>>>>>>> @2x support
>>>>>>>>>>>>>>>>>>>>>>> themselves,
>>>>>>>>>>>>>>>>>>>>>>> but if we are internally managing @2x and -DPI 
>>>>>>>>>>>>>>>>>>>>>>> variants for them,
>>>>>>>>>>>>>>>>>>>>>>> then I'm not sure if there is actual developer 
>>>>>>>>>>>>>>>>>>>>>>> need to manually
>>>>>>>>>>>>>>>>>>>>>>> construct their own. Am I forgetting something?
>>>>>>>>>>>>>>>>>>>>>>    The NSImage has 
>>>>>>>>>>>>>>>>>>>>>> addRepresentation/removeRepresentation
>>>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>>>> work with image representations on Mac OS X.
>>>>>>>>>>>>>>>>>>>>>>    The java.awt.Image class should provide similar
>>>>>>>>>>>>>>>>>>>>>> functionality to
>>>>>>>>>>>>>>>>>>>>>> have the possibilities as Cocoa on HiDPI displays.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2. Using scale factor/image sizes/scaled image 
>>>>>>>>>>>>>>>>>>>>>>>> sizes to
>>>>>>>>>>>>>>>>>>>>>>>> retreive a
>>>>>>>>>>>>>>>>>>>>>>>> resolution variant.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>    May be it is better to have a structure that 
>>>>>>>>>>>>>>>>>>>>>>>> provide all
>>>>>>>>>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>>>>>>>>> information  to query the resolution variant: 
>>>>>>>>>>>>>>>>>>>>>>>> scale factor,
>>>>>>>>>>>>>>>>>>>>>>>> draw area
>>>>>>>>>>>>>>>>>>>>>>>> width/height, transformed area width/height?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>>      public interface MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>          interface DrawAreaInfo {
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>              float getScaleFactor();
>>>>>>>>>>>>>>>>>>>>>>>>              float getAreaWidth();
>>>>>>>>>>>>>>>>>>>>>>>>              float getAreaHeight();
>>>>>>>>>>>>>>>>>>>>>>>>              float getTransformedAreaWidth();
>>>>>>>>>>>>>>>>>>>>>>>>              float getTransformedAreaHeight();
>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>          public Image 
>>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariant(DrawAreaInfo
>>>>>>>>>>>>>>>>>>>>>>>> drawAreaInfo) ;
>>>>>>>>>>>>>>>>>>>>>>>>          public List<Image> 
>>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants();
>>>>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The problem with a constructor is that this is 
>>>>>>>>>>>>>>>>>>>>>>> something that is
>>>>>>>>>>>>>>>>>>>>>>> (potentially) done on every drawImage() call, 
>>>>>>>>>>>>>>>>>>>>>>> which means we are
>>>>>>>>>>>>>>>>>>>>>>> inviting GC into the equation. If we can come up 
>>>>>>>>>>>>>>>>>>>>>>> with a simple
>>>>>>>>>>>>>>>>>>>>>>> "just
>>>>>>>>>>>>>>>>>>>>>>> a couple/3/4 numbers" way to embed that data 
>>>>>>>>>>>>>>>>>>>>>>> into a method call
>>>>>>>>>>>>>>>>>>>>>>> argument list then we can make this lighter weight.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> What about simply having floating point (double) 
>>>>>>>>>>>>>>>>>>>>>>> dimensions on
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> rendered size
>>>>>>>>>>>>>>>>>>>>>>       There should be a way to choose a 
>>>>>>>>>>>>>>>>>>>>>> resolution variant
>>>>>>>>>>>>>>>>>>>>>> based on
>>>>>>>>>>>>>>>>>>>>>> requested drawing size or transformed drawing size.
>>>>>>>>>>>>>>>>>>>>>>       At least a current transformation should be 
>>>>>>>>>>>>>>>>>>>>>> included too.
>>>>>>>>>>>>>>>>>>>>>>> plus a single floating point "logical DPI" for 
>>>>>>>>>>>>>>>>>>>>>>> the screen?
>>>>>>>>>>>>>>>>>>>>>>      There is the ID2D1Factory::GetDesktopDpi 
>>>>>>>>>>>>>>>>>>>>>> method which returns
>>>>>>>>>>>>>>>>>>>>>> dpiX and dpiY.
>>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>     That means that logicalDPIX/Y can have 
>>>>>>>>>>>>>>>>>>>>>> different values.
>>>>>>>>>>>>>>>>>>>>>>      At least it is described in the
>>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>      "To get the DPI setting, call the 
>>>>>>>>>>>>>>>>>>>>>> ID2D1Factory::GetDesktopDpi
>>>>>>>>>>>>>>>>>>>>>> method. The DPI is returned as two floating-point 
>>>>>>>>>>>>>>>>>>>>>> values, one for
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> x-axis and one for the y-axis. In theory, these 
>>>>>>>>>>>>>>>>>>>>>> values can differ.
>>>>>>>>>>>>>>>>>>>>>> Calculate a separate scaling factor for each axis."
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   The getResolutionVariant method could look like:
>>>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>>>>     public Image getResolutionVariant(float 
>>>>>>>>>>>>>>>>>>>>>> logicalDPIX, float
>>>>>>>>>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>>>>>>>>>             float widthX, float widthY, 
>>>>>>>>>>>>>>>>>>>>>> AffineTransform
>>>>>>>>>>>>>>>>>>>>>> transform);
>>>>>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  If the image is known (either passed as an 
>>>>>>>>>>>>>>>>>>>>>>> argument or the
>>>>>>>>>>>>>>>>>>>>>>> method is
>>>>>>>>>>>>>>>>>>>>>>> called on the image), then it can provide the 
>>>>>>>>>>>>>>>>>>>>>>> original WH.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The MultiResolutionImage default implementation 
>>>>>>>>>>>>>>>>>>>>>>>> could allow
>>>>>>>>>>>>>>>>>>>>>>>> to use
>>>>>>>>>>>>>>>>>>>>>>>> different strategies like scale 
>>>>>>>>>>>>>>>>>>>>>>>> factor/transfom/OS based
>>>>>>>>>>>>>>>>>>>>>>>>    to query a resolution variant. The OS based 
>>>>>>>>>>>>>>>>>>>>>>>> strategy can be
>>>>>>>>>>>>>>>>>>>>>>>> used by
>>>>>>>>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> For Mac policy, all we need is the transformed 
>>>>>>>>>>>>>>>>>>>>>>> dimensions, which
>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>> be passed in as FP for generality. For Windows 
>>>>>>>>>>>>>>>>>>>>>>> policy, all we
>>>>>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>>>> is logical DPI for the screen. What other 
>>>>>>>>>>>>>>>>>>>>>>> information would we
>>>>>>>>>>>>>>>>>>>>>>> need, or would an algorithm like to use, that 
>>>>>>>>>>>>>>>>>>>>>>> can't be computed
>>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>> those 2 pieces?
>>>>>>>>>>>>>>>>>>>>>>      The aim is to provide a base class that can 
>>>>>>>>>>>>>>>>>>>>>> be used to
>>>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage like:
>>>>>>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>      A developer should be able to implement a 
>>>>>>>>>>>>>>>>>>>>>> custom algorithm to
>>>>>>>>>>>>>>>>>>>>>> query a resolution variant.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>     It can be done by overriding the 
>>>>>>>>>>>>>>>>>>>>>> getResolutionVariant image:
>>>>>>>>>>>>>>>>>>>>>> -----------------------
>>>>>>>>>>>>>>>>>>>>>>         Image mrImage = new 
>>>>>>>>>>>>>>>>>>>>>> MultiResolutionBufferedImage(){
>>>>>>>>>>>>>>>>>>>>>>             @Override
>>>>>>>>>>>>>>>>>>>>>>             public Image getResolutionVariant(...) {
>>>>>>>>>>>>>>>>>>>>>>                 // Custom logic here
>>>>>>>>>>>>>>>>>>>>>>             }
>>>>>>>>>>>>>>>>>>>>>>         };
>>>>>>>>>>>>>>>>>>>>>> -----------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    Or it can be done by using resolution variant 
>>>>>>>>>>>>>>>>>>>>>> choosers so a
>>>>>>>>>>>>>>>>>>>>>> developer can implement custom resolution variant 
>>>>>>>>>>>>>>>>>>>>>> query:
>>>>>>>>>>>>>>>>>>>>>> -----------------------
>>>>>>>>>>>>>>>>>>>>>> public class MultiResolutionBufferedImage implements
>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage{
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>     interface ResolutionVariantChooser{
>>>>>>>>>>>>>>>>>>>>>>         Image getResolutionVariant(dpi, size,..., 
>>>>>>>>>>>>>>>>>>>>>> List<Image>
>>>>>>>>>>>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>>>>>>>> ResolutionVariantChooser TRANSFORM_BASED = null;
>>>>>>>>>>>>>>>>>>>>>> ResolutionVariantChooser DPI_BASED = null;
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ResolutionVariantChooser rvChooser;
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>     @Override
>>>>>>>>>>>>>>>>>>>>>>     public Image getResolutionVariant(dpi, 
>>>>>>>>>>>>>>>>>>>>>> size,...,) {
>>>>>>>>>>>>>>>>>>>>>>         return 
>>>>>>>>>>>>>>>>>>>>>> rvChooser.getResolutionVariant(dpi, size,...,
>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants());
>>>>>>>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> -----------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> The primary thing that I was concerned about 
>>>>>>>>>>>>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>>>>>>>>>>>>> presence of
>>>>>>>>>>>>>>>>>>>>>>>>>>> integers in the API when Windows uses 
>>>>>>>>>>>>>>>>>>>>>>>>>>> non-integer multiples
>>>>>>>>>>>>>>>>>>>>>>>>>>       It would make sense to pass real 
>>>>>>>>>>>>>>>>>>>>>>>>>> numbers to the
>>>>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariant() method if the 
>>>>>>>>>>>>>>>>>>>>>>>>>> difference between
>>>>>>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>>>>>>> variants sizes is 1.
>>>>>>>>>>>>>>>>>>>>>>>>>>       It seems that it is not a common case.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I was thinking of other API that is related to 
>>>>>>>>>>>>>>>>>>>>>>>>> this, such as
>>>>>>>>>>>>>>>>>>>>>>>>> the API
>>>>>>>>>>>>>>>>>>>>>>>>> that queries the scaling factor from a 
>>>>>>>>>>>>>>>>>>>>>>>>> SurfaceManager. I
>>>>>>>>>>>>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>>>>>>>>>>>>> remember some integer return values in that, 
>>>>>>>>>>>>>>>>>>>>>>>>> but Windows might
>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen 
>>>>>>>>>>>>>>>>>>>>>>>>> scaling factor
>>>>>>>>>>>>>>>>>>>>>>>>> that was
>>>>>>>>>>>>>>>>>>>>>>>>> determined from the UI.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> In terms of the getResolutionVariant() method 
>>>>>>>>>>>>>>>>>>>>>>>>> here, those
>>>>>>>>>>>>>>>>>>>>>>>>> non-integer
>>>>>>>>>>>>>>>>>>>>>>>>> screen scaling factors don't directly impact 
>>>>>>>>>>>>>>>>>>>>>>>>> this API. But, we
>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> some issues with the use of integers there 
>>>>>>>>>>>>>>>>>>>>>>>>> from other sources:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - That API assumes that the caller will 
>>>>>>>>>>>>>>>>>>>>>>>>> determine the pixel
>>>>>>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>>>>>>> needed, but the actual media choice is 
>>>>>>>>>>>>>>>>>>>>>>>>> determined with
>>>>>>>>>>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>>>>>>>>> techniques on Mac and Windows so this means 
>>>>>>>>>>>>>>>>>>>>>>>>> that the caller
>>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> to worry about platform conventions. Is that 
>>>>>>>>>>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>>>>>>>>>>> tradeoff?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - The technique recommended for Mac involves 
>>>>>>>>>>>>>>>>>>>>>>>>> computing the
>>>>>>>>>>>>>>>>>>>>>>>>> precise
>>>>>>>>>>>>>>>>>>>>>>>>> size desired using the current transform, 
>>>>>>>>>>>>>>>>>>>>>>>>> which may be a
>>>>>>>>>>>>>>>>>>>>>>>>> floating
>>>>>>>>>>>>>>>>>>>>>>>>> point value, so the integer values used in 
>>>>>>>>>>>>>>>>>>>>>>>>> this API are already
>>>>>>>>>>>>>>>>>>>>>>>>> approximations and there is no documentation 
>>>>>>>>>>>>>>>>>>>>>>>>> on how to
>>>>>>>>>>>>>>>>>>>>>>>>> generate the
>>>>>>>>>>>>>>>>>>>>>>>>> proper integer. In particular, the current 
>>>>>>>>>>>>>>>>>>>>>>>>> code in SG2D
>>>>>>>>>>>>>>>>>>>>>>>>> naively
>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>> a cast to integer to determine the values to 
>>>>>>>>>>>>>>>>>>>>>>>>> supply which
>>>>>>>>>>>>>>>>>>>>>>>>> means a
>>>>>>>>>>>>>>>>>>>>>>>>> transformed size of W+0.5 will be truncated to 
>>>>>>>>>>>>>>>>>>>>>>>>> W and the lower
>>>>>>>>>>>>>>>>>>>>>>>>> resolution image will be used. Does that 
>>>>>>>>>>>>>>>>>>>>>>>>> conform to Mac
>>>>>>>>>>>>>>>>>>>>>>>>> guidelines? Do
>>>>>>>>>>>>>>>>>>>>>>>>> they require the truncated size to reach W+1 
>>>>>>>>>>>>>>>>>>>>>>>>> before the next
>>>>>>>>>>>>>>>>>>>>>>>>> size is
>>>>>>>>>>>>>>>>>>>>>>>>> used?  Passing in float or double values would 
>>>>>>>>>>>>>>>>>>>>>>>>> sidestep all of
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> since then the comparisons would be done with 
>>>>>>>>>>>>>>>>>>>>>>>>> full precision,
>>>>>>>>>>>>>>>>>>>>>>>>> but as
>>>>>>>>>>>>>>>>>>>>>>>>> long as we can determine a "best practices 
>>>>>>>>>>>>>>>>>>>>>>>>> compatible with all
>>>>>>>>>>>>>>>>>>>>>>>>> platforms" rule on how to round to integers, 
>>>>>>>>>>>>>>>>>>>>>>>>> then integers
>>>>>>>>>>>>>>>>>>>>>>>>> are OK
>>>>>>>>>>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - The Windows document you cite below suggests 
>>>>>>>>>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>>>>>>>>>> determination
>>>>>>>>>>>>>>>>>>>>>>>>> should be made by looking at the Screen DPI 
>>>>>>>>>>>>>>>>>>>>>>>>> and choosing the
>>>>>>>>>>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>>>>>>>>>>> higher media variant based on that screen DPI. 
>>>>>>>>>>>>>>>>>>>>>>>>> They do not
>>>>>>>>>>>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>>>>>>>>>>>> choosing media based on the current transform 
>>>>>>>>>>>>>>>>>>>>>>>>> as is done for
>>>>>>>>>>>>>>>>>>>>>>>>> Mac.  If
>>>>>>>>>>>>>>>>>>>>>>>>> we stick with supplying values that are used 
>>>>>>>>>>>>>>>>>>>>>>>>> to determine which
>>>>>>>>>>>>>>>>>>>>>>>>> media
>>>>>>>>>>>>>>>>>>>>>>>>> to use, then on Windows we should not take the 
>>>>>>>>>>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>>>>>>>>>> but instead query the SurfaceManager for the 
>>>>>>>>>>>>>>>>>>>>>>>>> scale factor and
>>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>>> transform by those values (even if the current 
>>>>>>>>>>>>>>>>>>>>>>>>> transform was
>>>>>>>>>>>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>>>>>>>>>>>> overridden to identity).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> There are pros and cons to both approaches.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Mac ensures that you are always using the best 
>>>>>>>>>>>>>>>>>>>>>>>>> media for any
>>>>>>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>>>>>>> render operation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> But, Windows ensure more consistency in the 
>>>>>>>>>>>>>>>>>>>>>>>>> face of other
>>>>>>>>>>>>>>>>>>>>>>>>> scaling.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The thing to consider is that if you have a 
>>>>>>>>>>>>>>>>>>>>>>>>> 500x500 image
>>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>>> 1000x1000 variant and you rendering it at 
>>>>>>>>>>>>>>>>>>>>>>>>> 500x500 and then
>>>>>>>>>>>>>>>>>>>>>>>>> 501x501,
>>>>>>>>>>>>>>>>>>>>>>>>> that first jump will be fairly jarring as the 
>>>>>>>>>>>>>>>>>>>>>>>>> scaled version
>>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>>> 1000x1000 will not look precisely like the 
>>>>>>>>>>>>>>>>>>>>>>>>> original 500x500
>>>>>>>>>>>>>>>>>>>>>>>>> did.
>>>>>>>>>>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>>>>>>>>>>> @2x images only, this effect is minimized so 
>>>>>>>>>>>>>>>>>>>>>>>>> the advantage of
>>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>> using "the best media for a given render 
>>>>>>>>>>>>>>>>>>>>>>>>> operation" may
>>>>>>>>>>>>>>>>>>>>>>>>> outweigh the
>>>>>>>>>>>>>>>>>>>>>>>>> inconsistency issue. But, on Windows where the 
>>>>>>>>>>>>>>>>>>>>>>>>> media are
>>>>>>>>>>>>>>>>>>>>>>>>> 1.4x or
>>>>>>>>>>>>>>>>>>>>>>>>> 1.8x
>>>>>>>>>>>>>>>>>>>>>>>>> in size, a downscaled image will start to show 
>>>>>>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>>>>> interpolation
>>>>>>>>>>>>>>>>>>>>>>>>> noise and so the balance of the two choices 
>>>>>>>>>>>>>>>>>>>>>>>>> may shift more
>>>>>>>>>>>>>>>>>>>>>>>>> towards not
>>>>>>>>>>>>>>>>>>>>>>>>> wanting a jarring shift.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We might want one or more of the following:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE,
>>>>>>>>>>>>>>>>>>>>>>>>> ALWAYS_LARGEST,
>>>>>>>>>>>>>>>>>>>>>>>>> NONE,
>>>>>>>>>>>>>>>>>>>>>>>>> PLATFORM) where the last policy would use 
>>>>>>>>>>>>>>>>>>>>>>>>> TX_AWARE on Mac and
>>>>>>>>>>>>>>>>>>>>>>>>> DPI_AWARE on Windows
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - We create our own policy and always use it 
>>>>>>>>>>>>>>>>>>>>>>>>> (TX_AWARE? or
>>>>>>>>>>>>>>>>>>>>>>>>> DPI_AWARE?)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - We create our own policy that dynamically 
>>>>>>>>>>>>>>>>>>>>>>>>> chooses one of the
>>>>>>>>>>>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>>>>>>>>>> strategies depending on platform or available 
>>>>>>>>>>>>>>>>>>>>>>>>> media or ???
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - We could create an optional interface for 
>>>>>>>>>>>>>>>>>>>>>>>>> them to install
>>>>>>>>>>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>>>>>>>>>>>> algorithm as well. I think it would work best 
>>>>>>>>>>>>>>>>>>>>>>>>> as a delegate
>>>>>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>> that one installs into Image so that it can be 
>>>>>>>>>>>>>>>>>>>>>>>>> used with any
>>>>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>>>>> without having to subclass (it wouldn't really 
>>>>>>>>>>>>>>>>>>>>>>>>> have much to do
>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> BufferedImages or VolatileImages, though):
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> class Image {
>>>>>>>>>>>>>>>>>>>>>>>>>     void 
>>>>>>>>>>>>>>>>>>>>>>>>> setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>>>>>>>>>> List<Image> getResolutionVariants();
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> class Graphics {
>>>>>>>>>>>>>>>>>>>>>>>>>      void 
>>>>>>>>>>>>>>>>>>>>>>>>> setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> or - anywhere else it could be installed more 
>>>>>>>>>>>>>>>>>>>>>>>>> centrally (per
>>>>>>>>>>>>>>>>>>>>>>>>> App
>>>>>>>>>>>>>>>>>>>>>>>>> context)?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> and the interface would be something like one 
>>>>>>>>>>>>>>>>>>>>>>>>> of these
>>>>>>>>>>>>>>>>>>>>>>>>> variants:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> interface ImageResolutionHelper {
>>>>>>>>>>>>>>>>>>>>>>>>>     // This version would prevent substituting 
>>>>>>>>>>>>>>>>>>>>>>>>> a random image:
>>>>>>>>>>>>>>>>>>>>>>>>>     // They have to return an index into the 
>>>>>>>>>>>>>>>>>>>>>>>>> List<Image> for
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> image...
>>>>>>>>>>>>>>>>>>>>>>>>>     public int chooseVariant(Image img, double 
>>>>>>>>>>>>>>>>>>>>>>>>> dpi, number w,
>>>>>>>>>>>>>>>>>>>>>>>>> number h);
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>     // This version would allow substituting 
>>>>>>>>>>>>>>>>>>>>>>>>> an arbitrary
>>>>>>>>>>>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>>>>>>>>>>>     public Image getVariant(Image img, double 
>>>>>>>>>>>>>>>>>>>>>>>>> dpi, number w,
>>>>>>>>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>>>>>>>> h);
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Since they would be in full control of the 
>>>>>>>>>>>>>>>>>>>>>>>>> policy, though, we
>>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>>> unfortunately always have to call this, there 
>>>>>>>>>>>>>>>>>>>>>>>>> would be no more
>>>>>>>>>>>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, 
>>>>>>>>>>>>>>>>>>>>>>>>> though perhaps we
>>>>>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>>>>> document some internal conditions in which we 
>>>>>>>>>>>>>>>>>>>>>>>>> do not call it
>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> common cases (but that would have to be well 
>>>>>>>>>>>>>>>>>>>>>>>>> agreed not to
>>>>>>>>>>>>>>>>>>>>>>>>> get in
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> way of reasonable uses of the API and well 
>>>>>>>>>>>>>>>>>>>>>>>>> documented)?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note that we would have to do a security audit 
>>>>>>>>>>>>>>>>>>>>>>>>> to make sure
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> random image substitution couldn't allow any 
>>>>>>>>>>>>>>>>>>>>>>>>> sort of "screen
>>>>>>>>>>>>>>>>>>>>>>>>> phishing"
>>>>>>>>>>>>>>>>>>>>>>>>> exploit.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> and also what policy they use for choosing 
>>>>>>>>>>>>>>>>>>>>>>>>>>> scaled images.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't see a mention of taking the current 
>>>>>>>>>>>>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>>>>>>>>>>>> just physical issues like screen DPI and 
>>>>>>>>>>>>>>>>>>>>>>>>>>> form factor. They
>>>>>>>>>>>>>>>>>>>>>>>>>>> talk
>>>>>>>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution plateaus and in their 
>>>>>>>>>>>>>>>>>>>>>>>>>>> recommendations section they
>>>>>>>>>>>>>>>>>>>>>>>>>>> tell the
>>>>>>>>>>>>>>>>>>>>>>>>>>> developer to use a particular property that 
>>>>>>>>>>>>>>>>>>>>>>>>>>> tells them the
>>>>>>>>>>>>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution to figure out which image to load 
>>>>>>>>>>>>>>>>>>>>>>>>>>> if they are
>>>>>>>>>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>>>>>>>>>> manually. There is no discussion about 
>>>>>>>>>>>>>>>>>>>>>>>>>>> dynamically loading
>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>>>>>>>>>>> versions of the image based on a dynamic 
>>>>>>>>>>>>>>>>>>>>>>>>>>> program-applied
>>>>>>>>>>>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>>>>>>>>>>> factor as is done on MacOS.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Also, they tell developers to draw images to 
>>>>>>>>>>>>>>>>>>>>>>>>>>> a specific size
>>>>>>>>>>>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>>>>>>>>>>>> than using auto-sizing. That begs the 
>>>>>>>>>>>>>>>>>>>>>>>>>>> question as to how
>>>>>>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>>>>> interpret a call to draw an image just using 
>>>>>>>>>>>>>>>>>>>>>>>>>>> a location in
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> presence of various DPI factors.
>>>>>>>>>>>>>>>>>>>>>>>>>>       There is an interesting doc that 
>>>>>>>>>>>>>>>>>>>>>>>>>> describes how to write
>>>>>>>>>>>>>>>>>>>>>>>>>> DPI-aware
>>>>>>>>>>>>>>>>>>>>>>>>>> Win32 applications:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>       It is suggested to handle WM_DPICHANGED 
>>>>>>>>>>>>>>>>>>>>>>>>>> message, load
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> graphic
>>>>>>>>>>>>>>>>>>>>>>>>>> that has slightly greater resolution to the 
>>>>>>>>>>>>>>>>>>>>>>>>>> current DPI and
>>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>> StretchBlt
>>>>>>>>>>>>>>>>>>>>>>>>>>       to scale down the image.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before we get too far down the road on 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this API, I think we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the way in which MacOS processes 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution images
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HiDPI
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> screens, but have we investigated the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processes that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under Windows 8? My impression is that 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows 8 has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> included a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of new techniques for dealing with 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the high
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> displays
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that it will run on in the Windows tablet 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and mobile
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> industries
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that these will also come into play as 4K 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> displays (already
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> become more common on the desktop. We 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should make sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> come up with here can provide native 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> platform's policies and standard practices.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like to see a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> summary so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that we can consider them as we review 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this API...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>     There is the Windows Guidelines for 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> scaling to pixel
>>>>>>>>>>>>>>>>>>>>>>>>>>>> density:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>     which says that Windows has automatic 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> resource loading
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>>>>>>>>>>>>> three version of images scaling (100%, 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 140%, and 180%)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Without scaling, as the pixel density of a 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> display device
>>>>>>>>>>>>>>>>>>>>>>>>>>>> increases, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> physical sizes of objects on screen get 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> smaller.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> When UI would otherwise be too small to 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> touch and when text
>>>>>>>>>>>>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>>>>>>> small to read,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows scales the system and app UI to one 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the following
>>>>>>>>>>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>>>>>>>>>>> plateaus:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>      1.0 (100%, no scaling is applied)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>      1.4 (140% scaling)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>      1.8 (180% scaling)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows determines which scaling plateau to 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> use based on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> screen, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>>>>>>>>>>>> factor.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Use resource loading for bitmap images in 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the app package
>>>>>>>>>>>>>>>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bitmap
>>>>>>>>>>>>>>>>>>>>>>>>>>>> images stored
>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the app package, provide a separate 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> image for each
>>>>>>>>>>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>>>>>>>>>>> factor(100%, 140%, and 180%),
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and name your image files using the "scale" 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> naming
>>>>>>>>>>>>>>>>>>>>>>>>>>>> convention
>>>>>>>>>>>>>>>>>>>>>>>>>>>> described
>>>>>>>>>>>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows loads the right image for the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> current scale
>>>>>>>>>>>>>>>>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>   The image name convention for the various 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> scales is:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> images/logo.scale-100.png
>>>>>>>>>>>>>>>>>>>>>>>>>>>> images/logo.scale-140.png
>>>>>>>>>>>>>>>>>>>>>>>>>>>> images/logo.scale-180.png
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>    The 'ms-appx:///images/logo.png' uri is 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> used to load the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>>>>>>>> in an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>    If we want to support this in the same 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> way as it is done
>>>>>>>>>>>>>>>>>>>>>>>>>>>> for Mac
>>>>>>>>>>>>>>>>>>>>>>>>>>>> OS X
>>>>>>>>>>>>>>>>>>>>>>>>>>>>    the WToolkit should return 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolution image in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> case if
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>    The Graphics class can request an image 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> with necessary
>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the MultiResolution image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>    It seems that nothing should be changed 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface in this case.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    bug: 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029339 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    This is a proposal to introduce an API 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that allows to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi resolution image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I. It seems reasonable that the API 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should provide two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   1. Get the resolution variant based on 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the requested
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> width and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> height:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      - Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> width, int height)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     Usually the system provides the scale 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> factor which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> represents
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of pixels corresponding to each 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> linear unit on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> display.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     However, it has sense to combine the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scale factor and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transformations to get the actual image 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> displayed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   2. Get all provided resolution variants:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    There are several uses cases:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Create a new multi-resolution image 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> based on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Pass to the native system the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image. For
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a use can set to the system the custom 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cursor.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> II. There are some possible ways where 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the new API can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   1. java.awt.Image.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    The 2 new methods can be added to the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Image class. A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    the getResolutionVariant() and 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the resolution variants
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    or there can be default 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations of these
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> puts resolution variants
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    to the list in the sorted order.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    To check that the image has resolution 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> variants the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> statement can be used:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image.getResolutionVariants().size()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> != 1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    The disadvantage is that there is an 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> overhead that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should contain the List object and not all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    images can have resolution variants.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   2. Introduce new MultiResolutionImage 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    A user should extend Image class and 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implement the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      public class 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage extends
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implements MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          Image highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage(BufferedImage
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseImage,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> super(baseImage.getWidth(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseImage.getHeight(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> baseImage.getType());
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this.highResolutionImage = 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> g.dispose();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> width, int
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return ((width <= getWidth() && height <=
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getHeight()))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? this : highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Arrays.asList(this,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> highResolutionImage);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   The current fix adds the 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> resolution variant rendering hints.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Wed Dec 10 13:31:42 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 10 Dec 2014 16:31:42 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8065373 [macosx] jdk8,
 jdk7u60 Regression in Graphics2D drawing of derived Fonts
Message-ID: <54884B3E.6060801@oracle.com>

Hello.
Please review the fix for jdk 9/8u40.
Device transformation "fDevTx ", which was added in [1] and fFontTx 
contains different "directions".
Both of them are used in calculation of advances, because of that in 
some cases we get incorrect/opposite text rotation.
Note that I am not sure that fFontTx itself is correct, because it is 
used in printing, which is broken also since a beginning. But for now I 
simply change the newly added fDevTx to fix a regression.

[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a8b9df782017

Bug: https://bugs.openjdk.java.net/browse/JDK-8065373
Webrev can be found at: http://cr.openjdk.java.net/~serb/8065373/webrev.00

-- 
Best regards, Sergey.



From philip.race at oracle.com  Wed Dec 10 23:36:28 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 10 Dec 2014 15:36:28 -0800
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <1415378167.7443.1.camel@nirvana.localdomain>
References: <1415378167.7443.1.camel@nirvana.localdomain>
Message-ID: <5488D8FC.2030700@oracle.com>

> the character is encoded as <c3a4> (which is correct ihmo)
> but then mapped to ISOLatin1Encoding.

\u00e4 (Umlaut) encoded as 8859 should just be "e4".
What you have above is UTF-8, whereas the PS printing path is
definitely expecting 8859-1. I looked and found that when I reviewed this change
I commented it probably should be 8859-1 but didn't make a sufficient point of it :-(
I thought that since we returned latin1 for the charset name we'd get the right encoding
but apparently not, and I imagine what testing was done either didn't cover this range
or the bug was overlooked.

The following is the quick fix I think we need since I think printing and ONLY printing
ever uses this code when we are using fontconfig :-

diff --git a/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java b/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
--- a/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
+++ b/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
@@ -180,7 +180,7 @@
          String[] componentFaceNames = cfi[idx].getComponentFaceNames();
          FontDescriptor[] ret = new FontDescriptor[componentFaceNames.length];
          for (int i = 0; i < componentFaceNames.length; i++) {
-            ret[i] = new FontDescriptor(componentFaceNames[i], StandardCharsets.UTF_8.newEncoder(), new int[0]);
+            ret[i] = new FontDescriptor(componentFaceNames[i], StandardCharsets.ISO_8859_1.newEncoder(), new int[0]);
          }
  
          return ret;

-phil.



On 11/07/2014 08:36 AM, Mario Torre wrote:
> Hi all,
>
> I've been working on a strange issue recently, this seems to affect all
> recent version of OpenJDK as well as Oracle JDK.
>
> The issue appears to be related to this change:
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/fbe9320339ea
>
> The issue as I could find by debugging OpenJDK is a mix of a couple of
> things.
>
> This change was addressing postscript size explosion, where missing font
> descriptor in version prior to this fix were causing characters to be
> rendered as paths.
>
> The new code creates an actual descriptor array, so fonts can be
> rendered directly by postscript. However, it seems that the postscript
> code assumes ISO_8859_1 encoding, so if I pass some characters with,
> say, umlaut, like '?', instead of creating a patch the character is
> encoded as <c3a4> (which is correct ihmo) but then mapped to
> ISOLatin1Encoding.
>
> This is a snippet of the generated postscript file, the file is
> generated using a modified verion of the PrintSE.java test in OpenJDK:
>
> http://cr.openjdk.java.net/~neugens/psDieresisBug/PrintSEUmlauts.java
>
> /ISOF {
>       dup findfont dup length 1 add dict begin {
>               1 index /FID eq {pop pop} {D} ifelse
>       } forall /Encoding ISOLatin1Encoding D
>       currentdict end definefont
> } BD
> /NZ {dup 1 lt {pop 1} if} BD
> /S {
>       moveto 1 index stringwidth pop NZ sub
>       1 index length 1 sub NZ div 0
>       3 2 roll ashow newpath} BD
> 12.0 12 F
> <c3a4> 7.44 100.0 100.0 S
> pgSave restore
>
> I'm not really confident with Postscript at this level, so I would like
> some hints of where to look for an actual fix.
>
> I have a workaround that seems to work, something like:
>
> GlyphVector gv = font.createGlyphVector(frc, "?");
> g2d.drawGlyphVector(gv, 250, 220);
>
> which basically forces the glyph path again. And of course I could
> revert the original change, but in either case it doesn't seem correct.
>
> My guess is that we should either somehow force ISO_8859_1 when calling
> CharsetString[] makeMultiCharsetString from PSPrinterJob, or have a
> proper fix for the Postscript file.
>
> Any idea of hint is very much appreciated.
>
> Cheers,
> Mario
>
>



From victor.dyakov at oracle.com  Thu Dec 11 06:20:05 2014
From: victor.dyakov at oracle.com (Victor D'yakov)
Date: Thu, 11 Dec 2014 09:20:05 +0300
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548796BE.2030504@oracle.com>
References: <548796BE.2030504@oracle.com>
Message-ID: <54893795.6070800@oracle.com>

Do we need to split it to AWT, Swing and 2D?
The email is to 3 lists and its not clear who would pick up reviewing it.

Also please use "client" forest this is our repo for pre-integration 
testing all together with Client SQE we are following to avoid 
regression cases.

Victor

On 10.12.2014 3:41, joe darcy wrote:
> Hello,
>
> In support of JEP 212: Resolve Lint and Doclint Warnings 
> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please 
> review the large but straightforward set of changes in the webrev:
>
>     http://cr.openjdk.java.net/~darcy/8066621.0/
>
> Some background of the approach being taken to address this part of 
> JEP 212 was discussed on core-libs:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>
>
> Briefly, to allow the deprecation warnings to be dealt with and that 
> sole remaining lint warning category enabled in the build, a two-step 
> approach is being taken. The first step is to suppress the deprecation 
> warnings and the second step is for area-experts to examine the 
> specific uses of deprecated APIs in their code. This webrev only 
> attempts to cover the first step.
>
> The webrev is based off of the JDK 9 "dev" forest rather than the 
> "client" forest. Since the change only involves copyright updates and 
> adding annotations, there would be no functional modification in the 
> changeset. Therefore, I would strongly prefer to push these changes 
> directly to dev rather than pushing them to client and waiting for 
> them to propagate to dev to expedite the time when the build warning 
> can be enabled. (If a warning is not enabled in the build, new 
> instances of the warning tend to creep into the code base.)
>
> Thanks,
>
> -Joe



From joe.darcy at oracle.com  Thu Dec 11 06:40:16 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 10 Dec 2014 22:40:16 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <54893795.6070800@oracle.com>
References: <548796BE.2030504@oracle.com> <54893795.6070800@oracle.com>
Message-ID: <54893C50.3080504@oracle.com>

On 12/10/2014 10:20 PM, Victor D'yakov wrote:
> Do we need to split it to AWT, Swing and 2D?

I would not find that helpful.

> The email is to 3 lists and its not clear who would pick up reviewing it.

I assume the people in each are would review their piece of the change.

>
> Also please use "client" forest this is our repo for pre-integration 
> testing all together with Client SQE we are following to avoid 
> regression cases.

As I explained below, since the code changes involve only copyright 
updates (in comments) and annotations (which don't affect the generated 
bytecode), there will no be functional change in the output based on 
this changeset.

Therefore, as long as a build succeeds, I don't see what difference 
client SQE testing would make in this particular case.

-Joe

>
> Victor
>
> On 10.12.2014 3:41, joe darcy wrote:
>> Hello,
>>
>> In support of JEP 212: Resolve Lint and Doclint Warnings 
>> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, 
>> please review the large but straightforward set of changes in the 
>> webrev:
>>
>>     http://cr.openjdk.java.net/~darcy/8066621.0/
>>
>> Some background of the approach being taken to address this part of 
>> JEP 212 was discussed on core-libs:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>>
>>
>> Briefly, to allow the deprecation warnings to be dealt with and that 
>> sole remaining lint warning category enabled in the build, a two-step 
>> approach is being taken. The first step is to suppress the 
>> deprecation warnings and the second step is for area-experts to 
>> examine the specific uses of deprecated APIs in their code. This 
>> webrev only attempts to cover the first step.
>>
>> The webrev is based off of the JDK 9 "dev" forest rather than the 
>> "client" forest. Since the change only involves copyright updates and 
>> adding annotations, there would be no functional modification in the 
>> changeset. Therefore, I would strongly prefer to push these changes 
>> directly to dev rather than pushing them to client and waiting for 
>> them to propagate to dev to expedite the time when the build warning 
>> can be enabled. (If a warning is not enabled in the build, new 
>> instances of the warning tend to creep into the code base.)
>>
>> Thanks,
>>
>> -Joe
>



From Alan.Bateman at oracle.com  Thu Dec 11 10:25:29 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Dec 2014 10:25:29 +0000
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548796BE.2030504@oracle.com>
References: <548796BE.2030504@oracle.com>
Message-ID: <54897119.4080307@oracle.com>

On 10/12/2014 00:41, joe darcy wrote:
> Hello,
>
> In support of JEP 212: Resolve Lint and Doclint Warnings 
> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please 
> review the large but straightforward set of changes in the webrev:
>
>     http://cr.openjdk.java.net/~darcy/8066621.0/
>
> Some background of the approach being taken to address this part of 
> JEP 212 was discussed on core-libs:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>
>
> Briefly, to allow the deprecation warnings to be dealt with and that 
> sole remaining lint warning category enabled in the build, a two-step 
> approach is being taken. The first step is to suppress the deprecation 
> warnings and the second step is for area-experts to examine the 
> specific uses of deprecated APIs in their code. This webrev only 
> attempts to cover the first step.
>
> The webrev is based off of the JDK 9 "dev" forest rather than the 
> "client" forest. Since the change only involves copyright updates and 
> adding annotations, there would be no functional modification in the 
> changeset. Therefore, I would strongly prefer to push these changes 
> directly to dev rather than pushing them to client and waiting for 
> them to propagate to dev to expedite the time when the build warning 
> can be enabled. (If a warning is not enabled in the build, new 
> instances of the warning tend to creep into the code base.)
I've skimmed through the changes and they look okay to me. Clearly it 
would be nice to get some of these addresses so that the 
@SuppressWarnings can be removed in time. As you've pointed out, the 
changes don't impact the generated code.

-Alan.


From philip.race at oracle.com  Thu Dec 11 21:21:51 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 11 Dec 2014 13:21:51 -0800
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8065373 [macosx] jdk8,
 jdk7u60 Regression in Graphics2D drawing of derived Fonts
In-Reply-To: <54884B3E.6060801@oracle.com>
References: <54884B3E.6060801@oracle.com>
Message-ID: <548A0AEF.9030204@oracle.com>

Consistent treatment of concatenating sInverseTx seems right although
I am not sure of the overall picture here.

Quartz uses "y increases upwards"
https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202-CJBBAEEC

2d uses "y increases downwards"
https://docs.oracle.com/javase/tutorial/2d/overview/coordinate.html

It seems like this transform
static CGAffineTransform sInverseTX = { 1, 0, 0, -1, 0, 0 };

might have been to compensate to adjust into the quartz coordinate system
But we should then see this elsewhere .. not just for text - and I do 
see it here for example :-
b ImageSurfaceData.m   941 CGContextConcatCTM(qsdo->cgRef, 
CGAffineTransformMake(1, 0, 0, -1, 0,
                            isdo->height));

However printing perhaps handles it differently.
The PrinterView subclass of NSView overrides isFlipped :-

- (BOOL)isFlipped
{
     return TRUE;
}

But I'd expect to see flipped text, not just incorrectly rotated text, if
this were the problem, so I am far from sure about all of this

-phil.

***
*On 12/10/14 5:31 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9/8u40.
> Device transformation "fDevTx ", which was added in [1] and fFontTx 
> contains different "directions".
> Both of them are used in calculation of advances, because of that in 
> some cases we get incorrect/opposite text rotation.
> Note that I am not sure that fFontTx itself is correct, because it is 
> used in printing, which is broken also since a beginning. But for now 
> I simply change the newly added fDevTx to fix a regression.
>
> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a8b9df782017
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065373
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8065373/webrev.00
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141211/c839b3a5/attachment.html>

From sergey.bylokhov at oracle.com  Thu Dec 11 21:57:34 2014
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 11 Dec 2014 13:57:34 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8065373 [macosx] jdk8,
 jdk7u60 Regression in Graphics2D drawing of derived Fonts
Message-ID: <21417566-8566-42ed-b9b8-b1ae872cd755@default>

Hi, Phil. 
----- philip.race at oracle.com wrote: 
> 

> Consistent treatment of concatenating sInverseTx seems right although 
> I am not sure of the overall picture here. 
> 
> Quartz uses "y increases upwards" 
> https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202-CJBBAEEC 
> 
> 2d uses "y increases downwards" 
> https://docs.oracle.com/javase/tutorial/2d/overview/coordinate.html 
> 
> It seems like this transform 
> static CGAffineTransform sInverseTX = { 1, 0, 0, -1, 0, 0 }; 
> 
> might have been to compensate to adjust into the quartz coordinate system 

Right. 

> But I'd expect to see flipped text, not just incorrectly rotated text, if 
> this were the problem, so I am far from sure about all of this 

The problem also in the fact that fFontTx is incorrectly translated, it is set in SG2D.checkFontInfo(). And CTextPipeline use this translation instead of fontinfo.originX/Y. 

> 
> -phil. 
> 
> 
> On 12/10/14 5:31 AM, Sergey Bylokhov wrote: 
> 

Hello. 
> Please review the fix for jdk 9/8u40. 
> Device transformation "fDevTx ", which was added in [1] and fFontTx contains different "directions". 
> Both of them are used in calculation of advances, because of that in some cases we get incorrect/opposite text rotation. 
> Note that I am not sure that fFontTx itself is correct, because it is used in printing, which is broken also since a beginning. But for now I simply change the newly added fDevTx to fix a regression. 
> 
> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a8b9df782017 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065373 
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8065373/webrev.00 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141211/9e715667/attachment.html>

From andrew.brygin at oracle.com  Fri Dec 12 17:11:46 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Fri, 12 Dec 2014 20:11:46 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
 Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <544AB09D.5060805@oracle.com>
References: <CA+3bSS-SWXEzmcCDttDb8Odp_sozPxv_A0k4zAZvPQ+uU4Ka=A@mail.gmail.com>	<53BD5E45.4000805@oracle.com>
	<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>
	<54297B00.5020604@oracle.com>
	<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>
	<5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com>
	<54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com>
	<54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com>
	<543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com>
	<544A92CC.10406@oracle.com> <544AB09D.5060805@oracle.com>
Message-ID: <548B21D2.8080701@oracle.com>

Hello Phil,

  at the moment, I failed to get acceptable results for rendering to 
translucent destination.
  I am playing with an idea to fall back to grayscale AA on non-opaque 
pixels (or pixels with
  opacity less than a certain threshold) directly in the lcd shader program.

  For now, there is an updated version of the fix which supports lcd 
text in OGL pipeline
  for a case of  alpha paint and default composite. However, the case of 
translucent
  destination is not supported yet, that makes lcd text unavailable in 
swing apps
  on macosx.

  All changes specific for this version are in OGLSurfaceData.java and 
OGLTextRenderer.c.
  Rest of the fix is unchanged.

http://cr.openjdk.java.net/~bae/8023794/9/webrev.04/

  Of course,  this version may affect the performance of lcd text 
rendering, but
  I have no numbers to estimate the effect at the moment. In the worst case,
  we can consider to use two different programs: one for opaque paint 
(in order
  to preserve performance), and another (like published now) for the 
case of alpha
  paint.

  Please take a look.

Thanks,
Andrew

On 10/25/2014 12:03 AM, Phil Race wrote:
> On 10/24/2014 10:56 AM, Andrew Brygin wrote:
>> Hello,
>>
>>  please take a look to updated version of the fix:
>>
>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
>>
>>  TODOs were removed:
>>  * CGLSurfaceData.java
>>       the condition for lcd rendering is inherited from OGL surface 
>> data, but
>>       here we have to remove the check for the transparency, because 
>> we always
>>       create transparent  volatile images for swing backbuffers on 
>> macosx in order
>>       to support shaped windows.
>
> Are you saying its created translucent regardless, or only if its shaped?
> But if its really translucent/transparent under the text, then
> IIRC the shaders - and s/w loops - do not properly handle that case.
> You probably should try drawing LCD text over a fully transparent area
> to see what happens.
>
>>
>> * * *CGGlyphImages.m and AWTStrike.m
>>       NSException is used to  handle invalid (unevaluated) text 
>> antialising hint values.
>>       We actually have already used NSException to handle memory 
>> allocation failure,
>>       so this change just makes usage of get/release of primitive 
>> arrays a bit more safe.
>>
>>
>> Known differences comparing to apple jdk6:
>>
>> a) we do not interpret TEXT_ANTIALIASING_ON as lcd text.
>
> Its should never have meant that, else you would have no way to 
> explicitly
> request grey scale.
>>
>> b) we do not render lcd text in a case of non-opaque paint. This 
>> behavior is common for
>>      all cases (software loops, OGL, and D3D), so it seems to deserve 
>> a separate bug if we
>>      want to handle this case.
>
> I think that's another manifestation of the issue mentioned above.
>
> -phil.
>



From neugens at redhat.com  Fri Dec 12 18:00:28 2014
From: neugens at redhat.com (Mario Torre)
Date: Fri, 12 Dec 2014 19:00:28 +0100
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <5488D8FC.2030700@oracle.com>
References: <1415378167.7443.1.camel@nirvana.localdomain>
	<5488D8FC.2030700@oracle.com>
Message-ID: <1418407228.25551.8.camel@nirvana.localdomain>

On Wed, 2014-12-10 at 15:36 -0800, Phil Race wrote:
> > the character is encoded as <c3a4> (which is correct ihmo)
> > but then mapped to ISOLatin1Encoding.
> 
> \u00e4 (Umlaut) encoded as 8859 should just be "e4".
> What you have above is UTF-8, whereas the PS printing path is
> definitely expecting 8859-1. I looked and found that when I reviewed this change
> I commented it probably should be 8859-1 but didn't make a sufficient point of it :-(
> I thought that since we returned latin1 for the charset name we'd get the right encoding
> but apparently not, and I imagine what testing was done either didn't cover this range
> or the bug was overlooked.
> 
> The following is the quick fix I think we need since I think printing and ONLY printing
> ever uses this code when we are using fontconfig :-
> 
> diff --git a/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java b/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> --- a/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> +++ b/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> @@ -180,7 +180,7 @@
>           String[] componentFaceNames = cfi[idx].getComponentFaceNames();
>           FontDescriptor[] ret = new FontDescriptor[componentFaceNames.length];
>           for (int i = 0; i < componentFaceNames.length; i++) {
> -            ret[i] = new FontDescriptor(componentFaceNames[i], StandardCharsets.UTF_8.newEncoder(), new int[0]);
> +            ret[i] = new FontDescriptor(componentFaceNames[i], StandardCharsets.ISO_8859_1.newEncoder(), new int[0]);
>           }
>   
>           return ret;
> 

Hi Phil,

Thanks for the reply!

I thought it was something along the lines, but I wasn't confident
enough for the fix.

I applied your fix and (of course!) I can confirm it worked, and created
a bug report:

https://bugs.openjdk.java.net/browse/JDK-8067364

I also went ahead and tweaked the test case so that there's no need to
print anymore:

http://cr.openjdk.java.net/~neugens/8067364/webrev.00/

This webrev contains the updated test case based on the PrintSE test and
your fix. I will be happy to push the fix myself if you prefer.

Cheers,
Mario




From philip.race at oracle.com  Fri Dec 12 18:11:14 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 12 Dec 2014 10:11:14 -0800
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <1418407228.25551.8.camel@nirvana.localdomain>
References: <1415378167.7443.1.camel@nirvana.localdomain>	
	<5488D8FC.2030700@oracle.com>
	<1418407228.25551.8.camel@nirvana.localdomain>
Message-ID: <548B2FC2.2080201@oracle.com>

Hi Mario,

I don't understand why your test needs a shell script to compile it ?

Once we've resolved that question,   and you get a 2nd review, feel
free to push.

-phil.

On 12/12/14 10:00 AM, Mario Torre wrote:
> On Wed, 2014-12-10 at 15:36 -0800, Phil Race wrote:
>>> the character is encoded as <c3a4> (which is correct ihmo)
>>> but then mapped to ISOLatin1Encoding.
>> \u00e4 (Umlaut) encoded as 8859 should just be "e4".
>> What you have above is UTF-8, whereas the PS printing path is
>> definitely expecting 8859-1. I looked and found that when I reviewed this change
>> I commented it probably should be 8859-1 but didn't make a sufficient point of it :-(
>> I thought that since we returned latin1 for the charset name we'd get the right encoding
>> but apparently not, and I imagine what testing was done either didn't cover this range
>> or the bug was overlooked.
>>
>> The following is the quick fix I think we need since I think printing and ONLY printing
>> ever uses this code when we are using fontconfig :-
>>
>> diff --git a/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java b/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
>> --- a/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
>> +++ b/src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
>> @@ -180,7 +180,7 @@
>>            String[] componentFaceNames = cfi[idx].getComponentFaceNames();
>>            FontDescriptor[] ret = new FontDescriptor[componentFaceNames.length];
>>            for (int i = 0; i < componentFaceNames.length; i++) {
>> -            ret[i] = new FontDescriptor(componentFaceNames[i], StandardCharsets.UTF_8.newEncoder(), new int[0]);
>> +            ret[i] = new FontDescriptor(componentFaceNames[i], StandardCharsets.ISO_8859_1.newEncoder(), new int[0]);
>>            }
>>    
>>            return ret;
>>
> Hi Phil,
>
> Thanks for the reply!
>
> I thought it was something along the lines, but I wasn't confident
> enough for the fix.
>
> I applied your fix and (of course!) I can confirm it worked, and created
> a bug report:
>
> https://bugs.openjdk.java.net/browse/JDK-8067364
>
> I also went ahead and tweaked the test case so that there's no need to
> print anymore:
>
> http://cr.openjdk.java.net/~neugens/8067364/webrev.00/
>
> This webrev contains the updated test case based on the PrintSE test and
> your fix. I will be happy to push the fix myself if you prefer.
>
> Cheers,
> Mario
>
>



From neugens at redhat.com  Fri Dec 12 18:15:57 2014
From: neugens at redhat.com (Mario Torre)
Date: Fri, 12 Dec 2014 19:15:57 +0100
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <548B2FC2.2080201@oracle.com>
References: <1415378167.7443.1.camel@nirvana.localdomain>
	<5488D8FC.2030700@oracle.com>
	<1418407228.25551.8.camel@nirvana.localdomain>
	<548B2FC2.2080201@oracle.com>
Message-ID: <1418408157.25551.10.camel@nirvana.localdomain>

On Fri, 2014-12-12 at 10:11 -0800, Phil Race wrote:
> Hi Mario,
> 
> I don't understand why your test needs a shell script to compile it ?
> 
> Once we've resolved that question,   and you get a 2nd review, feel
> free to push.

Sure, on my system the test randomly hangs if I don't call
System.exit(0) from the printing thread, but jtreg doesn't like
System.exit to be called, so basically the tests never exits.

I'm happy to revisit the code if you know how I can make the program
exit normally :)

Cheer,
Mario




From philip.race at oracle.com  Fri Dec 12 19:06:10 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 12 Dec 2014 11:06:10 -0800
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <1418408157.25551.10.camel@nirvana.localdomain>
References: <1415378167.7443.1.camel@nirvana.localdomain>		
	<5488D8FC.2030700@oracle.com>	
	<1418407228.25551.8.camel@nirvana.localdomain>	
	<548B2FC2.2080201@oracle.com>
	<1418408157.25551.10.camel@nirvana.localdomain>
Message-ID: <548B3CA2.3070503@oracle.com>

Correct. jtreg doesn't like System.exit() but I also understand that shell
tests are now highly frowned upon.
So either
1) Run using "othervm" where calling System.exit() should be fine - I 
think !?
2) Don't worry about it, assuming jtreg can clean up if needed. If it can't
halt the test threads then that seems to be a different problem that I'd
expect occurs in many tests.

-phil.

On 12/12/2014 10:15 AM, Mario Torre wrote:
> On Fri, 2014-12-12 at 10:11 -0800, Phil Race wrote:
>> Hi Mario,
>>
>> I don't understand why your test needs a shell script to compile it ?
>>
>> Once we've resolved that question,   and you get a 2nd review, feel
>> free to push.
> Sure, on my system the test randomly hangs if I don't call
> System.exit(0) from the printing thread, but jtreg doesn't like
> System.exit to be called, so basically the tests never exits.
>
> I'm happy to revisit the code if you know how I can make the program
> exit normally :)
>
> Cheer,
> Mario
>
>



From philip.race at oracle.com  Fri Dec 12 20:46:44 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 12 Dec 2014 12:46:44 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548796BE.2030504@oracle.com>
References: <548796BE.2030504@oracle.com>
Message-ID: <548B5434.4020609@oracle.com>

Hi,
You did not provide a direct reference to the set of warnings that were 
generated.
fortunately I found it here :- 
https://bugs.openjdk.java.net/browse/JDK-8066622

A couple of things I find 'unfortunate' are
1) In order to avoid a deprecation warning on one call/line of a 100 
line method,
the entire method is subject to the annotation. Eg :-
dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: 
warning: [deprecation] show() in Dialog has been deprecated

Other deprecated uses could silently creep into such a body of code.

2) Some significant fraction of all the warnings are for getPeer() :-
dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: 
warning: [deprecation] getPeer() in Component has been deprecated

The issue here is that the deprecation javadoc tag is unable to 
distinguish deprecated for
external usage vs legitimate internal usage. There is no problem with 
code inside the desktop module
calling getPeer() which is defined in this same module.  There may not 
be many other APIs that
have this similar issue, but if there are it might be better to find 
some way to make it clear
that we aren't suppressing warnings until we fix the code : rather we 
really should not be
receiving a warning here anyway since there is nothing to fix. Perhaps 
"Component. getPeer()"
could acquire an annotation  like "module-nodeprecation" which 
automatically suppresses the
annotation processor  warnings for all such cases. If javac doesn't know 
about modules perhaps
we could utilise a javac flag that's used only by the JDK build to 
indicate that an annotation
like that should apply.

Regarding the show() case above I came across a puzzle.
show() is first defined on Component, as is its 'replacement' 
setVisible(boolean).
It turns out that what we have in Component is

public void setVisible(boolean b) {
    show(b);
}

@Deprecated
public void show(boolean b) {
    if (b) {
       show();
   } else {
       hide();
}

@Deprecated
public void show() {
  ...
}

So I am puzzled why those uses within Component aren't suppressed in 
your webrev ?
Is there some automatic suppression of the warnings within the class 
that does
the deprecation ? If so then perhaps the module idea above can be considered
an extension of this. If that isn't what's happening, then what is ?

-phil.





On 12/9/2014 4:41 PM, joe darcy wrote:
> Hello,
>
> In support of JEP 212: Resolve Lint and Doclint Warnings 
> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please 
> review the large but straightforward set of changes in the webrev:
>
>     http://cr.openjdk.java.net/~darcy/8066621.0/
>
> Some background of the approach being taken to address this part of 
> JEP 212 was discussed on core-libs:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>
>
> Briefly, to allow the deprecation warnings to be dealt with and that 
> sole remaining lint warning category enabled in the build, a two-step 
> approach is being taken. The first step is to suppress the deprecation 
> warnings and the second step is for area-experts to examine the 
> specific uses of deprecated APIs in their code. This webrev only 
> attempts to cover the first step.
>
> The webrev is based off of the JDK 9 "dev" forest rather than the 
> "client" forest. Since the change only involves copyright updates and 
> adding annotations, there would be no functional modification in the 
> changeset. Therefore, I would strongly prefer to push these changes 
> directly to dev rather than pushing them to client and waiting for 
> them to propagate to dev to expedite the time when the build warning 
> can be enabled. (If a warning is not enabled in the build, new 
> instances of the warning tend to creep into the code base.)
>
> Thanks,
>
> -Joe



From joe.darcy at oracle.com  Sat Dec 13 01:35:17 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 12 Dec 2014 17:35:17 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548B5434.4020609@oracle.com>
References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com>
Message-ID: <548B97D5.9050408@oracle.com>

Hi Phil,

On 12/12/2014 12:46 PM, Phil Race wrote:
> Hi,
> You did not provide a direct reference to the set of warnings that 
> were generated.
> fortunately I found it here :- 
> https://bugs.openjdk.java.net/browse/JDK-8066622

Each "Suppress deprecations warnings in foo" bug is linked to a "Fix 
deprecation warnings in foo" bug which lists the exact warnings.

>
> A couple of things I find 'unfortunate' are
> 1) In order to avoid a deprecation warning on one call/line of a 100 
> line method,
> the entire method is subject to the annotation. Eg :-
> dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: 
> warning: [deprecation] show() in Dialog has been deprecated
>
> Other deprecated uses could silently creep into such a body of code.

That is true, but today deprecations warnings can (and do) creep into 
the entirely of the JDK without notice. Turning on the deprecation lint 
warning in the build will prevent that for the vast majority of code, 
which is why I want to get the remaining warning suppression bugs 
quickly pushed into JDK 9 so the build warning can be enabled. (This 
suppression effort was on hold until a small language change was 
recently implemented in JDK 9 to eliminate deprecation warnings just for 
importing a deprecated type.)

For the "fix the warning" companion bug to this bug, I would recommend 
factoring out the deprecated method call into its own private method to 
limit the scope of the @SuppressWarning annotation. For this changeset, 
I didn't want to actually modify the contents or structure of any 
methods I so didn't undertake that kind of transformation.

>
> 2) Some significant fraction of all the warnings are for getPeer() :-
> dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: 
> warning: [deprecation] getPeer() in Component has been deprecated

Yes, I also noticed that a sizeable percentage of the warnings were for 
uses of that one method.

>
> The issue here is that the deprecation javadoc tag is unable to 
> distinguish deprecated for
> external usage vs legitimate internal usage.

FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at JavaOne 
this year covering the nuances of deprecation in the JDK:

https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377

> There is no problem with code inside the desktop module
> calling getPeer() which is defined in this same module.  There may not 
> be many other APIs that
> have this similar issue, but if there are it might be better to find 
> some way to make it clear
> that we aren't suppressing warnings until we fix the code : rather we 
> really should not be
> receiving a warning here anyway since there is nothing to fix.

Well, the @SuppressWarnings annotation can be used to convey that 
information, perhaps supplemented by a comment or a wrapper method 
around getPeer; something like

/**
   * Package-access method somewhere in java.awt
   */
@SuppressWarnings("deprecation")
static java.awt Component privilegeOfPeerage(java.awt Component c) {
     return c.getPeer();
}

> Perhaps "Component. getPeer()"
> could acquire an annotation  like "module-nodeprecation" which 
> automatically suppresses the
> annotation processor  warnings for all such cases. If javac doesn't 
> know about modules perhaps
> we could utilise a javac flag that's used only by the JDK build to 
> indicate that an annotation
> like that should apply.

At this point, I think that level of solution would be overkill 
(especially given the JDK's historical lack of discipline around 
deprecation warnings).

>
> Regarding the show() case above I came across a puzzle.
> show() is first defined on Component, as is its 'replacement' 
> setVisible(boolean).
> It turns out that what we have in Component is
>
> public void setVisible(boolean b) {
>    show(b);
> }
>
> @Deprecated
> public void show(boolean b) {
>    if (b) {
>       show();
>   } else {
>       hide();
> }
>
> @Deprecated
> public void show() {
>  ...
> }
>
> So I am puzzled why those uses within Component aren't suppressed in 
> your webrev ?
> Is there some automatic suppression of the warnings within the class 
> that does
> the deprecation ? 

Yes, quoting from the JLS:

"A Java compiler must produce a deprecation warning when a type, method, 
field, or constructor whose declaration is annotated with |@Deprecated| 
is used (overridden, invoked, or referenced by name) in a construct 
which is explicitly or implicitly declared, unless:
     * [...]
     * The use and declaration are both within the same outermost class. "

http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6

Thanks for the review,

-Joe

> If so then perhaps the module idea above can be considered
> an extension of this. If that isn't what's happening, then what is ?
>
> -phil.
>
>
>
>
>
> On 12/9/2014 4:41 PM, joe darcy wrote:
>> Hello,
>>
>> In support of JEP 212: Resolve Lint and Doclint Warnings 
>> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, 
>> please review the large but straightforward set of changes in the 
>> webrev:
>>
>>     http://cr.openjdk.java.net/~darcy/8066621.0/
>>
>> Some background of the approach being taken to address this part of 
>> JEP 212 was discussed on core-libs:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>>
>>
>> Briefly, to allow the deprecation warnings to be dealt with and that 
>> sole remaining lint warning category enabled in the build, a two-step 
>> approach is being taken. The first step is to suppress the 
>> deprecation warnings and the second step is for area-experts to 
>> examine the specific uses of deprecated APIs in their code. This 
>> webrev only attempts to cover the first step.
>>
>> The webrev is based off of the JDK 9 "dev" forest rather than the 
>> "client" forest. Since the change only involves copyright updates and 
>> adding annotations, there would be no functional modification in the 
>> changeset. Therefore, I would strongly prefer to push these changes 
>> directly to dev rather than pushing them to client and waiting for 
>> them to propagate to dev to expedite the time when the build warning 
>> can be enabled. (If a warning is not enabled in the build, new 
>> instances of the warning tend to creep into the code base.)
>>
>> Thanks,
>>
>> -Joe
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141212/6d1873e6/attachment.html>

From Alan.Bateman at oracle.com  Sat Dec 13 09:11:08 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 09:11:08 +0000
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548B5434.4020609@oracle.com>
References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com>
Message-ID: <548C02AC.4020301@oracle.com>

On 12/12/2014 20:46, Phil Race wrote:
> :
>
> 2) Some significant fraction of all the warnings are for getPeer() :-
> dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: 
> warning: [deprecation] getPeer() in Component has been deprecated
>
> The issue here is that the deprecation javadoc tag is unable to 
> distinguish deprecated for
> external usage vs legitimate internal usage. There is no problem with 
> code inside the desktop module
> calling getPeer() which is defined in this same module.

In our modularization effort then the highest priority issue for the 
client libraries area is JDK-8037739. This issue is about examining the 
supportness of the peer APIs, and assuming they aren't meant to be 
exported, then removing all references from the Java SE APIs (which 
might mean removing methods). Assuming that java.awt.peer and 
java.awt.dnd.peer are JDK-internal then you could drop the @Deprecated tags.

-Alan


From philip.race at oracle.com  Sun Dec 14 15:57:06 2014
From: philip.race at oracle.com (Phil Race)
Date: Sun, 14 Dec 2014 07:57:06 -0800
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8065373 [macosx] jdk8,
 jdk7u60 Regression in Graphics2D drawing of derived Fonts
In-Reply-To: <21417566-8566-42ed-b9b8-b1ae872cd755@default>
References: <21417566-8566-42ed-b9b8-b1ae872cd755@default>
Message-ID: <548DB352.4030806@oracle.com>

OK to your explanation .. seems the printing case should be handled 
separately.
Not sure off-hand why PrintView flips and nothing else does. I suppose 
it is to
get back to the quartz coordinate system which is the same as the postscript
coordinate system as that'll be what you want when printing.

-phil.

On 12/11/14 1:57 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> ----- philip.race at oracle.com wrote:
> >
> > Consistent treatment of concatenating sInverseTx seems right although
> > I am not sure of the overall picture here.
> >
> > Quartz uses "y increases upwards"
> > 
> https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202-CJBBAEEC
> >
> > 2d uses "y increases downwards"
> > https://docs.oracle.com/javase/tutorial/2d/overview/coordinate.html
> >
> > It seems like this transform
> > static CGAffineTransform sInverseTX = { 1, 0, 0, -1, 0, 0 };
> >
> > might have been to compensate to adjust into the quartz coordinate 
> system
>
> Right.
>
> > But I'd expect to see flipped text, not just incorrectly rotated 
> text, if
> > this were the problem, so I am far from sure about all of this
>
> The problem also in the fact that fFontTx is incorrectly translated, 
> it is set in SG2D.checkFontInfo(). And CTextPipeline use this 
> translation instead of fontinfo.originX/Y.
>
> >
> > -phil.
> >
> > *
> > *On 12/10/14 5:31 AM, Sergey Bylokhov wrote:
> >
>
>     Hello.
>     > Please review the fix for jdk 9/8u40.
>     > Device transformation "fDevTx ", which was added in [1] and
>     fFontTx contains different "directions".
>     > Both of them are used in calculation of advances, because of
>     that in some cases we get incorrect/opposite text rotation.
>     > Note that I am not sure that fFontTx itself is correct, because
>     it is used in printing, which is broken also since a beginning.
>     But for now I simply change the newly added fDevTx to fix a
>     regression.
>     >
>     > [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a8b9df782017
>     >
>     > Bug: https://bugs.openjdk.java.net/browse/JDK-8065373
>     > Webrev can be found at:
>     http://cr.openjdk.java.net/~serb/8065373/webrev.00
>     >
>     > 
>
>
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141214/2d959c09/attachment.html>

From philip.race at oracle.com  Mon Dec 15 19:48:37 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 15 Dec 2014 11:48:37 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548B97D5.9050408@oracle.com>
References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com>
	<548B97D5.9050408@oracle.com>
Message-ID: <548F3B15.1050300@oracle.com>



On 12/12/14 5:35 PM, joe darcy wrote:
> Hi Phil,
>
> On 12/12/2014 12:46 PM, Phil Race wrote:
>> Hi,
>> You did not provide a direct reference to the set of warnings that 
>> were generated.
>> fortunately I found it here :- 
>> https://bugs.openjdk.java.net/browse/JDK-8066622
>
> Each "Suppress deprecations warnings in foo" bug is linked to a "Fix 
> deprecation warnings in foo" bug which lists the exact warnings.
>
OK .. direct link would have helped.


>>
>> A couple of things I find 'unfortunate' are
>> 1) In order to avoid a deprecation warning on one call/line of a 100 
>> line method,
>> the entire method is subject to the annotation. Eg :-
>> dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: warning: 
>> [deprecation] show() in Dialog has been deprecated
>>
>> Other deprecated uses could silently creep into such a body of code.
>
> That is true, but today deprecations warnings can (and do) creep into 
> the entirely of the JDK without notice. Turning on the deprecation 
> lint warning in the build will prevent that for the vast majority of 
> code, which is why I want to get the remaining warning suppression 
> bugs quickly pushed into JDK 9 so the build warning can be enabled. 
> (This suppression effort was on hold until a small language change was 
> recently implemented in JDK 9 to eliminate deprecation warnings just 
> for importing a deprecated type.)

Maybe a digression, but why go to the trouble, why would one 
legitimately import a
(deprecated) type and yet not use it ?

But the gist of my point is that with this approach more warnings can 
still creep in.
Its unfortunate that the annotation system does not provide a way to 
annotate the specific call
and so it is not apparent to the reader what its suppressing.

> For the "fix the warning" companion bug to this bug, I would recommend 
> factoring out the deprecated method call into its own private method 
> to limit the scope of the @SuppressWarning annotation. For this 
> changeset, I didn't want to actually modify the contents or structure 
> of any methods I so didn't undertake that kind of transformation.
Adding a wrapper method seems artificial.
Personally I would prefer to find a solution in the annotation system or 
find a replacement or de-deprecating
as Alan suggested might work in some cases, although Stuart Marks said 
RMI has the same case.


>>
>> 2) Some significant fraction of all the warnings are for getPeer() :-
>> dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: 
>> warning: [deprecation] getPeer() in Component has been deprecated
>
> Yes, I also noticed that a sizeable percentage of the warnings were 
> for uses of that one method.

>
>>
>> The issue here is that the deprecation javadoc tag is unable to 
>> distinguish deprecated for
>> external usage vs legitimate internal usage.
>
> FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at JavaOne 
> this year covering the nuances of deprecation in the JDK:
>
> https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377
>
>> There is no problem with code inside the desktop module
>> calling getPeer() which is defined in this same module.  There may 
>> not be many other APIs that
>> have this similar issue, but if there are it might be better to find 
>> some way to make it clear
>> that we aren't suppressing warnings until we fix the code : rather we 
>> really should not be
>> receiving a warning here anyway since there is nothing to fix.
>
> Well, the @SuppressWarnings annotation can be used to convey that 
> information, perhaps supplemented by a comment or a wrapper method 
> around getPeer; something like
>
> /**
>   * Package-access method somewhere in java.awt
>   */
> @SuppressWarnings("deprecation")
> static java.awt Component privilegeOfPeerage(java.awt Component c)  {
>     return c.getPeer();
> }
>

I don't think that conveys that its OK to use. It just adds work to hide 
it in a different way.

>> Perhaps "Component. getPeer()"
>> could acquire an annotation  like "module-nodeprecation" which 
>> automatically suppresses the
>> annotation processor  warnings for all such cases. If javac doesn't 
>> know about modules perhaps
>> we could utilise a javac flag that's used only by the JDK build to 
>> indicate that an annotation
>> like that should apply.
>
> At this point, I think that level of solution would be overkill 
> (especially given the JDK's historical lack of discipline around 
> deprecation warnings).
>

Well .. I think its worth more discussion than dismissing it out of hand.
>>
>> Regarding the show() case above I came across a puzzle.
>> show() is first defined on Component, as is its 'replacement' 
>> setVisible(boolean).
>> It turns out that what we have in Component is
>>
>> public void setVisible(boolean b) {
>>    show(b);
>> }
>>
>> @Deprecated
>> public void show(boolean b) {
>>    if (b) {
>>       show();
>>   } else {
>>       hide();
>> }
>>
>> @Deprecated
>> public void show() {
>>  ...
>> }
>>
>> So I am puzzled why those uses within Component aren't suppressed in 
>> your webrev ?
>> Is there some automatic suppression of the warnings within the class 
>> that does
>> the deprecation ? 
>
> Yes, quoting from the JLS:
>
> "A Java compiler must produce a deprecation warning when a type, 
> method, field, or constructor whose declaration is annotated with 
> |@Deprecated| is used (overridden, invoked, or referenced by name) in 
> a construct which is explicitly or implicitly declared, unless:
>     * [...]
>     * The use and declaration are both within the same outermost class. "
>
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6

OK. So that's not as well known as you'd think. It stumped Stuart.
I had to 'infer'  this from the observed behaviour.

At this point I'll approve the changes although I would like full 
consideration
of enhancements to the APS in the future.

Also I believe this should go to client. If it gets pushed by the end of 
the day
or at least no later than the end of tomorrow it should be integrated by 
23rd.

-phil.

>
> Thanks for the review,
>
> -Joe
>
>> If so then perhaps the module idea above can be considered
>> an extension of this. If that isn't what's happening, then what is ?
>>
>> -phil.
>>
>>
>>
>>
>>
>> On 12/9/2014 4:41 PM, joe darcy wrote:
>>> Hello,
>>>
>>> In support of JEP 212: Resolve Lint and Doclint Warnings 
>>> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, 
>>> please review the large but straightforward set of changes in the 
>>> webrev:
>>>
>>> http://cr.openjdk.java.net/~darcy/8066621.0/
>>>
>>> Some background of the approach being taken to address this part of 
>>> JEP 212 was discussed on core-libs:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>>>
>>>
>>> Briefly, to allow the deprecation warnings to be dealt with and that 
>>> sole remaining lint warning category enabled in the build, a 
>>> two-step approach is being taken. The first step is to suppress the 
>>> deprecation warnings and the second step is for area-experts to 
>>> examine the specific uses of deprecated APIs in their code. This 
>>> webrev only attempts to cover the first step.
>>>
>>> The webrev is based off of the JDK 9 "dev" forest rather than the 
>>> "client" forest. Since the change only involves copyright updates 
>>> and adding annotations, there would be no functional modification in 
>>> the changeset. Therefore, I would strongly prefer to push these 
>>> changes directly to dev rather than pushing them to client and 
>>> waiting for them to propagate to dev to expedite the time when the 
>>> build warning can be enabled. (If a warning is not enabled in the 
>>> build, new instances of the warning tend to creep into the code base.)
>>>
>>> Thanks,
>>>
>>> -Joe
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141215/417ad43e/attachment.html>

From philip.race at oracle.com  Mon Dec 15 20:20:09 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 15 Dec 2014 12:20:09 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses
 family+style, not full name/postscript name
Message-ID: <548F4279.5040002@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8064833
http://cr.openjdk.java.net/~prr/8064833/

OS X font look up is using family name + style - even when using deriveFont
from a specific font. Since the family name like "Helvetica" is 
insufficient to
convey that you are using the "Helvetica Light" subfamily and we get the
wronf font.
The provided test shows that the results can be completely garbage 
rendering.

Some clean up included here is remove the unconditional define of DEBUG and
the native 'isFakeItalic' variable which was not used anywhere.

-phil.


From joe.darcy at oracle.com  Tue Dec 16 04:07:30 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 15 Dec 2014 20:07:30 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation
 warnings in java.desktop module
In-Reply-To: <548F3B15.1050300@oracle.com>
References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com>
	<548B97D5.9050408@oracle.com> <548F3B15.1050300@oracle.com>
Message-ID: <548FB002.4030809@oracle.com>

On 12/15/2014 11:48 AM, Phil Race wrote:
>
>
> On 12/12/14 5:35 PM, joe darcy wrote:
>> Hi Phil,
>>
>> On 12/12/2014 12:46 PM, Phil Race wrote:
>>> Hi,
>>> You did not provide a direct reference to the set of warnings that 
>>> were generated.
>>> fortunately I found it here :- 
>>> https://bugs.openjdk.java.net/browse/JDK-8066622
>>
>> Each "Suppress deprecations warnings in foo" bug is linked to a "Fix 
>> deprecation warnings in foo" bug which lists the exact warnings.
>>
> OK .. direct link would have helped.
>
>
>>>
>>> A couple of things I find 'unfortunate' are
>>> 1) In order to avoid a deprecation warning on one call/line of a 100 
>>> line method,
>>> the entire method is subject to the annotation. Eg :-
>>> dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: 
>>> warning: [deprecation] show() in Dialog has been deprecated
>>>
>>> Other deprecated uses could silently creep into such a body of code.
>>
>> That is true, but today deprecations warnings can (and do) creep into 
>> the entirely of the JDK without notice. Turning on the deprecation 
>> lint warning in the build will prevent that for the vast majority of 
>> code, which is why I want to get the remaining warning suppression 
>> bugs quickly pushed into JDK 9 so the build warning can be enabled. 
>> (This suppression effort was on hold until a small language change 
>> was recently implemented in JDK 9 to eliminate deprecation warnings 
>> just for importing a deprecated type.)
>
> Maybe a digression, but why go to the trouble, why would one 
> legitimately import a
> (deprecated) type and yet not use it ?

That is not the scenario that is problematic. If you 
@SuppressWarnings("deprecation") at the top of a class, that declaration 
annotation does *not* cover import statements. Additionally, a 
@SuppressWarnings("deprecation") annotation cannot be applied to import 
statements (this is a restriction since JDK 5).

Therefore, before the small language change to elide deprecation 
warnings on import statements made in JDK 9 (JEP 211), you could have a 
class where:

* A deprecated type was imported
* All the uses of the deprecated type in the code were @SuppressWarnings'ed

and still the class would generate deprecation warnings when it was 
compiled. To get a warning-free compile, the import statement would need 
to be removed and all the uses of the type replaced by fully qualified 
names, which is an unreasonable transformation to get warning-free code!

>
> But the gist of my point is that with this approach more warnings can 
> still creep in.
> Its unfortunate that the annotation system does not provide a way to 
> annotate the specific call
> and so it is not apparent to the reader what its suppressing.

Conversely, the downside of annotating every call site is that every 
call site is annotated...

All the @SuppressWarnings annotations are scoped to the declaration they 
are applied to (type, method/constructor, field). If you want to reduce 
the scope of warning suppression, a new scope can be introduced, such as 
a new method to contain the problematic construct. (This is analogous to 
introducing a new temporary variable with an @SuppressWarnings 
annotation to constrain the suppression to the expression used to 
initialize the variable, a technique that was used on occasion in the 
warnings cleanup changes earlier in JDK 9.)

>
>> For the "fix the warning" companion bug to this bug, I would 
>> recommend factoring out the deprecated method call into its own 
>> private method to limit the scope of the @SuppressWarning annotation. 
>> For this changeset, I didn't want to actually modify the contents or 
>> structure of any methods I so didn't undertake that kind of 
>> transformation.
> Adding a wrapper method seems artificial.
> Personally I would prefer to find a solution in the annotation system 
> or find a replacement or de-deprecating
> as Alan suggested might work in some cases, although Stuart Marks said 
> RMI has the same case.
>
>
>>>
>>> 2) Some significant fraction of all the warnings are for getPeer() :-
>>> dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: 
>>> warning: [deprecation] getPeer() in Component has been deprecated
>>
>> Yes, I also noticed that a sizeable percentage of the warnings were 
>> for uses of that one method.
>
>>
>>>
>>> The issue here is that the deprecation javadoc tag is unable to 
>>> distinguish deprecated for
>>> external usage vs legitimate internal usage.
>>
>> FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at JavaOne 
>> this year covering the nuances of deprecation in the JDK:
>>
>> https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377
>>
>>> There is no problem with code inside the desktop module
>>> calling getPeer() which is defined in this same module.  There may 
>>> not be many other APIs that
>>> have this similar issue, but if there are it might be better to find 
>>> some way to make it clear
>>> that we aren't suppressing warnings until we fix the code : rather 
>>> we really should not be
>>> receiving a warning here anyway since there is nothing to fix.
>>
>> Well, the @SuppressWarnings annotation can be used to convey that 
>> information, perhaps supplemented by a comment or a wrapper method 
>> around getPeer; something like
>>
>> /**
>>   * Package-access method somewhere in java.awt
>>   */
>> @SuppressWarnings("deprecation")
>> static java.awt Component privilegeOfPeerage(java.awt Component c)  {
>>     return c.getPeer();
>> }
>>
>
> I don't think that conveys that its OK to use. It just adds work to 
> hide it in a different way.

A comment could be added to clarify "Package-level method to allow 
warning-free package-level use."

>
>>> Perhaps "Component. getPeer()"
>>> could acquire an annotation  like "module-nodeprecation" which 
>>> automatically suppresses the
>>> annotation processor  warnings for all such cases. If javac doesn't 
>>> know about modules perhaps
>>> we could utilise a javac flag that's used only by the JDK build to 
>>> indicate that an annotation
>>> like that should apply.
>>
>> At this point, I think that level of solution would be overkill 
>> (especially given the JDK's historical lack of discipline around 
>> deprecation warnings).
>>
>
> Well .. I think its worth more discussion than dismissing it out of hand.
>>>
>>> Regarding the show() case above I came across a puzzle.
>>> show() is first defined on Component, as is its 'replacement' 
>>> setVisible(boolean).
>>> It turns out that what we have in Component is
>>>
>>> public void setVisible(boolean b) {
>>>    show(b);
>>> }
>>>
>>> @Deprecated
>>> public void show(boolean b) {
>>>    if (b) {
>>>       show();
>>>   } else {
>>>       hide();
>>> }
>>>
>>> @Deprecated
>>> public void show() {
>>>  ...
>>> }
>>>
>>> So I am puzzled why those uses within Component aren't suppressed in 
>>> your webrev ?
>>> Is there some automatic suppression of the warnings within the class 
>>> that does
>>> the deprecation ? 
>>
>> Yes, quoting from the JLS:
>>
>> "A Java compiler must produce a deprecation warning when a type, 
>> method, field, or constructor whose declaration is annotated with 
>> |@Deprecated| is used (overridden, invoked, or referenced by name) in 
>> a construct which is explicitly or implicitly declared, unless:
>>     * [...]
>>     * The use and declaration are both within the same outermost class. "
>>
>> http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6
>
> OK. So that's not as well known as you'd think. It stumped Stuart.
> I had to 'infer'  this from the observed behaviour.

Although it may be surprising, that aspect of deprecation goes back a 
long ways.

>
> At this point I'll approve the changes although I would like full 
> consideration
> of enhancements to the APS in the future.
>
> Also I believe this should go to client. If it gets pushed by the end 
> of the day
> or at least no later than the end of tomorrow it should be integrated 
> by 23rd.

I've pushed the changes to the client repo.

I will be soon preparing two additional changesets for review to perform 
similar deprecation warning suppression in platform-specific client code.

Thanks,

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141215/432385c1/attachment.html>

From joe.darcy at oracle.com  Tue Dec 16 06:07:01 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 15 Dec 2014 22:07:01 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
Message-ID: <548FCC05.4000907@oracle.com>

Hello,

Please review the next step of suppressing the deprecation warnings the 
client libraries, this time in windows-specific desktop code:

     JDK-8067092: Suppress windows-specific deprecation warnings in the 
java.desktop module
     http://cr.openjdk.java.net/~darcy/8067092.0/

Thanks,

-Joe


From joe.darcy at oracle.com  Tue Dec 16 06:48:23 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 15 Dec 2014 22:48:23 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067086: Suppress mac-specific
 deprecation warnings in the java.desktop module
Message-ID: <548FD5B7.5040703@oracle.com>

Hello,

Please review this (hopefully) last change to suppress the deprecation 
warnings in the java.desktop module:

     8067086: Suppress mac-specific deprecation warnings in the 
java.desktop module
     http://cr.openjdk.java.net/~darcy/8067086.0/

Thanks,

-Joe


From Alan.Bateman at oracle.com  Tue Dec 16 11:15:28 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Dec 2014 11:15:28 +0000
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <548FCC05.4000907@oracle.com>
References: <548FCC05.4000907@oracle.com>
Message-ID: <54901450.1000309@oracle.com>

On 16/12/2014 06:07, joe darcy wrote:
> Hello,
>
> Please review the next step of suppressing the deprecation warnings 
> the client libraries, this time in windows-specific desktop code:
>
>     JDK-8067092: Suppress windows-specific deprecation warnings in the 
> java.desktop module
>     http://cr.openjdk.java.net/~darcy/8067092.0/
>
> Thanks,
Lots more getPeer :-)

The change looks okay to me and the same techniques to reduce these as 
per the other thread.

-Alan


From andrew.brygin at oracle.com  Tue Dec 16 15:31:26 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Tue, 16 Dec 2014 18:31:26 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8065373 [macosx] jdk8,
 jdk7u60 Regression in Graphics2D drawing of derived Fonts
In-Reply-To: <21417566-8566-42ed-b9b8-b1ae872cd755@default>
References: <21417566-8566-42ed-b9b8-b1ae872cd755@default>
Message-ID: <5490504E.7000207@oracle.com>

Hello Sergey,

  the change looks fine to me.

Thanks,
Andrew.


On 12/12/2014 12:57 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> ----- philip.race at oracle.com wrote:
> >
> > Consistent treatment of concatenating sInverseTx seems right although
> > I am not sure of the overall picture here.
> >
> > Quartz uses "y increases upwards"
> > 
> https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202-CJBBAEEC
> >
> > 2d uses "y increases downwards"
> > https://docs.oracle.com/javase/tutorial/2d/overview/coordinate.html
> >
> > It seems like this transform
> > static CGAffineTransform sInverseTX = { 1, 0, 0, -1, 0, 0 };
> >
> > might have been to compensate to adjust into the quartz coordinate 
> system
>
> Right.
>
> > But I'd expect to see flipped text, not just incorrectly rotated 
> text, if
> > this were the problem, so I am far from sure about all of this
>
> The problem also in the fact that fFontTx is incorrectly translated, 
> it is set in SG2D.checkFontInfo(). And CTextPipeline use this 
> translation instead of fontinfo.originX/Y.
>
> >
> > -phil.
> >
> > *
> > *On 12/10/14 5:31 AM, Sergey Bylokhov wrote:
> >
>
>     Hello.
>     > Please review the fix for jdk 9/8u40.
>     > Device transformation "fDevTx ", which was added in [1] and
>     fFontTx contains different "directions".
>     > Both of them are used in calculation of advances, because of
>     that in some cases we get incorrect/opposite text rotation.
>     > Note that I am not sure that fFontTx itself is correct, because
>     it is used in printing, which is broken also since a beginning.
>     But for now I simply change the newly added fDevTx to fix a
>     regression.
>     >
>     > [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a8b9df782017
>     >
>     > Bug: https://bugs.openjdk.java.net/browse/JDK-8065373
>     > Webrev can be found at:
>     http://cr.openjdk.java.net/~serb/8065373/webrev.00
>     >
>     > 
>
>
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20141216/75350b2e/attachment.html>

From joe.darcy at oracle.com  Tue Dec 16 17:10:47 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 16 Dec 2014 09:10:47 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <54901450.1000309@oracle.com>
References: <548FCC05.4000907@oracle.com> <54901450.1000309@oracle.com>
Message-ID: <54906797.4090801@oracle.com>


On 12/16/2014 3:15 AM, Alan Bateman wrote:
> On 16/12/2014 06:07, joe darcy wrote:
>> Hello,
>>
>> Please review the next step of suppressing the deprecation warnings 
>> the client libraries, this time in windows-specific desktop code:
>>
>>     JDK-8067092: Suppress windows-specific deprecation warnings in 
>> the java.desktop module
>>     http://cr.openjdk.java.net/~darcy/8067092.0/
>>
>> Thanks,
> Lots more getPeer :-)
>
> The change looks okay to me and the same techniques to reduce these as 
> per the other thread.
>

Yes, same techniques as before -- for each warning, add 
"@SuppressWarning("deprecation")" to the enclosing method (or to the 
field for a field initializer expression). Some @SuppressWarning 
annotations cover multiple warning instances.

Thanks,

-Joe



From philip.race at oracle.com  Tue Dec 16 17:24:31 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 16 Dec 2014 09:24:31 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <54906797.4090801@oracle.com>
References: <548FCC05.4000907@oracle.com> <54901450.1000309@oracle.com>
	<54906797.4090801@oracle.com>
Message-ID: <54906ACF.5050508@oracle.com>

Approved.
We really need to figure out what to do about getPeer() - for this and 
for jigsaw ..

-phil.


On 12/16/2014 9:10 AM, joe darcy wrote:
>
> On 12/16/2014 3:15 AM, Alan Bateman wrote:
>> On 16/12/2014 06:07, joe darcy wrote:
>>> Hello,
>>>
>>> Please review the next step of suppressing the deprecation warnings 
>>> the client libraries, this time in windows-specific desktop code:
>>>
>>>     JDK-8067092: Suppress windows-specific deprecation warnings in 
>>> the java.desktop module
>>>     http://cr.openjdk.java.net/~darcy/8067092.0/
>>>
>>> Thanks,
>> Lots more getPeer :-)
>>
>> The change looks okay to me and the same techniques to reduce these 
>> as per the other thread.
>>
>
> Yes, same techniques as before -- for each warning, add 
> "@SuppressWarning("deprecation")" to the enclosing method (or to the 
> field for a field initializer expression). Some @SuppressWarning 
> annotations cover multiple warning instances.
>
> Thanks,
>
> -Joe
>



From joe.darcy at oracle.com  Tue Dec 16 18:01:36 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 16 Dec 2014 10:01:36 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <54906ACF.5050508@oracle.com>
References: <548FCC05.4000907@oracle.com> <54901450.1000309@oracle.com>
	<54906797.4090801@oracle.com> <54906ACF.5050508@oracle.com>
Message-ID: <54907380.1090306@oracle.com>

Thanks for the review.

Just one more fix to review to finish suppressing the deprecation 
warnings in the desktop module; please also see the review request for 
JDK-8067086: Suppress mac-specific deprecation warnings in the 
java.desktop module:

http://mail.openjdk.java.net/pipermail/2d-dev/2014-December/004992.html
http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008790.html

Thanks,

-Joe

On 12/16/2014 9:24 AM, Phil Race wrote:
> Approved.
> We really need to figure out what to do about getPeer() - for this and 
> for jigsaw ..
>
> -phil.
>
>
> On 12/16/2014 9:10 AM, joe darcy wrote:
>>
>> On 12/16/2014 3:15 AM, Alan Bateman wrote:
>>> On 16/12/2014 06:07, joe darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the next step of suppressing the deprecation warnings 
>>>> the client libraries, this time in windows-specific desktop code:
>>>>
>>>>     JDK-8067092: Suppress windows-specific deprecation warnings in 
>>>> the java.desktop module
>>>>     http://cr.openjdk.java.net/~darcy/8067092.0/
>>>>
>>>> Thanks,
>>> Lots more getPeer :-)
>>>
>>> The change looks okay to me and the same techniques to reduce these 
>>> as per the other thread.
>>>
>>
>> Yes, same techniques as before -- for each warning, add 
>> "@SuppressWarning("deprecation")" to the enclosing method (or to the 
>> field for a field initializer expression). Some @SuppressWarning 
>> annotations cover multiple warning instances.
>>
>> Thanks,
>>
>> -Joe
>>
>



From philip.race at oracle.com  Tue Dec 16 18:05:22 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 16 Dec 2014 10:05:22 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067086: Suppress
 mac-specific deprecation warnings in the java.desktop module
In-Reply-To: <548FD5B7.5040703@oracle.com>
References: <548FD5B7.5040703@oracle.com>
Message-ID: <54907462.7060103@oracle.com>

Approved

-phil.

On 12/15/14 10:48 PM, joe darcy wrote:
> Hello,
>
> Please review this (hopefully) last change to suppress the deprecation 
> warnings in the java.desktop module:
>
>     8067086: Suppress mac-specific deprecation warnings in the 
> java.desktop module
>     http://cr.openjdk.java.net/~darcy/8067086.0/
>
> Thanks,
>
> -Joe



From james.graham at oracle.com  Tue Dec 16 18:24:46 2014
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 16 Dec 2014 10:24:46 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <54906ACF.5050508@oracle.com>
References: <548FCC05.4000907@oracle.com> <54901450.1000309@oracle.com>
	<54906797.4090801@oracle.com> <54906ACF.5050508@oracle.com>
Message-ID: <549078EE.3060001@oracle.com>

Stop using them and replace them with new package private methods and a 
cross-package accessor (similar to the SurfaceManager.ImageAccessor 
pattern)?  What are the technical constraints preventing this?

I think the getPeer() method used to be used by AWT applications to tell 
if an app was on the screen or not, but we can easily gut the method to 
just return any old non-null value when the peer exists (even just leave 
it returning the true peer as long as we aren't using it internally to 
get the peer).  Then we could independently decide if its legacy uses 
are no longer allowed and switch it to throwing an exception or 
returning null or uninteresting values as we see fit...

			...jim

On 12/16/14 9:24 AM, Phil Race wrote:
> Approved.
> We really need to figure out what to do about getPeer() - for this and
> for jigsaw ..
>
> -phil.
>
>
> On 12/16/2014 9:10 AM, joe darcy wrote:
>>
>> On 12/16/2014 3:15 AM, Alan Bateman wrote:
>>> On 16/12/2014 06:07, joe darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the next step of suppressing the deprecation warnings
>>>> the client libraries, this time in windows-specific desktop code:
>>>>
>>>>     JDK-8067092: Suppress windows-specific deprecation warnings in
>>>> the java.desktop module
>>>>     http://cr.openjdk.java.net/~darcy/8067092.0/
>>>>
>>>> Thanks,
>>> Lots more getPeer :-)
>>>
>>> The change looks okay to me and the same techniques to reduce these
>>> as per the other thread.
>>>
>>
>> Yes, same techniques as before -- for each warning, add
>> "@SuppressWarning("deprecation")" to the enclosing method (or to the
>> field for a field initializer expression). Some @SuppressWarning
>> annotations cover multiple warning instances.
>>
>> Thanks,
>>
>> -Joe
>>
>


From philip.race at oracle.com  Tue Dec 16 18:29:29 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 16 Dec 2014 10:29:29 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <549078EE.3060001@oracle.com>
References: <548FCC05.4000907@oracle.com> <54901450.1000309@oracle.com>
	<54906797.4090801@oracle.com> <54906ACF.5050508@oracle.com>
	<549078EE.3060001@oracle.com>
Message-ID: <54907A09.1080201@oracle.com>

Yes .. no technical constraint there.
Although I was pondering going further and seeing if we can actually remove
the public method java.awt.peer.Peer Component.getPeer()
since with the module system the peer package is not accessible and this
is then even  weirder than it is now .. as it effectively documents a 
package
we don't document (any more) and you can't use in JDK 9.

-phil.

On 12/16/14 10:24 AM, Jim Graham wrote:
> Stop using them and replace them with new package private methods and 
> a cross-package accessor (similar to the SurfaceManager.ImageAccessor 
> pattern)?  What are the technical constraints preventing this?
>
> I think the getPeer() method used to be used by AWT applications to 
> tell if an app was on the screen or not, but we can easily gut the 
> method to just return any old non-null value when the peer exists 
> (even just leave it returning the true peer as long as we aren't using 
> it internally to get the peer).  Then we could independently decide if 
> its legacy uses are no longer allowed and switch it to throwing an 
> exception or returning null or uninteresting values as we see fit...
>
>             ...jim
>
> On 12/16/14 9:24 AM, Phil Race wrote:
>> Approved.
>> We really need to figure out what to do about getPeer() - for this and
>> for jigsaw ..
>>
>> -phil.
>>
>>
>> On 12/16/2014 9:10 AM, joe darcy wrote:
>>>
>>> On 12/16/2014 3:15 AM, Alan Bateman wrote:
>>>> On 16/12/2014 06:07, joe darcy wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the next step of suppressing the deprecation warnings
>>>>> the client libraries, this time in windows-specific desktop code:
>>>>>
>>>>>     JDK-8067092: Suppress windows-specific deprecation warnings in
>>>>> the java.desktop module
>>>>>     http://cr.openjdk.java.net/~darcy/8067092.0/
>>>>>
>>>>> Thanks,
>>>> Lots more getPeer :-)
>>>>
>>>> The change looks okay to me and the same techniques to reduce these
>>>> as per the other thread.
>>>>
>>>
>>> Yes, same techniques as before -- for each warning, add
>>> "@SuppressWarning("deprecation")" to the enclosing method (or to the
>>> field for a field initializer expression). Some @SuppressWarning
>>> annotations cover multiple warning instances.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>



From Alan.Bateman at oracle.com  Tue Dec 16 21:25:23 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Dec 2014 21:25:23 +0000
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress
 windows-specific deprecation warnings in the java.desktop module
In-Reply-To: <54907A09.1080201@oracle.com>
References: <548FCC05.4000907@oracle.com> <54901450.1000309@oracle.com>
	<54906797.4090801@oracle.com> <54906ACF.5050508@oracle.com>
	<549078EE.3060001@oracle.com> <54907A09.1080201@oracle.com>
Message-ID: <5490A343.2040208@oracle.com>

On 16/12/2014 18:29, Phil Race wrote:
> Yes .. no technical constraint there.
> Although I was pondering going further and seeing if we can actually 
> remove
> the public method java.awt.peer.Peer Component.getPeer()
> since with the module system the peer package is not accessible and this
> is then even  weirder than it is now .. as it effectively documents a 
> package
> we don't document (any more) and you can't use in JDK 9.
I think removing the Component::getPeer method is the right thing to do, 
it would not otherwise be possible to compile or run code that makes 
direct use of it.

-Alan


From adinn at redhat.com  Fri Dec 19 11:08:36 2014
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 19 Dec 2014 11:08:36 +0000
Subject: [OpenJDK 2D-Dev] What is the point of CloseTTFontFileFunc?
Message-ID: <54940734.5090401@redhat.com>

Hi All,

I am looking at a problem Red Hat customers have reported with True Type
fonts where they are seeing a Hotspot crash using JDK7. the problem
relates to the use of TT font scalers and, in particular to code called
under native methods initNativeScaler and disposeNativeScaler of class
sun.font.FreetypeFontScaler.

While investigating this I looked at the stream close function
CloseTTFontFileFunc provided for the scaler in freetypeScaler.c and was
rather confused as to what it was supposed to achieve. n.b. the code
below from the release version of Icedtea7 which caused the problem
appears still to exist unchanged in the latest jdk7u, jdk8u and jdk9).

/* NB: is it ever called? */
static void CloseTTFontFileFunc(FT_Stream stream) {
    FTScalerInfo *scalerInfo = (FTScalerInfo *) stream->pathname.pointer;
    JNIEnv* env = scalerInfo->env;
    jclass tmpClass = (*env)->FindClass(env, "sun/font/TrueTypeFont");
    jfieldID platNameField =
         (*env)->GetFieldID(env, tmpClass, "platName",
"Ljava/lang/String;");
    jstring platName = (*env)->GetObjectField(env,
                                              scalerInfo->font2D,
                                              platNameField);
    const char *name = JNU_GetStringPlatformChars(env, platName, NULL);
    JNU_ReleaseStringPlatformChars(env, platName, name);
}

Is there any point in calling JNU_GetStringPlatformChars and then
JNU_ReleaseStringPlatformChars? This appears simply to malloc a copy of
the platname string, albeit perhaps with some multibyte chars replaced
with '?', and then to immediately free the allocated string. Is there
any good reason for this?

regards,


Andrew Dinn
-----------



From neugens at redhat.com  Fri Dec 19 16:33:38 2014
From: neugens at redhat.com (Mario Torre)
Date: Fri, 19 Dec 2014 17:33:38 +0100
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <548B3CA2.3070503@oracle.com>
References: <1415378167.7443.1.camel@nirvana.localdomain>
	<5488D8FC.2030700@oracle.com>
	<1418407228.25551.8.camel@nirvana.localdomain>
	<548B2FC2.2080201@oracle.com>
	<1418408157.25551.10.camel@nirvana.localdomain>
	<548B3CA2.3070503@oracle.com>
Message-ID: <1419006818.4115.8.camel@nirvana.localdomain>

On Fri, 2014-12-12 at 11:06 -0800, Phil Race wrote:
> Correct. jtreg doesn't like System.exit() but I also understand that shell
> tests are now highly frowned upon.
> So either
> 1) Run using "othervm" where calling System.exit() should be fine - I 
> think !?
> 2) Don't worry about it, assuming jtreg can clean up if needed. If it can't
> halt the test threads then that seems to be a different problem that I'd
> expect occurs in many tests.

Looks like jtreg knows what to do. I'm still running in othervm but it
looks like the tests are now behaving correctly:

http://cr.openjdk.java.net/~neugens/8067364/webrev.01/

I still need a second reviewer then I can proceed.

Cheers,
Mario



From andrew.brygin at oracle.com  Sun Dec 21 23:35:44 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Sun, 21 Dec 2014 15:35:44 -0800 (PST)
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
Message-ID: <eb11ddad-8336-43c8-aebf-7a4ccd5b850b@default>

Hello Mario,

 the change looks fine to me.

Thanks,
Andrew

----- Original Message -----
From: neugens at redhat.com
To: philip.race at oracle.com
Cc: 2d-dev at openjdk.java.net
Sent: Friday, December 19, 2014 7:34:06 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis

On Fri, 2014-12-12 at 11:06 -0800, Phil Race wrote:
> Correct. jtreg doesn't like System.exit() but I also understand that shell
> tests are now highly frowned upon.
> So either
> 1) Run using "othervm" where calling System.exit() should be fine - I 
> think !?
> 2) Don't worry about it, assuming jtreg can clean up if needed. If it can't
> halt the test threads then that seems to be a different problem that I'd
> expect occurs in many tests.

Looks like jtreg knows what to do. I'm still running in othervm but it
looks like the tests are now behaving correctly:

http://cr.openjdk.java.net/~neugens/8067364/webrev.01/

I still need a second reviewer then I can proceed.

Cheers,
Mario



From Sergey.Bylokhov at oracle.com  Tue Dec 23 19:10:54 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 Dec 2014 22:10:54 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup
 uses family+style, not full name/postscript name
In-Reply-To: <548F4279.5040002@oracle.com>
References: <548F4279.5040002@oracle.com>
Message-ID: <5499BE3E.4060808@oracle.com>

Hi, Phil.
Probably it is possible to move the new code in CFontManager.loadFonts() 
to the SunFontManager.loadFonts()?
Note that in the test the text "Big italic red text" should be ..."black 
text", and the window should be disposed at the end of the test. Why 
this test is mac specific?

On 15.12.2014 23:20, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8064833
> http://cr.openjdk.java.net/~prr/8064833/
>
> OS X font look up is using family name + style - even when using 
> deriveFont
> from a specific font. Since the family name like "Helvetica" is 
> insufficient to
> convey that you are using the "Helvetica Light" subfamily and we get the
> wronf font.
> The provided test shows that the results can be completely garbage 
> rendering.
>
> Some clean up included here is remove the unconditional define of 
> DEBUG and
> the native 'isFakeItalic' variable which was not used anywhere.
>
> -phil.


-- 
Best regards, Sergey.



From philip.race at oracle.com  Tue Dec 23 21:30:35 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 23 Dec 2014 13:30:35 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup
 uses family+style, not full name/postscript name
In-Reply-To: <5499BE3E.4060808@oracle.com>
References: <548F4279.5040002@oracle.com> <5499BE3E.4060808@oracle.com>
Message-ID: <5499DEFB.3070808@oracle.com>

On 12/23/2014 11:10 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> Probably it is possible to move the new code in 
> CFontManager.loadFonts() to the SunFontManager.loadFonts()?

No .. its completely mac-specific.

> Note that in the test the text "Big italic red text" should be 
> ..."black text", 

that was taken from the original bug.

> and the window should be disposed at the end of the test.

I can update the test before I push.

 > Why this test is mac specific?

Because the whole problem is mac-specific and you can't find the situation
with the fonts that cause this problem elsewhere. Its really iffy to 
test at all ..
Note that I am using glyphcodes, which means you have to know exactly
what font you have.

-phil.

>
> On 15.12.2014 23:20, Phil Race wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8064833
>> http://cr.openjdk.java.net/~prr/8064833/
>>
>> OS X font look up is using family name + style - even when using 
>> deriveFont
>> from a specific font. Since the family name like "Helvetica" is 
>> insufficient to
>> convey that you are using the "Helvetica Light" subfamily and we get the
>> wronf font.
>> The provided test shows that the results can be completely garbage 
>> rendering.
>>
>> Some clean up included here is remove the unconditional define of 
>> DEBUG and
>> the native 'isFakeItalic' variable which was not used anywhere.
>>
>> -phil.
>
>



From Sergey.Bylokhov at oracle.com  Wed Dec 24 08:22:50 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 24 Dec 2014 11:22:50 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup
 uses family+style, not full name/postscript name
In-Reply-To: <5499DEFB.3070808@oracle.com>
References: <548F4279.5040002@oracle.com> <5499BE3E.4060808@oracle.com>
	<5499DEFB.3070808@oracle.com>
Message-ID: <549A77DA.1080202@oracle.com>

Hi, Phil.
On 24.12.2014 0:30, Phil Race wrote:
> Because the whole problem is mac-specific and you can't find the 
> situation
> with the fonts that cause this problem elsewhere. Its really iffy to 
> test at all ..
> Note that I am using glyphcodes, which means you have to know exactly
> what font you have.
I just install "Helvetica Light Oblique" on my windows os and the test 
produces partially correct string. 0x03 code is " instead of simple 
space. Is that expected?
>
> -phil.
>
>>
>> On 15.12.2014 23:20, Phil Race wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8064833
>>> http://cr.openjdk.java.net/~prr/8064833/
>>>
>>> OS X font look up is using family name + style - even when using 
>>> deriveFont
>>> from a specific font. Since the family name like "Helvetica" is 
>>> insufficient to
>>> convey that you are using the "Helvetica Light" subfamily and we get 
>>> the
>>> wronf font.
>>> The provided test shows that the results can be completely garbage 
>>> rendering.
>>>
>>> Some clean up included here is remove the unconditional define of 
>>> DEBUG and
>>> the native 'isFakeItalic' variable which was not used anywhere.
>>>
>>> -phil.
>>
>>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Wed Dec 24 15:31:21 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 24 Dec 2014 07:31:21 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup
 uses family+style, not full name/postscript name
In-Reply-To: <549A77DA.1080202@oracle.com>
References: <548F4279.5040002@oracle.com> <5499BE3E.4060808@oracle.com>
	<5499DEFB.3070808@oracle.com> <549A77DA.1080202@oracle.com>
Message-ID: <549ADC49.8020004@oracle.com>

On 12/24/14 12:22 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> On 24.12.2014 0:30, Phil Race wrote:
>> Because the whole problem is mac-specific and you can't find the 
>> situation
>> with the fonts that cause this problem elsewhere. Its really iffy to 
>> test at all ..
>> Note that I am using glyphcodes, which means you have to know exactly
>> what font you have.
> I just install "Helvetica Light Oblique" on my windows os and the test 
> produces partially correct string. 0x03 code is " instead of simple 
> space. Is that expected?

That's what I mean by the test being iffy. Its got to be the same font.
Its either that or simply don't provide a test at all.
Where (exactly - ie in every last detail) did you get this font ?
IIRC on OS X it was in a dfont .. and that would not be very useful on 
windows.

-phil.

>>
>> -phil.
>>
>>>
>>> On 15.12.2014 23:20, Phil Race wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8064833
>>>> http://cr.openjdk.java.net/~prr/8064833/
>>>>
>>>> OS X font look up is using family name + style - even when using 
>>>> deriveFont
>>>> from a specific font. Since the family name like "Helvetica" is 
>>>> insufficient to
>>>> convey that you are using the "Helvetica Light" subfamily and we 
>>>> get the
>>>> wronf font.
>>>> The provided test shows that the results can be completely garbage 
>>>> rendering.
>>>>
>>>> Some clean up included here is remove the unconditional define of 
>>>> DEBUG and
>>>> the native 'isFakeItalic' variable which was not used anywhere.
>>>>
>>>> -phil.
>>>
>>>
>>
>
>



From neugens.limasoftware at gmail.com  Sun Dec 28 16:31:37 2014
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Sun, 28 Dec 2014 17:31:37 +0100
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <eb11ddad-8336-43c8-aebf-7a4ccd5b850b@default>
References: <eb11ddad-8336-43c8-aebf-7a4ccd5b850b@default>
Message-ID: <CAGUMyaS_Q9AETvh4B_+Ex-03SFdNCrxc0bYz6HX53OCUSNaGdA@mail.gmail.com>

Thanks!

I'm about to push the fix with this commit message:

8067364: Printing to Postscript doesn't support dieresis
Summary: Fix regression caused by fix for 8023990
Reviewed-by: bae, prr
Contributed-by: neugens at redhat.com, philip.race at oracle.com

I added the Contributed-by tag because I only contributed the test and
did some initial assessment, the actual patch was from Phil, not sure
if this is correct though, doesn't seem to be the intended use for
this tag (We had a discussion on this sort of things some time ago,
but I can't find the mail exchanges in the archives).

Cheers,
Mario

2014-12-22 0:35 GMT+01:00 Andrew Brygin <andrew.brygin at oracle.com>:
> Hello Mario,
>
>  the change looks fine to me.
>
> Thanks,
> Andrew
>
> ----- Original Message -----
> From: neugens at redhat.com
> To: philip.race at oracle.com
> Cc: 2d-dev at openjdk.java.net
> Sent: Friday, December 19, 2014 7:34:06 PM GMT +04:00 Abu Dhabi / Muscat
> Subject: Re: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
>
> On Fri, 2014-12-12 at 11:06 -0800, Phil Race wrote:
>> Correct. jtreg doesn't like System.exit() but I also understand that shell
>> tests are now highly frowned upon.
>> So either
>> 1) Run using "othervm" where calling System.exit() should be fine - I
>> think !?
>> 2) Don't worry about it, assuming jtreg can clean up if needed. If it can't
>> halt the test threads then that seems to be a different problem that I'd
>> expect occurs in many tests.
>
> Looks like jtreg knows what to do. I'm still running in othervm but it
> looks like the tests are now behaving correctly:
>
> http://cr.openjdk.java.net/~neugens/8067364/webrev.01/
>
> I still need a second reviewer then I can proceed.
>
> Cheers,
> Mario
>



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From adinn at redhat.com  Mon Dec 29 11:03:57 2014
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 29 Dec 2014 11:03:57 +0000
Subject: [OpenJDK 2D-Dev] What is the point of CloseTTFontFileFunc?
In-Reply-To: <54940734.5090401@redhat.com>
References: <54940734.5090401@redhat.com>
Message-ID: <54A1351D.9090108@redhat.com>

Hi again,

Trying a second time . . . anyone have an answer to this question?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

On 19/12/14 11:08, Andrew Dinn wrote:
> Hi All,
> 
> I am looking at a problem Red Hat customers have reported with True Type
> fonts where they are seeing a Hotspot crash using JDK7. the problem
> relates to the use of TT font scalers and, in particular to code called
> under native methods initNativeScaler and disposeNativeScaler of class
> sun.font.FreetypeFontScaler.
> 
> While investigating this I looked at the stream close function
> CloseTTFontFileFunc provided for the scaler in freetypeScaler.c and was
> rather confused as to what it was supposed to achieve. n.b. the code
> below from the release version of Icedtea7 which caused the problem
> appears still to exist unchanged in the latest jdk7u, jdk8u and jdk9).
> 
> /* NB: is it ever called? */
> static void CloseTTFontFileFunc(FT_Stream stream) {
>     FTScalerInfo *scalerInfo = (FTScalerInfo *) stream->pathname.pointer;
>     JNIEnv* env = scalerInfo->env;
>     jclass tmpClass = (*env)->FindClass(env, "sun/font/TrueTypeFont");
>     jfieldID platNameField =
>          (*env)->GetFieldID(env, tmpClass, "platName",
> "Ljava/lang/String;");
>     jstring platName = (*env)->GetObjectField(env,
>                                               scalerInfo->font2D,
>                                               platNameField);
>     const char *name = JNU_GetStringPlatformChars(env, platName, NULL);
>     JNU_ReleaseStringPlatformChars(env, platName, name);
> }
> 
> Is there any point in calling JNU_GetStringPlatformChars and then
> JNU_ReleaseStringPlatformChars? This appears simply to malloc a copy of
> the platname string, albeit perhaps with some multibyte chars replaced
> with '?', and then to immediately free the allocated string. Is there
> any good reason for this?
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 
> 
> 


From Sergey.Bylokhov at oracle.com  Mon Dec 29 11:11:22 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 29 Dec 2014 14:11:22 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup
 uses family+style, not full name/postscript name
In-Reply-To: <5499DEFB.3070808@oracle.com>
References: <548F4279.5040002@oracle.com> <5499BE3E.4060808@oracle.com>
	<5499DEFB.3070808@oracle.com>
Message-ID: <54A136DA.2070009@oracle.com>

Hi, Phil.
The fix looks fine. Note that necessary tags are absent in the test 
(@test etc).

On 24.12.2014 0:30, Phil Race wrote:
> On 12/23/2014 11:10 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> Probably it is possible to move the new code in 
>> CFontManager.loadFonts() to the SunFontManager.loadFonts()?
>
> No .. its completely mac-specific.
>
>> Note that in the test the text "Big italic red text" should be 
>> ..."black text", 
>
> that was taken from the original bug.
>
>> and the window should be disposed at the end of the test.
>
> I can update the test before I push.
>
> > Why this test is mac specific?
>
> Because the whole problem is mac-specific and you can't find the 
> situation
> with the fonts that cause this problem elsewhere. Its really iffy to 
> test at all ..
> Note that I am using glyphcodes, which means you have to know exactly
> what font you have.
>
> -phil.
>
>>
>> On 15.12.2014 23:20, Phil Race wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8064833
>>> http://cr.openjdk.java.net/~prr/8064833/
>>>
>>> OS X font look up is using family name + style - even when using 
>>> deriveFont
>>> from a specific font. Since the family name like "Helvetica" is 
>>> insufficient to
>>> convey that you are using the "Helvetica Light" subfamily and we get 
>>> the
>>> wronf font.
>>> The provided test shows that the results can be completely garbage 
>>> rendering.
>>>
>>> Some clean up included here is remove the unconditional define of 
>>> DEBUG and
>>> the native 'isFakeItalic' variable which was not used anywhere.
>>>
>>> -phil.
>>
>>
>


-- 
Best regards, Sergey.



From andrew.brygin at oracle.com  Wed Dec 31 08:41:36 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Wed, 31 Dec 2014 11:41:36 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup
 uses family+style, not full name/postscript name
In-Reply-To: <548F4279.5040002@oracle.com>
References: <548F4279.5040002@oracle.com>
Message-ID: <54A3B6C0.7070600@oracle.com>

Hello Phil,

  could you please clarify why do we need to register italic variant twice:
  CFontManager.java:

  280                registerGenericFont(plain.createItalicVariant(), true);
  281                CFont f = plain.createItalicVariant();
  282                registerGenericFont(f, true);

the same thing is done for bold font on lines 285 - 287.

Thanks,
Andrew

On 12/15/2014 11:20 PM, Phil Race wrote:

> https://bugs.openjdk.java.net/browse/JDK-8064833
> http://cr.openjdk.java.net/~prr/8064833/
>
> OS X font look up is using family name + style - even when using 
> deriveFont
> from a specific font. Since the family name like "Helvetica" is 
> insufficient to
> convey that you are using the "Helvetica Light" subfamily and we get the
> wronf font.
> The provided test shows that the results can be completely garbage 
> rendering.
>
> Some clean up included here is remove the unconditional define of 
> DEBUG and
> the native 'isFakeItalic' variable which was not used anywhere.
>
> -phil.