From krueger at lesspain.de  Sun Dec  1 05:54:32 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sun, 1 Dec 2013 14:54:32 +0100
Subject: How to know, whether HiDPI is supported?
In-Reply-To: <52CAC6A8CE5503408F3482C89035832809C5F772@OC11EXPO27.exchange.mit.edu>
References: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>
	<52CAC6A8CE5503408F3482C89035832809C57BC4@OC11EXPO27.exchange.mit.edu>
	<CAEnqZEW8ck9-PRfUebPHgddEwibEEpZPT5i2uUdvLNvoBmfwDw@mail.gmail.com>
	<52CAC6A8CE5503408F3482C89035832809C5F772@OC11EXPO27.exchange.mit.edu>
Message-ID: <CAEnqZEXnZ+6P1es8mdTtPZ==G3tSV6a5M8C_SohecB_ucMZ_vA@mail.gmail.com>

Yes, that's what I mean. On my Macbook Pro I can choose out of five
settings if I choose "scaled" rather than "best for retina display"
and I, for example, use the "more space" setting to have a maximum
resolution in terms of pixels and I doubt this is 2.0, so your check
would probably fail although it would make sense to use the
higher-resolution graphics on my Macbook with that setting. I would
probably just treat anything thats > 1.0 as HiDPI.

Robert

On Sat, Nov 30, 2013 at 8:09 PM, Eirik Bakke <ebakke at mit.edu> wrote:
> Quite possible--do you mean if the scale factor is not exactly 1.0 or 2.0?
> In that case, yes, you should need to get the actual scale factor from the
> AffineTransform. But I'm unsure how often scale factors other than 1.0 or
> 2.0 are encountered (surely there can't be more than two sets of icons for
> every app... unless everyone provides bitmap for the low resolution and
> SVG for the higher ones).
>
> I should add that I have only tested the Retina mode using the "Enable
> HiDPI display modes" option from the Graphics Tools for XCode [1]. And
> that one only lets me try 2x scale factors.
>
> -- Eirik
>
> [1]
> http://stackoverflow.com/questions/12124576/how-to-simulate-a-retina-displa
> y-hidpi-mode-in-mac-os-x-10-8-mountain-lion-on
>
> -- Eirik
>
> On 11/30/13, 7:04 AM, "Robert Kr?ger" <krueger at lesspain.de> wrote:
>
>>Don't the scale factors depend on the individual user's retina
>>settings? Of course, your approach will also work if that is the case,
>>it will just require some more checks.
>>
>>On Fri, Nov 29, 2013 at 11:26 PM, Eirik Bakke <ebakke at mit.edu> wrote:
>>> This did the trick for me:
>>>
>>> // g is the Graphics2D object fed to the paint() or paintComponent()
>>> method of your Swing component.
>>>
>>>g.getFontRenderContext().getTransform().equals(AffineTransform.getScaleIn
>>>st
>>> ance(2.0, 2.0))
>>>
>>>
>>> It uses no private APIs, and has the advantage that it lets you make the
>>> retina-or-not decision on a component-to-component basis (or in
>>>practice,
>>> on a window-to-window basis, as all components in the same window have
>>>the
>>> same FontRenderContext). This means if your user has one window on their
>>> retina laptop screen and another on their non-retina external monitor,
>>> both will render appropriately for their respective devices (I've
>>> confirmed this to work on Java 1.7.0_45 for MacOS X 10.8.5).
>>>
>>> -- Eirik
>>>
>>> On 11/29/13, 7:36 AM, "Hendrik Schreiber" <hs at tagtraum.com> wrote:
>>>
>>>>Hey..
>>>>
>>>>with some of the Retina work appearing in 1.7.0_60, what is the
>>>>recommended way for the developer to find out, whether images are/can be
>>>>scaled, i.e., whether we are dealing with a HiDPI display.
>>>>
>>>>In the past, on the Apple JVM, we used:
>>>>
>>>>       final Float scaleFactor = (Float)
>>>>Toolkit.getDefaultToolkit().getDesktopProperty("apple.awt.contentScaleFa
>>>>ct
>>>>or");
>>>>
>>>>Is there an equivalent?
>>>>
>>>>I very much appreciate that you are pushing some of the work down to
>>>>1.7.0_60. Can you say what parts should now/soon work and how to use
>>>>them?
>>>>
>>>>Thank you,
>>>>
>>>>-hendrik
>>>
>

From ebakke at MIT.EDU  Sun Dec  1 10:45:54 2013
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Sun, 1 Dec 2013 18:45:54 +0000
Subject: How to know, whether HiDPI is supported?
In-Reply-To: <CAEnqZEXnZ+6P1es8mdTtPZ==G3tSV6a5M8C_SohecB_ucMZ_vA@mail.gmail.com>
References: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>
	<52CAC6A8CE5503408F3482C89035832809C57BC4@OC11EXPO27.exchange.mit.edu>
	<CAEnqZEW8ck9-PRfUebPHgddEwibEEpZPT5i2uUdvLNvoBmfwDw@mail.gmail.com>
	<52CAC6A8CE5503408F3482C89035832809C5F772@OC11EXPO27.exchange.mit.edu>
	<CAEnqZEXnZ+6P1es8mdTtPZ==G3tSV6a5M8C_SohecB_ucMZ_vA@mail.gmail.com>
Message-ID: <52CAC6A8CE5503408F3482C89035832809C65C00@OC11EXPO27.exchange.mit.edu>

Ah, I see.

> I would probably just treat anything thats > 1.0 as HiDPI.

Good call, at least for the purposes of selecting icons/bitmap graphics.
(In my case I have an app that generates some graphics which it tries to
align to pixel boundaries. So in retina mode it aligns to "half-pixels"
instead of pixels. I'll have to see if it's worth trying to align to
pixels on more general scale factors, or whether I should just not try to
do any alignment at all on the odd HiDPI modes...)


-- Eirik

On 12/1/13, 8:54 AM, "Robert Kr?ger" <krueger at lesspain.de> wrote:

>Yes, that's what I mean. On my Macbook Pro I can choose out of five
>settings if I choose "scaled" rather than "best for retina display"
>and I, for example, use the "more space" setting to have a maximum
>resolution in terms of pixels and I doubt this is 2.0, so your check
>would probably fail although it would make sense to use the
>higher-resolution graphics on my Macbook with that setting. I would
>probably just treat anything thats > 1.0 as HiDPI.
>
>Robert
>
>On Sat, Nov 30, 2013 at 8:09 PM, Eirik Bakke <ebakke at mit.edu> wrote:
>> Quite possible--do you mean if the scale factor is not exactly 1.0 or
>>2.0?
>> In that case, yes, you should need to get the actual scale factor from
>>the
>> AffineTransform. But I'm unsure how often scale factors other than 1.0
>>or
>> 2.0 are encountered (surely there can't be more than two sets of icons
>>for
>> every app... unless everyone provides bitmap for the low resolution and
>> SVG for the higher ones).
>>
>> I should add that I have only tested the Retina mode using the "Enable
>> HiDPI display modes" option from the Graphics Tools for XCode [1]. And
>> that one only lets me try 2x scale factors.
>>
>> -- Eirik
>>
>> [1]
>> 
>>http://stackoverflow.com/questions/12124576/how-to-simulate-a-retina-disp
>>la
>> y-hidpi-mode-in-mac-os-x-10-8-mountain-lion-on
>>
>> -- Eirik
>>
>> On 11/30/13, 7:04 AM, "Robert Kr?ger" <krueger at lesspain.de> wrote:
>>
>>>Don't the scale factors depend on the individual user's retina
>>>settings? Of course, your approach will also work if that is the case,
>>>it will just require some more checks.
>>>
>>>On Fri, Nov 29, 2013 at 11:26 PM, Eirik Bakke <ebakke at mit.edu> wrote:
>>>> This did the trick for me:
>>>>
>>>> // g is the Graphics2D object fed to the paint() or paintComponent()
>>>> method of your Swing component.
>>>>
>>>>g.getFontRenderContext().getTransform().equals(AffineTransform.getScale
>>>>In
>>>>st
>>>> ance(2.0, 2.0))
>>>>
>>>>
>>>> It uses no private APIs, and has the advantage that it lets you make
>>>>the
>>>> retina-or-not decision on a component-to-component basis (or in
>>>>practice,
>>>> on a window-to-window basis, as all components in the same window have
>>>>the
>>>> same FontRenderContext). This means if your user has one window on
>>>>their
>>>> retina laptop screen and another on their non-retina external monitor,
>>>> both will render appropriately for their respective devices (I've
>>>> confirmed this to work on Java 1.7.0_45 for MacOS X 10.8.5).
>>>>
>>>> -- Eirik
>>>>
>>>> On 11/29/13, 7:36 AM, "Hendrik Schreiber" <hs at tagtraum.com> wrote:
>>>>
>>>>>Hey..
>>>>>
>>>>>with some of the Retina work appearing in 1.7.0_60, what is the
>>>>>recommended way for the developer to find out, whether images are/can
>>>>>be
>>>>>scaled, i.e., whether we are dealing with a HiDPI display.
>>>>>
>>>>>In the past, on the Apple JVM, we used:
>>>>>
>>>>>       final Float scaleFactor = (Float)
>>>>>Toolkit.getDefaultToolkit().getDesktopProperty("apple.awt.contentScale
>>>>>Fa
>>>>>ct
>>>>>or");
>>>>>
>>>>>Is there an equivalent?
>>>>>
>>>>>I very much appreciate that you are pushing some of the work down to
>>>>>1.7.0_60. Can you say what parts should now/soon work and how to use
>>>>>them?
>>>>>
>>>>>Thank you,
>>>>>
>>>>>-hendrik
>>>>
>>


From alexandr.scherbatiy at oracle.com  Mon Dec  2 04:55:02 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 02 Dec 2013 16:55:02 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <529922DD.7020605@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
	<52967E74.4030205@oracle.com> <52975719.4050502@oracle.com>
	<529922DD.7020605@oracle.com>
Message-ID: <529C8326.7020401@oracle.com>


   Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8011059/webrev.12/
     - Image observers are not cached now for the resolution variants
     - base image width and height are checked in the wrapped image observer

On 11/30/2013 3:27 AM, Jim Graham wrote:
> Hi Alexander,
>
> I suppose the wrapping solution works for ImageObservers, but I think 
> the suggestion I gave in recent emails was to simply modify the 
> newInfo method (and a couple of other methods) to deliver the same 
> information with no caches, no hashmaps/lookups, no wrapping the 
> observer, and no wrapping with soft references.  Keep in mind that 
> observers are typically references to Component objects so any delay 
> in processing the soft references could keep relatively large 
> component hierarchies in play (if they are parents).  It should work 
> well for a first draft, though.
     It seems that just updating the newInfo method is not enough.
     The resolution variant can have a reference to the base image. 
Loading the base image it still should compare its result with the 
resolution variant loading.
     So the image loading status is just moved from the SunToolkit to 
the ToolkitImage.
     I think that the current fix for the checkImage/prepareImage in the 
SunToolkit is the simplest  for the current implementation.
     The separate fix for the ToolkitImage/ImageRepresentation can get 
all things right.
>
> Also, why does ObserverCache exist?  Couldn't the cache just be a 
> static field on MRToolkitImage?
      MRToolkitImage can be used in drawImage(Image,..,ImageObserver) 
method always with null observer. So the is no need to create the 
observer cache or use a synchronization during the cache initialization.

>
> The current way of baking in the image dimensions assumes that they 
> are known.  If the image is loaded asynchronously, then the calls to 
> getWidth/Height(null) may return -1 and the cached observer wrapper 
> has no way to get them later.  I would think this would fail in the 
> typical default scenario where the user gets an image and the first 
> even that triggers loading it is to render to the screen which would 
> bake the -1's into the observer wrapper in all of those cases.  This 
> should probably be addressed sooner rather than later.
     I added the base image width/height check to the observer wrapper. 
However, there is no way to rescale image representation width and 
height in case if the base image width and height are not known.

>
> If an @2x image gets an error we silently start using just the regular 
> version of the image.  In addition MediaTracker should not reflect 
> that error in its answers, but I think it currently does since you add 
> it as an implicit extra media with the same ID.  I think this is OK 
> for the first pass, but we need to track it as an issue.
>
> I saw that you fixed the toolkit versions of check/prepare image. 
> Component also has the same operations (via its peers).  The Component 
> versions do back off to the toolkit versions, but only if they fail to 
> find an actual peer to delegate to.  Note that MediaTracker uses the 
> Component versions so it is affected by this, but I don't think it 
> will cause functional problems that I can think of.  Eventually we'd 
> want MT to only load the version that is appropriate for the indicated 
> Component - and at that point then this might be an issue, but I don't 
> think it is an issue for this first draft if it tracks both variations.
    I checked all peers like W/LW/XComponentPeer and toolkits.  They all 
delegate check/prepareImage calls to the default toolkit.

    Thanks,
    Alexandr.

> I think it is OK to send multiple notifications to an observer since 
> we've always been loose on the exact sequencing and the operations are 
> all asynchronous.  There could potentially be several notifications in 
> flight at the time that the observer indicates a lack of interest and 
> there is no way to stop them.  This could be considered "another case 
> of that".  Eventually we could consider addressing this with a tighter 
> integration between the wrapper mechanism and the code that calls 
> imageUpdate() and receives the answer that the observer is no longer 
> interested, but I think this is all OK for now.
>
> The only thing I think we should worry about now for this first draft 
> is the issue of getting the right dimensions for the observer 
> wrappers. They need to be more asynchronous about that. It already has 
> a handle on the original image anyway, so I think it just needs to get 
> the dimensions from there instead of passing them into the 
> constructor, with appropriate checks for -1's...
>
>             ...jim
>
> On 11/28/13 6:45 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.11/
>>
>>    I have moved new API supporting to the separate issue:
>>      JDK-8029339 Custom MultiResolution image support on HiDPI displays
>>        https://bugs.openjdk.java.net/browse/JDK-8029339
>>
>>     - SunToolkit.checkImage/updateImage are updated to handle
>> multi-resolution image
>>        Both base image and the resolution variant are loaded now.
>> However, in future, it would be useful to have an ability to load, for
>> example, only @2x image
>>        if the system has only Retina display on Mac OS X. So there are
>> can be problems with backward compatibility.
>>
>>    - MediaTracker is updated to handle multi-resolution image
>>       MediaTracker uses notifications both form the
>> Toolkit.prepareImage() method and image decoders. So only updating
>> Toolkit.prepareImage() is not enough.
>>
>>    - ImageObserver is wrapped both in drawImage() and
>> SunToolkit.prepareImage() methods. Size and coordinates are converted to
>> the base image.
>>      A user can receive several notifications about the complete image
>> loading from the original image and from the resolution variant.
>>      It can breaks his code if the code relies that only one
>> notification should be received.
>>
>>    - Resolution variant is ignored in case of errors in the drawImage()
>>       It needs to be decided on which step a user should be notified
>> that a resolution variant has error or this notification should be just
>> ignored.
>>
>>    - Test is updated
>>
>>    Icons and CustomCursor issues are handled by 8028212 and 8024926 bugs
>> and depend on the current bug implementation.
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 11/28/2013 3:21 AM, Jim Graham wrote:
>>> The things I was talking about in the quoted email were mostly future
>>> directions, but I did point out some issues in another email that
>>> should be addressed before FCS.  In particular:
>>>
>>> We do need to get the callbacks working whether they draw hi res or
>>> not.  I think the current fix delivers no notifications at all because
>>> the observer is not registered anywhere during the course of a
>>> drawImage().  That's a big bug.  I don't think we need to wrap
>>> observers to do that, there are only a few helper functions that
>>> deliver the notifications and they can be taught how to translate a
>>> resolution variant into the base image easily enough.
>>>
>>> You point out that there was no error checking for the hidpi image.  I
>>> agree.  Also, if the base image errors out, should we draw the @2x
>>> anyway?  Or should that base image be required? Minimally I think we
>>> need to not attempt the @2x for FCS if it errored and we can worry
>>> about how to respond to errors in the base image later.
>>>
>>> I think that com.sun would require CCC approval for a new interface
>>> and the bar is really high for API in 8.0 right now. Unless a
>>> developer really needs to use it it might be best to move the API to
>>> sun.*.  I didn't see any developers clamoring for it in the
>>> discussions I read, but let me know if I missed something.  If we get
>>> automatic use of @2x images then I think that satisfies the
>>> discussions I saw.
>>>
>>> MediaTracker defers to Component.prepareImage() for which variants
>>> should be loaded.  I think we need to teach prepareImage() to trigger
>>> the variant appropriate for the screen that the Component is on
>>> (perhaps the default screen if it isn't displayed yet).
>>>
>>> Also, there should probably be some MediaTracker, ImageIcon, and
>>> Cursor test cases that show that those mechanisms all work on images
>>> that have @2x variants.  Minimally they shouldn't fail entirely, and
>>> very desireably they should use the @2x version when appropriate, but
>>> that could be a follow on bug fix as long as they don't fail for the
>>> first fix.
>>>
>>> I've included below the quote from my last "review" email about the
>>> specific issues I found.  The main "blocking" issue right now is that
>>> it looks to me that no imageUpdate notifications at all happen for a
>>> hidpi image due to the ImageObserver getting dropped on the floor. Can
>>> we at least get imageUpdate() called with the base image, even if the
>>> xywh are wrong before we push the initial fix?  I hope my info below
>>> helps make that an easy task.
>>>
>>>> If they only ever use the image on a retina display (or some scaled
>>>> context) then I don't think we ever send any notifications the way
>>>> the current fix is written. Also, if you don't send notifications for
>>>> the scaled variant, but load the original and expect its
>>>> notifications to suffice, then we have a race condition - if the
>>>> original variant is fully constructed before the scaled version is
>>>> done then the final "OK to draw everything" notice would not happen
>>>> and they'd be left with a partial image.
>>>>
>>>> I think it should be easy to pass along the observer and simply have
>>>> ImageRep translate the image variant into the base image in its
>>>> newInfo method (and there are a couple of other locations that
>>>> imageUpdate is called that could do the same).  All it takes is
>>>> adding "ToolkitImage.set/getBaseImage()" to ToolkitImage, defaulting
>>>> to "this", but the Multi-Res image will set the base image on both of
>>>> its variants to the Multi-Res instance.
>>>>
>>>> Then we get full notices of all resolution variants.
>>>>
>>>> It would be best to scale the xywh supplied there as well. That
>>>> should be fairly easy, but if it is a big problem then that is lower
>>>> priority than getting the "ALLBITS" notification right, as that is
>>>> the main trigger for so many uses.
>>>>
>>>> (In the future we can add ImageObserver2 (or MultiResObserver?) which
>>>> has support for receiving notifications of variants without
>>>> translation.)
>>>
>>>
>>>             ...jim
>>>
>>> On 11/27/13 6:28 AM, Sergey Bylokhov wrote:
>>>> On 27.11.2013 15:12, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Probably we are in a point when it is necessary to stop and move out
>>>>> all extensions to the separate bugs.
>>>>> We should give a time to our sqe to test these changes.
>>>>> Actually current version looks good to me.
>>>> Small additional notes, It would be good:
>>>>   - to wrap initial observer in the drawImage and replace img/x,y,....
>>>> in the observer.
>>>>   - don't draw hidpi image, if it was loaded with errors.
>>>>   - sun.com package should be used?
>>>>   - If MediaTracker was requested to load MultiResolutionImage,it 
>>>> should
>>>> load all versions?
>>>>>
>>>>> On 26.11.2013 2:31, Jim Graham wrote:
>>>>>>
>>>>>>
>>>>>> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>>>>>>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>>>>>>> Hi Alexander,
>>>>>>>>
>>>>>>>> If we are going to be advertising it as something that developers
>>>>>>>> use
>>>>>>>> in production code then we would need to file this via CCC. 
>>>>>>>> With the
>>>>>>>> current implementation, any user that has their own ImageObservers
>>>>>>>> must use this API and so it becomes not only public, at a time 
>>>>>>>> when
>>>>>>>> there is a lockdown on new public API in 8.0, but it also means 
>>>>>>>> that
>>>>>>>> we are tied to its implementation and we can't rely on "it was
>>>>>>>> experimental and so we can change it at any point" - you can't say
>>>>>>>> that about an API that is necessary to correctly use a touted
>>>>>>>> feature.
>>>>>>>
>>>>>>>      This issue has its own history.  It has been already fixed
>>>>>>> for the
>>>>>>> JDK 7u for the Java2D demo. It was decided to not bring new API
>>>>>>> for the
>>>>>>> HiDPI support in the JDK 7.
>>>>>>>      It was suggested to using code like below to create a
>>>>>>> ScalableImage.
>>>>>>> ------------------------------
>>>>>>> /**
>>>>>>>   * Class that loads and returns images according to
>>>>>>>   * scale factor of graphic device
>>>>>>>   *
>>>>>>>   *  <pre> {@code
>>>>>>>   *    Image image = new ScalableImage() {
>>>>>>>   *
>>>>>>>   *        public Image createScaledImage(float scaleFactor) {
>>>>>>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>>>>>>   *                : loadImage("image at 2x.png");
>>>>>>>   *        }
>>>>>>>   *
>>>>>>>   *        Image loadImage(String name){
>>>>>>>   *            // load image
>>>>>>>   *        }
>>>>>>>   *    };}</pre>
>>>>>>>   */
>>>>>>> ------------------------------
>>>>>>>
>>>>>>>   It was based on the display scale factor. The scale factor
>>>>>>> should be
>>>>>>> manually retrieved from the Graphics2D and was not a part of the
>>>>>>> public
>>>>>>> API:
>>>>>>> g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>>>>>>
>>>>>>>   From that time it was clear that there should be 2 basic 
>>>>>>> operations
>>>>>>> for the HiDPI images support:
>>>>>>>    - retrieve an image with necessary resolution
>>>>>>>    - retrieve images with all resolutions
>>>>>>>
>>>>>>>    The second one is useful when it is necessary to create one 
>>>>>>> set of
>>>>>>> images using the given one (for example, to draw a shape on all
>>>>>>> images).
>>>>>>
>>>>>> For now, these are just ToolkitImages and you can't draw on them, so
>>>>>> this is moot for the case of @2x support in getImage().
>>>>>>
>>>>>>>    The JDK 7 solution has been revisited for the JDK 8 and the
>>>>>>> neccesary
>>>>>>> CCC request 8011059  has been created and approved.
>>>>>>>
>>>>>>>    Both the JDK-8011059 issue description and the approved CCC
>>>>>>> request
>>>>>>> says:
>>>>>>>    -----------------------
>>>>>>>    A user should have a unified way to provide high resolution 
>>>>>>> images
>>>>>>> that can be drawn on HIDPI displays according to the user provided
>>>>>>> algorithm.
>>>>>>>    -----------------------
>>>>>>
>>>>>> We've implemented the Hint part of that solution, but the mechanism
>>>>>> for creating custom multi-res images was not workable. I no longer
>>>>>> sit as the client rep on the CCC or I would have pointed that 
>>>>>> out, my
>>>>>> apologies.
>>>>>>
>>>>>>>    The 8011059 fix consists of two parts:
>>>>>>>    - Provide a way for a custom image creation that holds images 
>>>>>>> with
>>>>>>> different resolutions
>>>>>>>    - Load @2x images on Mac OS X
>>>>>>>
>>>>>>>    The first one of the fix can be used without the second. it 
>>>>>>> is not
>>>>>>> difficult to crate just a class which loads @2x images using the
>>>>>>> given
>>>>>>> file path/url.
>>>>>>
>>>>>> If we support @2x transparently behind the scenes as we are doing
>>>>>> now, who is the requester for the way to create a custom set of
>>>>>> resolution variants?  I think the most important customer-driven
>>>>>> request was to support @2x for the Mac developers, wasn't it?
>>>>>>
>>>>>>>    Now it is suggested to implement the given MultiResolutionImage
>>>>>>> interface  and override two methods:
>>>>>>>     - Image getResolutionVariant(int width, int height)
>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>
>>>>>>>     An image with necessary resolution should be drawn
>>>>>>> automatically in
>>>>>>> SunGraphics2D.
>>>>>>>
>>>>>>>    What we need is to focus on the first part of the fix.
>>>>>>>    From this point of view it up to the user' code to load all or
>>>>>>> some
>>>>>>> resolution variants by MediaTracker and using
>>>>>>> Component.prepareImage/checkImage methods.
>>>>>>
>>>>>> This is all an interesting goal, but I'm not sure it is as high a
>>>>>> priority if we support a convention (based on platform conventions)
>>>>>> for high resolution variants behind the scenes.  I do agree that we
>>>>>> need something like this before too long, but I don't think it was
>>>>>> workable to target the getScaledInstance() method as the 
>>>>>> mechanism to
>>>>>> implement it.  That was the only convention that was approved in 
>>>>>> that
>>>>>> CCC request, so a more complete API based on another mechanism is 
>>>>>> not
>>>>>> covered there.
>>>>>>
>>>>>> Also, Win8 has its own conventions as well which come into play on
>>>>>> the new high resolution Surface tablets and we should consider those
>>>>>> to guide the API we develop.
>>>>>>
>>>>>> All, in all, though, I think if we get @2x support in with no code
>>>>>> changes needed for apps then we have taken care of the primary use
>>>>>> case.  We can probably even handle the Win8 conventions behind the
>>>>>> scenes in an 8u release...
>>>>>>
>>>>>>             ...jim
>>>>>
>>>>>
>>>>
>>>>
>>


From alexandr.scherbatiy at oracle.com  Tue Dec  3 03:48:43 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 03 Dec 2013 15:48:43 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <529CF89E.80309@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
	<52967E74.4030205@oracle.com> <52975719.4050502@oracle.com>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com>
Message-ID: <529DC51B.8090604@oracle.com>


  Hello,

  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8011059/webrev.13/
   - observer cache is returned back
   - resolution variant x/y/width/height are divided by 2 in the 
observer wrapper

On 12/3/2013 1:16 AM, Jim Graham wrote:
> Hi Alexander,
>
> There must have been a miscommunication.  While I think the cache has 
> some issues that worry me, it is absolutely needed if you are going to 
> wrap the observer.  You can't just delete it and re-wrap the observer 
> on every call because that will create a number of problems.  If you 
> are going to use a wrapper solution then we will need to live with the 
> potential issues of a cache.
>
> Note that the underlying ImageReps store lists of observers to be 
> notified.  You will be growing that list every time a call is made on 
> an image because each new wrapper looks like a new observer. For an 
> animated GIF the number of drawImage calls and associated wrappers 
> could be infinite (since they are never fully loaded). Also, for each 
> new wrapper, an additional callback is performed. This will drive the 
> performance of an animated GIF into the ground after a time when 
> thousands of growing callbacks are issued for each frame.
>
> If you are going to use observer wrappers then you must cache the 
> wrapper so you reuse the same wrapper on every new call.
>
> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.12/
>>      - Image observers are not cached now for the resolution variants
>>      - base image width and height are checked in the wrapped image
>> observer
>>
>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> I suppose the wrapping solution works for ImageObservers, but I think
>>> the suggestion I gave in recent emails was to simply modify the
>>> newInfo method (and a couple of other methods) to deliver the same
>>> information with no caches, no hashmaps/lookups, no wrapping the
>>> observer, and no wrapping with soft references.  Keep in mind that
>>> observers are typically references to Component objects so any delay
>>> in processing the soft references could keep relatively large
>>> component hierarchies in play (if they are parents).  It should work
>>> well for a first draft, though.
>>      It seems that just updating the newInfo method is not enough.
>
> There were 5 or 6 places that called imageUpdate when I did a quick 
> search and most of the calls went through newInfo.  They'd all have to 
> be updated.  Other than that, I'm not sure why it would not be enough?

   Consider the following scenario. There are image.png and image at 2x.png 
files on the disk.
     Image image1 = Toolkit.getImage("image.png");  // load as 
multi-resolution image
     Image image2 = Toolkit.getImage("image at 2x.png");  // load the image 
from cache
     toolkit.prepareImage(image2,.., imageObserver2);

    The image2 has image1 as the base image so it rescale its 
coordinates/dimension and passes the base instead of self to the 
imageObserver2 which does not look correct.

>
>>      The resolution variant can have a reference to the base image.
>> Loading the base image it still should compare its result with the
>> resolution variant loading.
>>      So the image loading status is just moved from the SunToolkit to
>> the ToolkitImage.
>
> If you are referring to comparing the new and old dimensions then the 
> newInfo method would have access to that information if it could ask a 
> resolution variant what its base image is.  That should be a very 
> simple change to ToolkitImage (add a set/getBaseImage() method).  Then 
> it can do the associated comparisons and parameter adjustments right 
> before calling back to the observer.
>
> Perhaps I haven't explained my vision of modifying newInfo very well. 
> I'll look into sketching it out in another email since I think the 
> cache/wrappers are OK for now.
>
>>      I think that the current fix for the checkImage/prepareImage in the
>> SunToolkit is the simplest  for the current implementation.
>>      The separate fix for the ToolkitImage/ImageRepresentation can get
>> all things right.
>
> I didn't really follow you here, but I said above that the cache 
> should be fine for now.  The cache is definitely needed if you are 
> wrapping observers as I said above in the first couple of paragraphs.
>
>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>> static field on MRToolkitImage?
>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>> method always with null observer. So the is no need to create the
>> observer cache or use a synchronization during the cache initialization.
>
> Maybe I'm missing something about your answer here, but I think you 
> may have misunderstood my question.  You placed the field that holds 
> the reference to the cache inside an inner class.  I didn't see why 
> the reference could not be stored in the base class.  Why is there an 
> empty inner class to wrap a single field?  In other words, why was 
> this used:
>
>   56
>   57     private static class ObserverCache {
>   58
>   59         static final SoftCache INSTANCE = new SoftCache();
>   60     }
>   61
>
> Instead of just:
>
>   56
>   59     static final SoftCache INSTANCE = new SoftCache();
>   61

    Just to not create the cache in case if MRToolkitImageis used but 
image observers are always null. See the comment above.

    Thanks,
    Alexandr,.

>
>>> The current way of baking in the image dimensions assumes that they
>>> are known.  If the image is loaded asynchronously, then the calls to
>>> getWidth/Height(null) may return -1 and the cached observer wrapper
>>> has no way to get them later.  I would think this would fail in the
>>> typical default scenario where the user gets an image and the first
>>> even that triggers loading it is to render to the screen which would
>>> bake the -1's into the observer wrapper in all of those cases.  This
>>> should probably be addressed sooner rather than later.
>>      I added the base image width/height check to the observer wrapper.
>> However, there is no way to rescale image representation width and
>> height in case if the base image width and height are not known.
>
> That is true if we are basing the scaling solely on the difference in 
> dimensions.  In the case of @2x we also could assume that the scaling 
> would be 2.0.  I'm not sure if that kind of assumption can be made for 
> all future resolution variant mechanisms, but I'd imagine that many of 
> them come with a standard for determining the scaling of the variants 
> up front so that the correct media can be chosen without having to 
> load all of it first just to compare dimensions.
>
> If the image dimensions weren't known when your observer was created 
> then you never attempt to recover, though.  You should be querying 
> "image.getWidth(this)" to try to grab the dimensions on the fly when 
> they come in rather than always punting.  In the current case where 
> nothing is cached, you end up with multiple wrappers so some of them 
> will have been created before the dimensions were known and some will 
> be created after the dimensions are known and the multiple callbacks 
> will all have conflicting information.  You'll need to go back to a 
> cache and that will mean a single wrapper for any given observer and, 
> at that point, inserting calls to "image.getWidth(this /* wrapper */)" 
> will be needed to make sure you get the proper dimensions at some point.
>
>>> If an @2x image gets an error we silently start using just the regular
>>> version of the image.  In addition MediaTracker should not reflect
>>> that error in its answers, but I think it currently does since you add
>>> it as an implicit extra media with the same ID.  I think this is OK
>>> for the first pass, but we need to track it as an issue.
>>>
>>> I saw that you fixed the toolkit versions of check/prepare image.
>>> Component also has the same operations (via its peers).  The Component
>>> versions do back off to the toolkit versions, but only if they fail to
>>> find an actual peer to delegate to.  Note that MediaTracker uses the
>>> Component versions so it is affected by this, but I don't think it
>>> will cause functional problems that I can think of. Eventually we'd
>>> want MT to only load the version that is appropriate for the indicated
>>> Component - and at that point then this might be an issue, but I don't
>>> think it is an issue for this first draft if it tracks both variations.
>>     I checked all peers like W/LW/XComponentPeer and toolkits. They all
>> delegate check/prepareImage calls to the default toolkit.
>
> Sounds good.  Eventually we might want to have them prepare just the 
> default resolution for that particular device if they are already 
> associated with a screen, but this should be good to go for now...
>
> The outstanding issues for me are:
>
> - The cache was necessary to eliminate the overhead of duplicated 
> wrappers so it should go back (unless you want to investigate an 
> alternate solution by modifying all places that call imageUpdate 
> instead, which are hopefully few)
>
> - Retrying on the base image dimensions if they weren't known when a 
> wrapper was created (or switching to a pre-determined scale derived 
> from the resolution mechanism which benefits @2x and keeping the 
> "relative dimension" scaling for the general case)
>
>             ...jim
>
>>     Thanks,
>>     Alexandr.
>>
>>> I think it is OK to send multiple notifications to an observer since
>>> we've always been loose on the exact sequencing and the operations are
>>> all asynchronous.  There could potentially be several notifications in
>>> flight at the time that the observer indicates a lack of interest and
>>> there is no way to stop them.  This could be considered "another case
>>> of that".  Eventually we could consider addressing this with a tighter
>>> integration between the wrapper mechanism and the code that calls
>>> imageUpdate() and receives the answer that the observer is no longer
>>> interested, but I think this is all OK for now.
>>>
>>> The only thing I think we should worry about now for this first draft
>>> is the issue of getting the right dimensions for the observer
>>> wrappers. They need to be more asynchronous about that. It already has
>>> a handle on the original image anyway, so I think it just needs to get
>>> the dimensions from there instead of passing them into the
>>> constructor, with appropriate checks for -1's...
>>>
>>>             ...jim
>>>
>>> On 11/28/13 6:45 AM, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.11/
>>>>
>>>>    I have moved new API supporting to the separate issue:
>>>>      JDK-8029339 Custom MultiResolution image support on HiDPI 
>>>> displays
>>>>        https://bugs.openjdk.java.net/browse/JDK-8029339
>>>>
>>>>     - SunToolkit.checkImage/updateImage are updated to handle
>>>> multi-resolution image
>>>>        Both base image and the resolution variant are loaded now.
>>>> However, in future, it would be useful to have an ability to load, for
>>>> example, only @2x image
>>>>        if the system has only Retina display on Mac OS X. So there are
>>>> can be problems with backward compatibility.
>>>>
>>>>    - MediaTracker is updated to handle multi-resolution image
>>>>       MediaTracker uses notifications both form the
>>>> Toolkit.prepareImage() method and image decoders. So only updating
>>>> Toolkit.prepareImage() is not enough.
>>>>
>>>>    - ImageObserver is wrapped both in drawImage() and
>>>> SunToolkit.prepareImage() methods. Size and coordinates are 
>>>> converted to
>>>> the base image.
>>>>      A user can receive several notifications about the complete image
>>>> loading from the original image and from the resolution variant.
>>>>      It can breaks his code if the code relies that only one
>>>> notification should be received.
>>>>
>>>>    - Resolution variant is ignored in case of errors in the 
>>>> drawImage()
>>>>       It needs to be decided on which step a user should be notified
>>>> that a resolution variant has error or this notification should be 
>>>> just
>>>> ignored.
>>>>
>>>>    - Test is updated
>>>>
>>>>    Icons and CustomCursor issues are handled by 8028212 and 8024926 
>>>> bugs
>>>> and depend on the current bug implementation.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 11/28/2013 3:21 AM, Jim Graham wrote:
>>>>> The things I was talking about in the quoted email were mostly future
>>>>> directions, but I did point out some issues in another email that
>>>>> should be addressed before FCS.  In particular:
>>>>>
>>>>> We do need to get the callbacks working whether they draw hi res or
>>>>> not.  I think the current fix delivers no notifications at all 
>>>>> because
>>>>> the observer is not registered anywhere during the course of a
>>>>> drawImage().  That's a big bug.  I don't think we need to wrap
>>>>> observers to do that, there are only a few helper functions that
>>>>> deliver the notifications and they can be taught how to translate a
>>>>> resolution variant into the base image easily enough.
>>>>>
>>>>> You point out that there was no error checking for the hidpi 
>>>>> image.  I
>>>>> agree.  Also, if the base image errors out, should we draw the @2x
>>>>> anyway?  Or should that base image be required? Minimally I think we
>>>>> need to not attempt the @2x for FCS if it errored and we can worry
>>>>> about how to respond to errors in the base image later.
>>>>>
>>>>> I think that com.sun would require CCC approval for a new interface
>>>>> and the bar is really high for API in 8.0 right now. Unless a
>>>>> developer really needs to use it it might be best to move the API to
>>>>> sun.*.  I didn't see any developers clamoring for it in the
>>>>> discussions I read, but let me know if I missed something.  If we get
>>>>> automatic use of @2x images then I think that satisfies the
>>>>> discussions I saw.
>>>>>
>>>>> MediaTracker defers to Component.prepareImage() for which variants
>>>>> should be loaded.  I think we need to teach prepareImage() to trigger
>>>>> the variant appropriate for the screen that the Component is on
>>>>> (perhaps the default screen if it isn't displayed yet).
>>>>>
>>>>> Also, there should probably be some MediaTracker, ImageIcon, and
>>>>> Cursor test cases that show that those mechanisms all work on images
>>>>> that have @2x variants.  Minimally they shouldn't fail entirely, and
>>>>> very desireably they should use the @2x version when appropriate, but
>>>>> that could be a follow on bug fix as long as they don't fail for the
>>>>> first fix.
>>>>>
>>>>> I've included below the quote from my last "review" email about the
>>>>> specific issues I found.  The main "blocking" issue right now is that
>>>>> it looks to me that no imageUpdate notifications at all happen for a
>>>>> hidpi image due to the ImageObserver getting dropped on the floor. 
>>>>> Can
>>>>> we at least get imageUpdate() called with the base image, even if the
>>>>> xywh are wrong before we push the initial fix?  I hope my info below
>>>>> helps make that an easy task.
>>>>>
>>>>>> If they only ever use the image on a retina display (or some scaled
>>>>>> context) then I don't think we ever send any notifications the way
>>>>>> the current fix is written. Also, if you don't send notifications 
>>>>>> for
>>>>>> the scaled variant, but load the original and expect its
>>>>>> notifications to suffice, then we have a race condition - if the
>>>>>> original variant is fully constructed before the scaled version is
>>>>>> done then the final "OK to draw everything" notice would not happen
>>>>>> and they'd be left with a partial image.
>>>>>>
>>>>>> I think it should be easy to pass along the observer and simply have
>>>>>> ImageRep translate the image variant into the base image in its
>>>>>> newInfo method (and there are a couple of other locations that
>>>>>> imageUpdate is called that could do the same).  All it takes is
>>>>>> adding "ToolkitImage.set/getBaseImage()" to ToolkitImage, defaulting
>>>>>> to "this", but the Multi-Res image will set the base image on 
>>>>>> both of
>>>>>> its variants to the Multi-Res instance.
>>>>>>
>>>>>> Then we get full notices of all resolution variants.
>>>>>>
>>>>>> It would be best to scale the xywh supplied there as well. That
>>>>>> should be fairly easy, but if it is a big problem then that is lower
>>>>>> priority than getting the "ALLBITS" notification right, as that is
>>>>>> the main trigger for so many uses.
>>>>>>
>>>>>> (In the future we can add ImageObserver2 (or MultiResObserver?) 
>>>>>> which
>>>>>> has support for receiving notifications of variants without
>>>>>> translation.)
>>>>>
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 11/27/13 6:28 AM, Sergey Bylokhov wrote:
>>>>>> On 27.11.2013 15:12, Sergey Bylokhov wrote:
>>>>>>> Hello.
>>>>>>> Probably we are in a point when it is necessary to stop and move 
>>>>>>> out
>>>>>>> all extensions to the separate bugs.
>>>>>>> We should give a time to our sqe to test these changes.
>>>>>>> Actually current version looks good to me.
>>>>>> Small additional notes, It would be good:
>>>>>>   - to wrap initial observer in the drawImage and replace 
>>>>>> img/x,y,....
>>>>>> in the observer.
>>>>>>   - don't draw hidpi image, if it was loaded with errors.
>>>>>>   - sun.com package should be used?
>>>>>>   - If MediaTracker was requested to load MultiResolutionImage,it
>>>>>> should
>>>>>> load all versions?
>>>>>>>
>>>>>>> On 26.11.2013 2:31, Jim Graham wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>>>>>>>>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>>>>>>>>> Hi Alexander,
>>>>>>>>>>
>>>>>>>>>> If we are going to be advertising it as something that 
>>>>>>>>>> developers
>>>>>>>>>> use
>>>>>>>>>> in production code then we would need to file this via CCC.
>>>>>>>>>> With the
>>>>>>>>>> current implementation, any user that has their own 
>>>>>>>>>> ImageObservers
>>>>>>>>>> must use this API and so it becomes not only public, at a time
>>>>>>>>>> when
>>>>>>>>>> there is a lockdown on new public API in 8.0, but it also means
>>>>>>>>>> that
>>>>>>>>>> we are tied to its implementation and we can't rely on "it was
>>>>>>>>>> experimental and so we can change it at any point" - you 
>>>>>>>>>> can't say
>>>>>>>>>> that about an API that is necessary to correctly use a touted
>>>>>>>>>> feature.
>>>>>>>>>
>>>>>>>>>      This issue has its own history.  It has been already fixed
>>>>>>>>> for the
>>>>>>>>> JDK 7u for the Java2D demo. It was decided to not bring new API
>>>>>>>>> for the
>>>>>>>>> HiDPI support in the JDK 7.
>>>>>>>>>      It was suggested to using code like below to create a
>>>>>>>>> ScalableImage.
>>>>>>>>> ------------------------------
>>>>>>>>> /**
>>>>>>>>>   * Class that loads and returns images according to
>>>>>>>>>   * scale factor of graphic device
>>>>>>>>>   *
>>>>>>>>>   *  <pre> {@code
>>>>>>>>>   *    Image image = new ScalableImage() {
>>>>>>>>>   *
>>>>>>>>>   *        public Image createScaledImage(float scaleFactor) {
>>>>>>>>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>>>>>>>>   *                : loadImage("image at 2x.png");
>>>>>>>>>   *        }
>>>>>>>>>   *
>>>>>>>>>   *        Image loadImage(String name){
>>>>>>>>>   *            // load image
>>>>>>>>>   *        }
>>>>>>>>>   *    };}</pre>
>>>>>>>>>   */
>>>>>>>>> ------------------------------
>>>>>>>>>
>>>>>>>>>   It was based on the display scale factor. The scale factor
>>>>>>>>> should be
>>>>>>>>> manually retrieved from the Graphics2D and was not a part of the
>>>>>>>>> public
>>>>>>>>> API:
>>>>>>>>> g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>>>>>>>>
>>>>>>>>>   From that time it was clear that there should be 2 basic
>>>>>>>>> operations
>>>>>>>>> for the HiDPI images support:
>>>>>>>>>    - retrieve an image with necessary resolution
>>>>>>>>>    - retrieve images with all resolutions
>>>>>>>>>
>>>>>>>>>    The second one is useful when it is necessary to create one
>>>>>>>>> set of
>>>>>>>>> images using the given one (for example, to draw a shape on all
>>>>>>>>> images).
>>>>>>>>
>>>>>>>> For now, these are just ToolkitImages and you can't draw on 
>>>>>>>> them, so
>>>>>>>> this is moot for the case of @2x support in getImage().
>>>>>>>>
>>>>>>>>>    The JDK 7 solution has been revisited for the JDK 8 and the
>>>>>>>>> neccesary
>>>>>>>>> CCC request 8011059  has been created and approved.
>>>>>>>>>
>>>>>>>>>    Both the JDK-8011059 issue description and the approved CCC
>>>>>>>>> request
>>>>>>>>> says:
>>>>>>>>>    -----------------------
>>>>>>>>>    A user should have a unified way to provide high resolution
>>>>>>>>> images
>>>>>>>>> that can be drawn on HIDPI displays according to the user 
>>>>>>>>> provided
>>>>>>>>> algorithm.
>>>>>>>>>    -----------------------
>>>>>>>>
>>>>>>>> We've implemented the Hint part of that solution, but the 
>>>>>>>> mechanism
>>>>>>>> for creating custom multi-res images was not workable. I no longer
>>>>>>>> sit as the client rep on the CCC or I would have pointed that
>>>>>>>> out, my
>>>>>>>> apologies.
>>>>>>>>
>>>>>>>>>    The 8011059 fix consists of two parts:
>>>>>>>>>    - Provide a way for a custom image creation that holds images
>>>>>>>>> with
>>>>>>>>> different resolutions
>>>>>>>>>    - Load @2x images on Mac OS X
>>>>>>>>>
>>>>>>>>>    The first one of the fix can be used without the second. it
>>>>>>>>> is not
>>>>>>>>> difficult to crate just a class which loads @2x images using the
>>>>>>>>> given
>>>>>>>>> file path/url.
>>>>>>>>
>>>>>>>> If we support @2x transparently behind the scenes as we are doing
>>>>>>>> now, who is the requester for the way to create a custom set of
>>>>>>>> resolution variants?  I think the most important customer-driven
>>>>>>>> request was to support @2x for the Mac developers, wasn't it?
>>>>>>>>
>>>>>>>>>    Now it is suggested to implement the given 
>>>>>>>>> MultiResolutionImage
>>>>>>>>> interface  and override two methods:
>>>>>>>>>     - Image getResolutionVariant(int width, int height)
>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>
>>>>>>>>>     An image with necessary resolution should be drawn
>>>>>>>>> automatically in
>>>>>>>>> SunGraphics2D.
>>>>>>>>>
>>>>>>>>>    What we need is to focus on the first part of the fix.
>>>>>>>>>    From this point of view it up to the user' code to load all or
>>>>>>>>> some
>>>>>>>>> resolution variants by MediaTracker and using
>>>>>>>>> Component.prepareImage/checkImage methods.
>>>>>>>>
>>>>>>>> This is all an interesting goal, but I'm not sure it is as high a
>>>>>>>> priority if we support a convention (based on platform 
>>>>>>>> conventions)
>>>>>>>> for high resolution variants behind the scenes.  I do agree 
>>>>>>>> that we
>>>>>>>> need something like this before too long, but I don't think it was
>>>>>>>> workable to target the getScaledInstance() method as the
>>>>>>>> mechanism to
>>>>>>>> implement it.  That was the only convention that was approved in
>>>>>>>> that
>>>>>>>> CCC request, so a more complete API based on another mechanism is
>>>>>>>> not
>>>>>>>> covered there.
>>>>>>>>
>>>>>>>> Also, Win8 has its own conventions as well which come into play on
>>>>>>>> the new high resolution Surface tablets and we should consider 
>>>>>>>> those
>>>>>>>> to guide the API we develop.
>>>>>>>>
>>>>>>>> All, in all, though, I think if we get @2x support in with no code
>>>>>>>> changes needed for apps then we have taken care of the primary use
>>>>>>>> case.  We can probably even handle the Win8 conventions behind the
>>>>>>>> scenes in an 8u release...
>>>>>>>>
>>>>>>>>             ...jim
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>


From alexandr.scherbatiy at oracle.com  Tue Dec  3 08:11:39 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 03 Dec 2013 20:11:39 +0400
Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support
In-Reply-To: <526FE6BB.3010109@oracle.com>
References: <526FE6BB.3010109@oracle.com>
Message-ID: <529E02BB.2020609@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
   - MultiResolutionImage interface is used from the fix 8011059
   - Only icons with resolution 1x and 2x are created.

     The real Mac OS X system icon have more resolutions.
     The full fix requires retrieving and handling all NSImage 
representations. It can be addressed for the next release.

   Thanks,
   Alexandr.

On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>
> The fix returns a high resolution system icon in the overridden 
> getScaledInstance(width, height, hints) method.
>
> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK 
> demos look perfect on retina displays:
> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>  - getScaledInstance(width, height, hints) method is used for the 
> image drawing when IMAGE_SCALING hints are enabled
>  - LWCToolkit.ScalableToolkitImage class is public
>
> Thanks,
> Alexandr.
>


From alexandr.scherbatiy at oracle.com  Tue Dec  3 08:32:27 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 03 Dec 2013 20:32:27 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
Message-ID: <529E079B.6050708@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8028212
   webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00

   - MultiResolutionImage interface is used from the fix 8011059
   - NSImage with representations are created for the multi-resolution 
cursor
   - NSImage representations are rescaled to the base cursor size

Thanks,
Alexandr.


From anthony.petrov at oracle.com  Tue Dec  3 08:39:46 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 20:39:46 +0400
Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support
In-Reply-To: <529E02BB.2020609@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
Message-ID: <529E0952.6080106@oracle.com>

Hi Alexander,

The Graphics obtained at line 519 in AquaImageFactory.java is never 
dispose()'d.

Other than that, the fix looks good to me (although I'm not an expert in 
Aqua L&F or HiDPI support code).

--
best regards,
Anthony

On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>    - MultiResolutionImage interface is used from the fix 8011059
>    - Only icons with resolution 1x and 2x are created.
>
>      The real Mac OS X system icon have more resolutions.
>      The full fix requires retrieving and handling all NSImage
> representations. It can be addressed for the next release.
>
>    Thanks,
>    Alexandr.
>
> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>
>> The fix returns a high resolution system icon in the overridden
>> getScaledInstance(width, height, hints) method.
>>
>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>> demos look perfect on retina displays:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>>  - getScaledInstance(width, height, hints) method is used for the
>> image drawing when IMAGE_SCALING hints are enabled
>>  - LWCToolkit.ScalableToolkitImage class is public
>>
>> Thanks,
>> Alexandr.
>>
>

From anthony.petrov at oracle.com  Tue Dec  3 09:06:45 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 21:06:45 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
In-Reply-To: <529E079B.6050708@oracle.com>
References: <529E079B.6050708@oracle.com>
Message-ID: <529E0FA5.6090300@oracle.com>

Hi Alexander,

If we go with this fix, I suggest to move the 
CImage.Creator.resizeImageRepresentations() to the CImage class and make 
it a member method, so that you don't need to pass a CImage reference to 
it as an argument.

Also, there's the CImage.resize() method already. Why does it not work 
for us? Having a specification for both methods (or for one, if the 
second is unneeded) might be helpful.

However, I'm not sure if we really want to resize each representation of 
an NSImage object to the same size. Why would we want to do that? In 
fact, one of the representations might already have the correct size, 
and we could use just that whenever we need it w/o wasting resources on 
resizing each of them. If there's no representations of suitable size, 
then we should choose the closest one and resize just it to the desired 
size. Or am I misunderstanding anything?

Also, in CCustomCursor.getImageData(), could we somehow encapsulate a 
part (or all) of the Image vs. MultiResolutionImage logic in the 
CImage.Creator class?

PS. I'm not really an expert in Image handling code. I'd suggest someone 
from the 2D team to review this as well. Maybe Jim could help?

--
best regards,
Anthony

On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>
>    - MultiResolutionImage interface is used from the fix 8011059
>    - NSImage with representations are created for the multi-resolution
> cursor
>    - NSImage representations are rescaled to the base cursor size
>
> Thanks,
> Alexandr.
>

From alexandr.scherbatiy at oracle.com  Wed Dec  4 06:15:52 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 04 Dec 2013 18:15:52 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <529E1999.5080200@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
	<52967E74.4030205@oracle.com> <52975719.4050502@oracle.com>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com>
Message-ID: <529F3918.40607@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8011059/webrev.14
   - Observer and rvObserver are used to get width/hight from 
image/rvImage in SunGraphics2D
   - width and height are rounded up in the image observer wrapper
   - width and height are also rescaled for the SOMEBITS, FRAMEBITS , 
and ALLBITS infoflags

  Thanks,
  Alexandr.


On 12/3/2013 9:49 PM, Jim Graham wrote:
> Hi Alexander,
>
> There is one last thing that I think I forgot to mention in SG2D that 
> might make some other comments I made make more sense.  There is no 
> observer registered on the resolution variant in SG2D.drawHiDPIImage() 
> in the case where the resolution variant hasn't been loaded yet. 
> Basically, the lines at 3099,3100 will trigger the variant to load, 
> but there is no observer in those calls to trace it back to the guy 
> who needs to call drawImage() again.  So, the only thing I think that 
> needs to be done is that the observer needs to be wrapped and handed 
> in to those calls to getWidth/Height(observer).
>
> The rest of that method looks fine - the regular variant will be used 
> (and will trigger repaints via the code that calls into drawImage()) 
> until the base image dimensions are known enough to trigger the 
> getResolutionVariant() code, and then we might continue to use the 
> regular version until the resolution variant at least knows its 
> dimensions, and that is all OK, but we need to start using the 
> observer wrapper on the resolution variant starting at lines 3099,3100 
> in order to get the repaints to keep happening for that version of the 
> image.
>
> Arguably, in addition, the unwrapped observer probably could be used 
> on lines 3089, 3090 when you get the dimensions of the base image, but 
> since the base image will later be handed to the drawImage pipeline, 
> the observer will be registered there anyway, so that isn't a bug.  
> But, the wrapped observer needs to be used on 3099,3100 or we may 
> never repaint with the resolution variant (it will be a race condition 
> based on how fast the regular and hiDPI images load).
>
> More comments below, but that is the only remaining blocker that I can 
> see...
>
> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> I suppose the wrapping solution works for ImageObservers, but I think
>>>>> the suggestion I gave in recent emails was to simply modify the
>>>>> newInfo method (and a couple of other methods) to deliver the same
>>>>> information with no caches, no hashmaps/lookups, no wrapping the
>>>>> observer, and no wrapping with soft references.  Keep in mind that
>>>>> observers are typically references to Component objects so any delay
>>>>> in processing the soft references could keep relatively large
>>>>> component hierarchies in play (if they are parents).  It should work
>>>>> well for a first draft, though.
>>>>      It seems that just updating the newInfo method is not enough.
>>>
>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>> search and most of the calls went through newInfo.  They'd all have to
>>> be updated.  Other than that, I'm not sure why it would not be enough?
>>
>>    Consider the following scenario. There are image.png and image at 2x.png
>> files on the disk.
>>      Image image1 = Toolkit.getImage("image.png");  // load as
>> multi-resolution image
>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
>> from cache
>>      toolkit.prepareImage(image2,.., imageObserver2);
>>
>>     The image2 has image1 as the base image so it rescale its
>> coordinates/dimension and passes the base instead of self to the
>> imageObserver2 which does not look correct.
>
> I see your point now.  I had thought that they would be cached 
> separately, but I see now that both are inserted into the hash 
> directly.  That allows sharing if they access both manually, but it 
> complicates the observer issue.  I don't think I would have bothered 
> with sharing the Image instance with a manual reference to the @2x in 
> that case, but we should be able to handle both in a future bug fix 
> and hopefully also get rid of wrappers, but it would take some surgery 
> on the drawImage pipeline and the record keeping in the observer 
> lists.  The existing solution will work fine for @2x images and allow 
> sharing so it is good to go for now (modulo the one issue with using 
> the wrapper for the getWidth()/getHeight() I mentioned above).
>
>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>> static field on MRToolkitImage?
>>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>>> method always with null observer. So the is no need to create the
>>>> observer cache or use a synchronization during the cache 
>>>> initialization.
>>>
>>> Maybe I'm missing something about your answer here, but I think you
>>> may have misunderstood my question.  You placed the field that holds
>>> the reference to the cache inside an inner class.  I didn't see why
>>> the reference could not be stored in the base class.  Why is there an
>>> empty inner class to wrap a single field?  In other words, why was
>>> this used:
>>>
>>>   56
>>>   57     private static class ObserverCache {
>>>   58
>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>   60     }
>>>   61
>>>
>>> Instead of just:
>>>
>>>   56
>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>   61
>>
>>     Just to not create the cache in case if MRToolkitImageis used but
>> image observers are always null. See the comment above.
>
> Ah, so this is just a micro-optimization then?  I'm not sure what you 
> mean by "always null".  It depends on whether they hand in an 
> observer, doesn't it?  The standard case of drawImage() tends to hand 
> in the Component as the observer.  In cases where we know we are using 
> a BufferedImage, we often use null, but code that uses a toolkit image 
> (or that doesn't know what the image is) should be using a non-null 
> observer or it won't paint right the first time when it triggers the 
> image loading.
>
> The cache object itself takes so little room that I don't think it is 
> worth worrying about.  If something triggers MRToolkitImage to be 
> referenced at all, then the 99% case will likely eventually involve 
> drawImage() calls with observer and an empty cache takes so little 
> room that it is probably fine to just aggressively create it at that 
> time.
>
> There is no bug or problem here, I just don't think the indirection 
> buys us anything worthwhile here...
>
>             ...jim


From alexandr.scherbatiy at oracle.com  Wed Dec  4 06:59:44 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 04 Dec 2013 18:59:44 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
In-Reply-To: <529E0FA5.6090300@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
Message-ID: <529F4360.5010808@oracle.com>

On 12/3/2013 9:06 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> If we go with this fix, I suggest to move the 
> CImage.Creator.resizeImageRepresentations() to the CImage class and 
> make it a member method, so that you don't need to pass a CImage 
> reference to it as an argument.
     I will update this.
>
> Also, there's the CImage.resize() method already. Why does it not work 
> for us? Having a specification for both methods (or for one, if the 
> second is unneeded) might be helpful.

      I do not know why, but SetNSImageSize (  [i 
setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not 
work in this case. The high resolution representation is not chosen on
      my Mac OS X with enabled Quartz Debug.

     I tried to narrow the problem and write the cocoa code. It is 
described in https://bugs.openjdk.java.net/browse/JDK-8028212

    Thanks,
    Alexandr.

>
> However, I'm not sure if we really want to resize each representation 
> of an NSImage object to the same size. Why would we want to do that? 
> In fact, one of the representations might already have the correct 
> size, and we could use just that whenever we need it w/o wasting 
> resources on resizing each of them. If there's no representations of 
> suitable size, then we should choose the closest one and resize just 
> it to the desired size. Or am I misunderstanding anything?
>
> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a 
> part (or all) of the Image vs. MultiResolutionImage logic in the 
> CImage.Creator class?
>
> PS. I'm not really an expert in Image handling code. I'd suggest 
> someone from the 2D team to review this as well. Maybe Jim could help?
>
> -- 
> best regards,
> Anthony
>
> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>
>>    - MultiResolutionImage interface is used from the fix 8011059
>>    - NSImage with representations are created for the multi-resolution
>> cursor
>>    - NSImage representations are rescaled to the base cursor size
>>
>> Thanks,
>> Alexandr.
>>


From anthony.petrov at oracle.com  Wed Dec  4 08:24:22 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 04 Dec 2013 20:24:22 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
In-Reply-To: <529F4360.5010808@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com>
Message-ID: <529F5736.2030901@oracle.com>

Thanks for the update, Alexander. I understand.

So, my only concerns that remain are:

1. The membership of the resizeImageRepresentations() method.

2. The encapsulation of the logic handling the 
Image/MultiResolutionImage case (see at the bottom of my original message).

--
best regards,
Anthony

On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> If we go with this fix, I suggest to move the
>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>> make it a member method, so that you don't need to pass a CImage
>> reference to it as an argument.
>      I will update this.
>>
>> Also, there's the CImage.resize() method already. Why does it not work
>> for us? Having a specification for both methods (or for one, if the
>> second is unneeded) might be helpful.
>
>       I do not know why, but SetNSImageSize (  [i
> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
> work in this case. The high resolution representation is not chosen on
>       my Mac OS X with enabled Quartz Debug.
>
>      I tried to narrow the problem and write the cocoa code. It is
> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>
>     Thanks,
>     Alexandr.
>
>>
>> However, I'm not sure if we really want to resize each representation
>> of an NSImage object to the same size. Why would we want to do that?
>> In fact, one of the representations might already have the correct
>> size, and we could use just that whenever we need it w/o wasting
>> resources on resizing each of them. If there's no representations of
>> suitable size, then we should choose the closest one and resize just
>> it to the desired size. Or am I misunderstanding anything?
>>
>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>> part (or all) of the Image vs. MultiResolutionImage logic in the
>> CImage.Creator class?
>>
>> PS. I'm not really an expert in Image handling code. I'd suggest
>> someone from the 2D team to review this as well. Maybe Jim could help?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>
>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>    - NSImage with representations are created for the multi-resolution
>>> cursor
>>>    - NSImage representations are rescaled to the base cursor size
>>>
>>> Thanks,
>>> Alexandr.
>>>
>

From Sergey.Bylokhov at oracle.com  Thu Dec  5 01:58:12 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Dec 2013 13:58:12 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <529F7174.3030805@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
	<52967E74.4030205@oracle.com> <52975719.4050502@oracle.com>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com> <529F3918.40607@oracle.com>
	<529F7174.3030805@oracle.com>
Message-ID: <52A04E34.1080804@oracle.com>

Hi, Alexander.
Count me as a second reviewer.

On 12/4/13 10:16 PM, Jim Graham wrote:
> Hi Alexander,
>
> It looks good to go.  I only skimmed the other parts of the fix on the 
> assumption that they haven't changed in a few revisions, but it all 
> looked good.  Glad to see you fixed the dimension issues in the 
> observer as well.
>
> I'll follow up with a list of future issues to track...
>
>             ...jim
>
> On 12/4/13 6:15 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.14
>>    - Observer and rvObserver are used to get width/hight from
>> image/rvImage in SunGraphics2D
>>    - width and height are rounded up in the image observer wrapper
>>    - width and height are also rescaled for the SOMEBITS, FRAMEBITS ,
>> and ALLBITS infoflags
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 12/3/2013 9:49 PM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> There is one last thing that I think I forgot to mention in SG2D that
>>> might make some other comments I made make more sense.  There is no
>>> observer registered on the resolution variant in SG2D.drawHiDPIImage()
>>> in the case where the resolution variant hasn't been loaded yet.
>>> Basically, the lines at 3099,3100 will trigger the variant to load,
>>> but there is no observer in those calls to trace it back to the guy
>>> who needs to call drawImage() again.  So, the only thing I think that
>>> needs to be done is that the observer needs to be wrapped and handed
>>> in to those calls to getWidth/Height(observer).
>>>
>>> The rest of that method looks fine - the regular variant will be used
>>> (and will trigger repaints via the code that calls into drawImage())
>>> until the base image dimensions are known enough to trigger the
>>> getResolutionVariant() code, and then we might continue to use the
>>> regular version until the resolution variant at least knows its
>>> dimensions, and that is all OK, but we need to start using the
>>> observer wrapper on the resolution variant starting at lines 3099,3100
>>> in order to get the repaints to keep happening for that version of the
>>> image.
>>>
>>> Arguably, in addition, the unwrapped observer probably could be used
>>> on lines 3089, 3090 when you get the dimensions of the base image, but
>>> since the base image will later be handed to the drawImage pipeline,
>>> the observer will be registered there anyway, so that isn't a bug.
>>> But, the wrapped observer needs to be used on 3099,3100 or we may
>>> never repaint with the resolution variant (it will be a race condition
>>> based on how fast the regular and hiDPI images load).
>>>
>>> More comments below, but that is the only remaining blocker that I can
>>> see...
>>>
>>> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>>>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> I suppose the wrapping solution works for ImageObservers, but I 
>>>>>>> think
>>>>>>> the suggestion I gave in recent emails was to simply modify the
>>>>>>> newInfo method (and a couple of other methods) to deliver the same
>>>>>>> information with no caches, no hashmaps/lookups, no wrapping the
>>>>>>> observer, and no wrapping with soft references.  Keep in mind that
>>>>>>> observers are typically references to Component objects so any 
>>>>>>> delay
>>>>>>> in processing the soft references could keep relatively large
>>>>>>> component hierarchies in play (if they are parents). It should work
>>>>>>> well for a first draft, though.
>>>>>>      It seems that just updating the newInfo method is not enough.
>>>>>
>>>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>>>> search and most of the calls went through newInfo.  They'd all 
>>>>> have to
>>>>> be updated.  Other than that, I'm not sure why it would not be 
>>>>> enough?
>>>>
>>>>    Consider the following scenario. There are image.png and 
>>>> image at 2x.png
>>>> files on the disk.
>>>>      Image image1 = Toolkit.getImage("image.png");  // load as
>>>> multi-resolution image
>>>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the 
>>>> image
>>>> from cache
>>>>      toolkit.prepareImage(image2,.., imageObserver2);
>>>>
>>>>     The image2 has image1 as the base image so it rescale its
>>>> coordinates/dimension and passes the base instead of self to the
>>>> imageObserver2 which does not look correct.
>>>
>>> I see your point now.  I had thought that they would be cached
>>> separately, but I see now that both are inserted into the hash
>>> directly.  That allows sharing if they access both manually, but it
>>> complicates the observer issue.  I don't think I would have bothered
>>> with sharing the Image instance with a manual reference to the @2x in
>>> that case, but we should be able to handle both in a future bug fix
>>> and hopefully also get rid of wrappers, but it would take some surgery
>>> on the drawImage pipeline and the record keeping in the observer
>>> lists.  The existing solution will work fine for @2x images and allow
>>> sharing so it is good to go for now (modulo the one issue with using
>>> the wrapper for the getWidth()/getHeight() I mentioned above).
>>>
>>>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>>>> static field on MRToolkitImage?
>>>>>>       MRToolkitImage can be used in 
>>>>>> drawImage(Image,..,ImageObserver)
>>>>>> method always with null observer. So the is no need to create the
>>>>>> observer cache or use a synchronization during the cache
>>>>>> initialization.
>>>>>
>>>>> Maybe I'm missing something about your answer here, but I think you
>>>>> may have misunderstood my question.  You placed the field that holds
>>>>> the reference to the cache inside an inner class.  I didn't see why
>>>>> the reference could not be stored in the base class.  Why is there an
>>>>> empty inner class to wrap a single field?  In other words, why was
>>>>> this used:
>>>>>
>>>>>   56
>>>>>   57     private static class ObserverCache {
>>>>>   58
>>>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>>>   60     }
>>>>>   61
>>>>>
>>>>> Instead of just:
>>>>>
>>>>>   56
>>>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>>>   61
>>>>
>>>>     Just to not create the cache in case if MRToolkitImageis used but
>>>> image observers are always null. See the comment above.
>>>
>>> Ah, so this is just a micro-optimization then?  I'm not sure what you
>>> mean by "always null".  It depends on whether they hand in an
>>> observer, doesn't it?  The standard case of drawImage() tends to hand
>>> in the Component as the observer.  In cases where we know we are using
>>> a BufferedImage, we often use null, but code that uses a toolkit image
>>> (or that doesn't know what the image is) should be using a non-null
>>> observer or it won't paint right the first time when it triggers the
>>> image loading.
>>>
>>> The cache object itself takes so little room that I don't think it is
>>> worth worrying about.  If something triggers MRToolkitImage to be
>>> referenced at all, then the 99% case will likely eventually involve
>>> drawImage() calls with observer and an empty cache takes so little
>>> room that it is probably fine to just aggressively create it at that
>>> time.
>>>
>>> There is no bug or problem here, I just don't think the indirection
>>> buys us anything worthwhile here...
>>>
>>>             ...jim
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Thu Dec  5 06:01:27 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 05 Dec 2013 18:01:27 +0400
Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support
In-Reply-To: <529E0952.6080106@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
	<529E0952.6080106@oracle.com>
Message-ID: <52A08737.4070305@oracle.com>


  Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8024926/webrev.02/

    - the graphics object is disposed in the 
AquaImageFactory.MultiResolutionIconImage constructor

   Thanks,
   Alexandr.

On 12/3/2013 8:39 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> The Graphics obtained at line 519 in AquaImageFactory.java is never 
> dispose()'d.
>
> Other than that, the fix looks good to me (although I'm not an expert 
> in Aqua L&F or HiDPI support code).
>
> -- 
> best regards,
> Anthony
>
> On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>>    - MultiResolutionImage interface is used from the fix 8011059
>>    - Only icons with resolution 1x and 2x are created.
>>
>>      The real Mac OS X system icon have more resolutions.
>>      The full fix requires retrieving and handling all NSImage
>> representations. It can be addressed for the next release.
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>>
>>> The fix returns a high resolution system icon in the overridden
>>> getScaledInstance(width, height, hints) method.
>>>
>>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>>> demos look perfect on retina displays:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>>>  - getScaledInstance(width, height, hints) method is used for the
>>> image drawing when IMAGE_SCALING hints are enabled
>>>  - LWCToolkit.ScalableToolkitImage class is public
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>


From alexandr.scherbatiy at oracle.com  Thu Dec  5 06:06:09 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 05 Dec 2013 18:06:09 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
In-Reply-To: <529F5736.2030901@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com> <529F5736.2030901@oracle.com>
Message-ID: <52A08851.4010400@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/

   - CImage.createFromImage() method is updated to handle 
MultiResolutionImage
   - resizeRepresentations() method is moved from Creator to the CImage 
class
   - nativeResizeImageRepresentations method is renamed to 
nativeResizeNSImageRepresentations in the CImage class
   - ImageReprese-M-tations typo is fixed in the CImage native code

   Thanks,
   Alexandr.

On 12/4/2013 8:24 PM, Anthony Petrov wrote:
> Thanks for the update, Alexander. I understand.
>
> So, my only concerns that remain are:
>
> 1. The membership of the resizeImageRepresentations() method.
>
> 2. The encapsulation of the logic handling the 
> Image/MultiResolutionImage case (see at the bottom of my original 
> message).
>
> -- 
> best regards,
> Anthony
>
> On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
>> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> If we go with this fix, I suggest to move the
>>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>>> make it a member method, so that you don't need to pass a CImage
>>> reference to it as an argument.
>>      I will update this.
>>>
>>> Also, there's the CImage.resize() method already. Why does it not work
>>> for us? Having a specification for both methods (or for one, if the
>>> second is unneeded) might be helpful.
>>
>>       I do not know why, but SetNSImageSize (  [i
>> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
>> work in this case. The high resolution representation is not chosen on
>>       my Mac OS X with enabled Quartz Debug.
>>
>>      I tried to narrow the problem and write the cocoa code. It is
>> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>>
>>     Thanks,
>>     Alexandr.
>>
>>>
>>> However, I'm not sure if we really want to resize each representation
>>> of an NSImage object to the same size. Why would we want to do that?
>>> In fact, one of the representations might already have the correct
>>> size, and we could use just that whenever we need it w/o wasting
>>> resources on resizing each of them. If there's no representations of
>>> suitable size, then we should choose the closest one and resize just
>>> it to the desired size. Or am I misunderstanding anything?
>>>
>>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>>> part (or all) of the Image vs. MultiResolutionImage logic in the
>>> CImage.Creator class?
>>>
>>> PS. I'm not really an expert in Image handling code. I'd suggest
>>> someone from the 2D team to review this as well. Maybe Jim could help?
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>>
>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>    - NSImage with representations are created for the multi-resolution
>>>> cursor
>>>>    - NSImage representations are rescaled to the base cursor size
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>


From Sergey.Bylokhov at oracle.com  Thu Dec  5 06:59:49 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Dec 2013 18:59:49 +0400
Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support
In-Reply-To: <52A08737.4070305@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
	<529E0952.6080106@oracle.com> <52A08737.4070305@oracle.com>
Message-ID: <52A094E5.5080800@oracle.com>

Hi, Alexander.
The fix looks good.
On 12/5/13 6:01 PM, Alexander Scherbatiy wrote:
>
>  Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8024926/webrev.02/
>
>    - the graphics object is disposed in the 
> AquaImageFactory.MultiResolutionIconImage constructor
>
>   Thanks,
>   Alexandr.
>
> On 12/3/2013 8:39 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> The Graphics obtained at line 519 in AquaImageFactory.java is never 
>> dispose()'d.
>>
>> Other than that, the fix looks good to me (although I'm not an expert 
>> in Aqua L&F or HiDPI support code).
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>>>
>>>    Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>    - Only icons with resolution 1x and 2x are created.
>>>
>>>      The real Mac OS X system icon have more resolutions.
>>>      The full fix requires retrieving and handling all NSImage
>>> representations. It can be addressed for the next release.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>>>
>>>> The fix returns a high resolution system icon in the overridden
>>>> getScaledInstance(width, height, hints) method.
>>>>
>>>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>>>> demos look perfect on retina displays:
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html 
>>>>
>>>>  - getScaledInstance(width, height, hints) method is used for the
>>>> image drawing when IMAGE_SCALING hints are enabled
>>>>  - LWCToolkit.ScalableToolkitImage class is public
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Dec  5 07:01:50 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Dec 2013 19:01:50 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
In-Reply-To: <52A08851.4010400@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com> <529F5736.2030901@oracle.com>
	<52A08851.4010400@oracle.com>
Message-ID: <52A0955E.4000209@oracle.com>

Hi, Alexander.
The fix looks good.
On 12/5/13 6:06 PM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/
>
>   - CImage.createFromImage() method is updated to handle 
> MultiResolutionImage
>   - resizeRepresentations() method is moved from Creator to the CImage 
> class
>   - nativeResizeImageRepresentations method is renamed to 
> nativeResizeNSImageRepresentations in the CImage class
>   - ImageReprese-M-tations typo is fixed in the CImage native code
>
>   Thanks,
>   Alexandr.
>
> On 12/4/2013 8:24 PM, Anthony Petrov wrote:
>> Thanks for the update, Alexander. I understand.
>>
>> So, my only concerns that remain are:
>>
>> 1. The membership of the resizeImageRepresentations() method.
>>
>> 2. The encapsulation of the logic handling the 
>> Image/MultiResolutionImage case (see at the bottom of my original 
>> message).
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
>>> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>>>> Hi Alexander,
>>>>
>>>> If we go with this fix, I suggest to move the
>>>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>>>> make it a member method, so that you don't need to pass a CImage
>>>> reference to it as an argument.
>>>      I will update this.
>>>>
>>>> Also, there's the CImage.resize() method already. Why does it not work
>>>> for us? Having a specification for both methods (or for one, if the
>>>> second is unneeded) might be helpful.
>>>
>>>       I do not know why, but SetNSImageSize (  [i
>>> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
>>> work in this case. The high resolution representation is not chosen on
>>>       my Mac OS X with enabled Quartz Debug.
>>>
>>>      I tried to narrow the problem and write the cocoa code. It is
>>> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>>
>>>> However, I'm not sure if we really want to resize each representation
>>>> of an NSImage object to the same size. Why would we want to do that?
>>>> In fact, one of the representations might already have the correct
>>>> size, and we could use just that whenever we need it w/o wasting
>>>> resources on resizing each of them. If there's no representations of
>>>> suitable size, then we should choose the closest one and resize just
>>>> it to the desired size. Or am I misunderstanding anything?
>>>>
>>>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>>>> part (or all) of the Image vs. MultiResolutionImage logic in the
>>>> CImage.Creator class?
>>>>
>>>> PS. I'm not really an expert in Image handling code. I'd suggest
>>>> someone from the 2D team to review this as well. Maybe Jim could help?
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>>>
>>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>>    - NSImage with representations are created for the 
>>>>> multi-resolution
>>>>> cursor
>>>>>    - NSImage representations are rescaled to the base cursor size
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>
>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Thu Dec  5 11:55:19 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 23:55:19 +0400
Subject: [8] Review request for 8028212 Custom cursor HiDPI support
In-Reply-To: <52A08851.4010400@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com> <529F5736.2030901@oracle.com>
	<52A08851.4010400@oracle.com>
Message-ID: <52A0DA27.8050907@oracle.com>

The fix looks fine to me. Thank you.

--
best regards,
Anthony

On 12/05/2013 06:06 PM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/
>
>    - CImage.createFromImage() method is updated to handle
> MultiResolutionImage
>    - resizeRepresentations() method is moved from Creator to the CImage
> class
>    - nativeResizeImageRepresentations method is renamed to
> nativeResizeNSImageRepresentations in the CImage class
>    - ImageReprese-M-tations typo is fixed in the CImage native code
>
>    Thanks,
>    Alexandr.
>
> On 12/4/2013 8:24 PM, Anthony Petrov wrote:
>> Thanks for the update, Alexander. I understand.
>>
>> So, my only concerns that remain are:
>>
>> 1. The membership of the resizeImageRepresentations() method.
>>
>> 2. The encapsulation of the logic handling the
>> Image/MultiResolutionImage case (see at the bottom of my original
>> message).
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
>>> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>>>> Hi Alexander,
>>>>
>>>> If we go with this fix, I suggest to move the
>>>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>>>> make it a member method, so that you don't need to pass a CImage
>>>> reference to it as an argument.
>>>      I will update this.
>>>>
>>>> Also, there's the CImage.resize() method already. Why does it not work
>>>> for us? Having a specification for both methods (or for one, if the
>>>> second is unneeded) might be helpful.
>>>
>>>       I do not know why, but SetNSImageSize (  [i
>>> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
>>> work in this case. The high resolution representation is not chosen on
>>>       my Mac OS X with enabled Quartz Debug.
>>>
>>>      I tried to narrow the problem and write the cocoa code. It is
>>> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>>
>>>> However, I'm not sure if we really want to resize each representation
>>>> of an NSImage object to the same size. Why would we want to do that?
>>>> In fact, one of the representations might already have the correct
>>>> size, and we could use just that whenever we need it w/o wasting
>>>> resources on resizing each of them. If there's no representations of
>>>> suitable size, then we should choose the closest one and resize just
>>>> it to the desired size. Or am I misunderstanding anything?
>>>>
>>>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>>>> part (or all) of the Image vs. MultiResolutionImage logic in the
>>>> CImage.Creator class?
>>>>
>>>> PS. I'm not really an expert in Image handling code. I'd suggest
>>>> someone from the 2D team to review this as well. Maybe Jim could help?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>>>
>>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>>    - NSImage with representations are created for the multi-resolution
>>>>> cursor
>>>>>    - NSImage representations are rescaled to the base cursor size
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>
>

From anthony.petrov at oracle.com  Thu Dec  5 11:57:29 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 23:57:29 +0400
Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support
In-Reply-To: <52A094E5.5080800@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
	<529E0952.6080106@oracle.com> <52A08737.4070305@oracle.com>
	<52A094E5.5080800@oracle.com>
Message-ID: <52A0DAA9.5050106@oracle.com>

+1.

--
best regards,
Anthony

On 12/05/2013 06:59 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> The fix looks good.
> On 12/5/13 6:01 PM, Alexander Scherbatiy wrote:
>>
>>  Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8024926/webrev.02/
>>
>>    - the graphics object is disposed in the
>> AquaImageFactory.MultiResolutionIconImage constructor
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 12/3/2013 8:39 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> The Graphics obtained at line 519 in AquaImageFactory.java is never
>>> dispose()'d.
>>>
>>> Other than that, the fix looks good to me (although I'm not an expert
>>> in Aqua L&F or HiDPI support code).
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>>>>
>>>>    Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>    - Only icons with resolution 1x and 2x are created.
>>>>
>>>>      The real Mac OS X system icon have more resolutions.
>>>>      The full fix requires retrieving and handling all NSImage
>>>> representations. It can be addressed for the next release.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>>>>
>>>>> The fix returns a high resolution system icon in the overridden
>>>>> getScaledInstance(width, height, hints) method.
>>>>>
>>>>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>>>>> demos look perfect on retina displays:
>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>>>>>
>>>>>  - getScaledInstance(width, height, hints) method is used for the
>>>>> image drawing when IMAGE_SCALING hints are enabled
>>>>>  - LWCToolkit.ScalableToolkitImage class is public
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>
>>
>
>

From swingler at apple.com  Thu Dec  5 12:07:39 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 05 Dec 2013 12:07:39 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <529E1EA0.7080209@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
	<71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
	<5282DB56.7090306@oracle.com>
	<1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>
	<5282ED9F.805@oracle.com>
	<3F1315D7-D09F-46F2-8A72-4C43F9CE5D8F@apple.com>
	<529E1EA0.7080209@oracle.com>
Message-ID: <D3C8A49A-260A-4585-AF95-D76AC0BCF32E@apple.com>

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

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

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

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

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

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

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

Regards,
Mike Swingler
Apple Inc.


From wmoore40 at gmail.com  Sun Dec  8 03:03:43 2013
From: wmoore40 at gmail.com (William Moore)
Date: Sun, 8 Dec 2013 12:03:43 +0100
Subject: Building OpenJDK on Mavericks (OS X 10.9)
Message-ID: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>

Hi

Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.

Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:

> clang: error: argument unused during compilation: '-fcheck-new?

If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:

> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]

What do I have to do to make this compile?

I know very little about C programming. Any help will be greatly appreciated.

Best regards

William

From david.dehaven at oracle.com  Mon Dec  9 09:26:44 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 9 Dec 2013 09:26:44 -0800
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>
Message-ID: <C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>


> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
> 
> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
> 
>> clang: error: argument unused during compilation: '-fcheck-new?
> 
> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
> 
>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
> 
> What do I have to do to make this compile?
> 
> I know very little about C programming. Any help will be greatly appreciated.
> 
> Best regards
> 
> William

Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.

-DrD-


From paul_t100 at fastmail.fm  Tue Dec 10 05:41:44 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Tue, 10 Dec 2013 13:41:44 +0000
Subject: Dragging an image from firefox browser works but not Google Chrome
	with Java 7
Message-ID: <52A71A18.8030607@fastmail.fm>

Dragging an image from firefox browser works but not Google Chrome, 
Chrome provides no data flavours when using Java 7 (1.7.0_45) although 
it works correctly when using Java 6

From wmoore40 at gmail.com  Tue Dec 10 05:48:07 2013
From: wmoore40 at gmail.com (William Moore)
Date: Tue, 10 Dec 2013 14:48:07 +0100
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>
	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>
Message-ID: <D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>

Thanks David

Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.

William

On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:

> 
>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>> 
>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>> 
>>> clang: error: argument unused during compilation: '-fcheck-new?
>> 
>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>> 
>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>> 
>> What do I have to do to make this compile?
>> 
>> I know very little about C programming. Any help will be greatly appreciated.
>> 
>> Best regards
>> 
>> William
> 
> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
> 
> -DrD-
> 


From staffan.larsen at oracle.com  Tue Dec 10 06:38:17 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 10 Dec 2013 15:38:17 +0100
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>
	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>
	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
Message-ID: <F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>


On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:

> Thanks David
> 
> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.

Having multiple XCode versions installed is also a work-around.

/Staffan

> 
> William
> 
> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
> 
>> 
>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>> 
>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>> 
>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>> 
>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>> 
>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>> 
>>> What do I have to do to make this compile?
>>> 
>>> I know very little about C programming. Any help will be greatly appreciated.
>>> 
>>> Best regards
>>> 
>>> William
>> 
>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>> 
>> -DrD-
>> 
> 


From wmoore40 at gmail.com  Tue Dec 10 06:55:14 2013
From: wmoore40 at gmail.com (William Moore)
Date: Tue, 10 Dec 2013 15:55:14 +0100
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>
	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>
	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
Message-ID: <C13338BE-5989-482C-ADFF-BDDBAC72B9A0@gmail.com>

OK, I?ll try that too. 

William

On 10 Dec 2013, at 3:38pm, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> 
> On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:
> 
>> Thanks David
>> 
>> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.
> 
> Having multiple XCode versions installed is also a work-around.
> 
> /Staffan
> 
>> 
>> William
>> 
>> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
>> 
>>> 
>>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>>> 
>>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>>> 
>>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>>> 
>>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>>> 
>>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>>> 
>>>> What do I have to do to make this compile?
>>>> 
>>>> I know very little about C programming. Any help will be greatly appreciated.
>>>> 
>>>> Best regards
>>>> 
>>>> William
>>> 
>>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>>> 
>>> -DrD-
>>> 
>> 
> 


From weijun.wang at oracle.com  Tue Dec 10 07:05:13 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 10 Dec 2013 23:05:13 +0800
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
Message-ID: <52A72DA9.80006@oracle.com>

What I did is to save a copy of usr dir inside Xcode 4 and run

   bash configure --with-tools-dir=/saved/xcode4/usr/bin/ ...

--Max

On 12/10/13, 22:38, Staffan Larsen wrote:
>
> On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:
>
>> Thanks David
>>
>> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.
>
> Having multiple XCode versions installed is also a work-around.
>
> /Staffan
>
>>
>> William
>>
>> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
>>
>>>
>>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>>>
>>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>>>
>>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>>>
>>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>>>
>>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>>>
>>>> What do I have to do to make this compile?
>>>>
>>>> I know very little about C programming. Any help will be greatly appreciated.
>>>>
>>>> Best regards
>>>>
>>>> William
>>>
>>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>>>
>>> -DrD-
>>>
>>
>

From petr.pchelko at oracle.com  Tue Dec 10 07:22:08 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 10 Dec 2013 19:22:08 +0400
Subject: Dragging an image from firefox browser works but not Google
	Chrome with Java 7
In-Reply-To: <52A71A18.8030607@fastmail.fm>
References: <52A71A18.8030607@fastmail.fm>
Message-ID: <9352D2E0-61BF-4F32-9490-7339E114838E@oracle.com>

Hello, Paul.

Looks like the bug is indeed reproducible on 7u45, however my testing shows that JDK-8 works well.
Could you please check your test case on JDK 8? It could be downloaded here: https://jdk8.java.net/download.html

Thank you.
With best regards. Petr.

On 10.12.2013, at 17:41, Paul Taylor <paul_t100 at fastmail.fm> wrote:

> Dragging an image from firefox browser works but not Google Chrome, Chrome provides no data flavours when using Java 7 (1.7.0_45) although it works correctly when using Java 6


From javalists at cbfiddle.com  Tue Dec 10 09:42:53 2013
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 10 Dec 2013 09:42:53 -0800
Subject: issues in converting from JDK6 to JDK7
Message-ID: <B0B25A01-9D62-4C37-ABB8-44948D008A6C@cbfiddle.com>

I've waited until now to try to convert my applications to JDK7, and I am pleased at how well things are working.

I encountered two incompatibilities, however:

(1) I found that text rendered via Quaqua looked good (and normal) but text in the same font rendered by my code looked bad. Apparently the default setting for text antialiasing has changed. What is the thinking behind this change? What is the best way for me to accommodate this change? It looks like Quaqua alters the graphics context on every call to drawString. Is this what I should do?

(2) In a JDK6 application, the default values of java.ext.dirs and java.library.path both contain /Library/Java/Extensions and ~/Library/Java/Extensions. That is no longer true for java.library.path, which leads to failures to load Java libraries that contain native code. I can work around by adding /Library/Java/Extensions in a build script, but that approach does not work for ~/Library/Java/Extensions. I guess this is an appbundler issue? Is it an intentional change or a bug?


From david.dehaven at oracle.com  Wed Dec 11 10:49:10 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 11 Dec 2013 10:49:10 -0800
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <52A72DA9.80006@oracle.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
	<52A72DA9.80006@oracle.com>
Message-ID: <F4151888-ABA7-4E7D-AB14-66D6AA667DD6@oracle.com>


That seems to be the best solution if you have Xcode 5 installed, just using xcode-select doesn't always work.

-DrD-

> What I did is to save a copy of usr dir inside Xcode 4 and run
> 
>  bash configure --with-tools-dir=/saved/xcode4/usr/bin/ ...
> 
> --Max
> 
> On 12/10/13, 22:38, Staffan Larsen wrote:
>> 
>> On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:
>> 
>>> Thanks David
>>> 
>>> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.
>> 
>> Having multiple XCode versions installed is also a work-around.
>> 
>> /Staffan
>> 
>>> 
>>> William
>>> 
>>> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
>>> 
>>>> 
>>>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>>>> 
>>>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>>>> 
>>>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>>>> 
>>>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>>>> 
>>>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>>>> 
>>>>> What do I have to do to make this compile?
>>>>> 
>>>>> I know very little about C programming. Any help will be greatly appreciated.
>>>>> 
>>>>> Best regards
>>>>> 
>>>>> William
>>>> 
>>>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>>>> 
>>>> -DrD-
>>>> 
>>> 
>> 


From wmoore40 at gmail.com  Wed Dec 11 10:59:19 2013
From: wmoore40 at gmail.com (William Moore)
Date: Wed, 11 Dec 2013 19:59:19 +0100
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <F4151888-ABA7-4E7D-AB14-66D6AA667DD6@oracle.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
	<52A72DA9.80006@oracle.com>
	<F4151888-ABA7-4E7D-AB14-66D6AA667DD6@oracle.com>
Message-ID: <F3B6E00A-1DC5-48F4-B430-7952EB0CE7C2@gmail.com>

Yes it does. Unfortunately it didn?t work for me:

> /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/common/jni_util_md.c:51: warning: incompatible implicit declaration of built-in function 'strcat'
> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:162,
>                  from /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/java/lang/java_props_macosx.c:35:
> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ',' or '}' before '__attribute__'
> In file included from /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/java/lang/java_props_macosx.h:27,
>                  from /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/java/lang/java_props_macosx.c:37:
> /Users/william/Programming/Java/jdk8/jdk/src/share/native/java/lang/java_props.h:123: warning: no semicolon at end of struct or union
> make[2]: *** [/Users/william/Programming/Java/jdk8/build/macosx-x86_64-normal-server-release/jdk/objs/libjava/java_props_macosx.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [libs-only] Error 2
> make: *** [jdk-only] Error 2

I don?t understand why it is trying to compile Solaris files but I have to go and do some other things now, so I?ll come back and look at it again later.

Thank you all for your help.

William

On 11 Dec 2013, at 7:49pm, David DeHaven <david.dehaven at oracle.com> wrote:

> 
> That seems to be the best solution if you have Xcode 5 installed, just using xcode-select doesn't always work.
> 
> -DrD-
> 
>> What I did is to save a copy of usr dir inside Xcode 4 and run
>> 
>> bash configure --with-tools-dir=/saved/xcode4/usr/bin/ ...
>> 
>> --Max
>> 
>> On 12/10/13, 22:38, Staffan Larsen wrote:
>>> 
>>> On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:
>>> 
>>>> Thanks David
>>>> 
>>>> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.
>>> 
>>> Having multiple XCode versions installed is also a work-around.
>>> 
>>> /Staffan
>>> 
>>>> 
>>>> William
>>>> 
>>>> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
>>>> 
>>>>> 
>>>>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>>>>> 
>>>>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>>>>> 
>>>>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>>>>> 
>>>>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>>>>> 
>>>>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>>>>> 
>>>>>> What do I have to do to make this compile?
>>>>>> 
>>>>>> I know very little about C programming. Any help will be greatly appreciated.
>>>>>> 
>>>>>> Best regards
>>>>>> 
>>>>>> William
>>>>> 
>>>>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>>>>> 
>>>>> -DrD-
>>>>> 
>>>> 
>>> 
> 


From staffan.larsen at oracle.com  Wed Dec 11 11:33:47 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 11 Dec 2013 20:33:47 +0100
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <F3B6E00A-1DC5-48F4-B430-7952EB0CE7C2@gmail.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
	<52A72DA9.80006@oracle.com>
	<F4151888-ABA7-4E7D-AB14-66D6AA667DD6@oracle.com>
	<F3B6E00A-1DC5-48F4-B430-7952EB0CE7C2@gmail.com>
Message-ID: <4D6E717B-D57F-437C-8900-771A621596D9@oracle.com>


On 11 dec 2013, at 19:59, William Moore <wmoore40 at gmail.com> wrote:

> I don?t understand why it is trying to compile Solaris files but I have to go and do some other things now, so I?ll come back and look at it again later.

They aren?t really solaris files. The files in the solaris directory are shared across all unix varieties.

/Staffan

From weijun.wang at oracle.com  Wed Dec 11 17:02:47 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 12 Dec 2013 09:02:47 +0800
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <F3B6E00A-1DC5-48F4-B430-7952EB0CE7C2@gmail.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
	<52A72DA9.80006@oracle.com>
	<F4151888-ABA7-4E7D-AB14-66D6AA667DD6@oracle.com>
	<F3B6E00A-1DC5-48F4-B430-7952EB0CE7C2@gmail.com>
Message-ID: <52A90B37.70705@oracle.com>

james.laskey at oracle.com has a solution to it:
>
> Everything built except for one Apple header.
>
> /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSUserNotification.h:16
>
>   NSUserNotificationActivationTypeReplied NS_AVAILABLE(10_9, NA) = 3
>
> I changed to
>
>   NSUserNotificationActivationTypeReplied /* NS_AVAILABLE(10_9, NA) */ = 3
>
> Otherwise we get a __attribute__ instead of ',' or '}' error.
>
> Everything ran fine after that.
>
> Cheers,
>
> -- Jim



On 12/12/2013 2:59, William Moore wrote:
> Yes it does. Unfortunately it didn?t work for me:
>
>> /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/common/jni_util_md.c:51: warning: incompatible implicit declaration of built-in function 'strcat'
>> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:162,
>>                   from /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/java/lang/java_props_macosx.c:35:
>> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ',' or '}' before '__attribute__'
>> In file included from /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/java/lang/java_props_macosx.h:27,
>>                   from /Users/william/Programming/Java/jdk8/jdk/src/solaris/native/java/lang/java_props_macosx.c:37:
>> /Users/william/Programming/Java/jdk8/jdk/src/share/native/java/lang/java_props.h:123: warning: no semicolon at end of struct or union
>> make[2]: *** [/Users/william/Programming/Java/jdk8/build/macosx-x86_64-normal-server-release/jdk/objs/libjava/java_props_macosx.o] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[1]: *** [libs-only] Error 2
>> make: *** [jdk-only] Error 2
>
> I don?t understand why it is trying to compile Solaris files but I have to go and do some other things now, so I?ll come back and look at it again later.
>
> Thank you all for your help.
>
> William
>
> On 11 Dec 2013, at 7:49pm, David DeHaven <david.dehaven at oracle.com> wrote:
>
>>
>> That seems to be the best solution if you have Xcode 5 installed, just using xcode-select doesn't always work.
>>
>> -DrD-
>>
>>> What I did is to save a copy of usr dir inside Xcode 4 and run
>>>
>>> bash configure --with-tools-dir=/saved/xcode4/usr/bin/ ...
>>>
>>> --Max
>>>
>>> On 12/10/13, 22:38, Staffan Larsen wrote:
>>>>
>>>> On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:
>>>>
>>>>> Thanks David
>>>>>
>>>>> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.
>>>>
>>>> Having multiple XCode versions installed is also a work-around.
>>>>
>>>> /Staffan
>>>>
>>>>>
>>>>> William
>>>>>
>>>>> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
>>>>>
>>>>>>
>>>>>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>>>>>>
>>>>>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>>>>>>
>>>>>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>>>>>>
>>>>>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>>>>>>
>>>>>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>>>>>>
>>>>>>> What do I have to do to make this compile?
>>>>>>>
>>>>>>> I know very little about C programming. Any help will be greatly appreciated.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> William
>>>>>>
>>>>>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>>>>>>
>>>>>> -DrD-
>>>>>>
>>>>>
>>>>
>>
>

From paul_t100 at fastmail.fm  Thu Dec 12 08:14:03 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Thu, 12 Dec 2013 16:14:03 +0000
Subject: Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items
	are always in English whatever set as Preferred Language
Message-ID: <52A9E0CB.4080707@fastmail.fm>

Using the Apple menu (Apple.laf.useScreenMenuBar) the special menu items 
are always in English whatever set as Preferred Language

OSX:System Preferences:Language and Region:Preferred Languages

i.e it stills say

Preferences...
Show All
Hide Others
  etc

in the first menu (my own menu items using my own resource bundle are fine)

instead of:

Pr?f?rences
Tout afficher
Masquer les autres

even if change preferred language from English to French and reboot

This works properly using Java 6

Is this a known bug, is quite problematic because it makes Java 
applications look rather amateurish in non-english env.

Paul



From paul_t100 at fastmail.fm  Thu Dec 12 12:12:06 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Thu, 12 Dec 2013 20:12:06 +0000
Subject: On OSX with Editable combo box the button is not aligned correctly
	with the combobox field
Message-ID: <52AA1896.7050900@fastmail.fm>

With Editable combo box the button is not aligned correctly with the 
combobox field, at least I don't think so I'm struggling to find an 
example of editable combo in a native OSX application.
Its worse using size variant small, with non editable combobox its fine.

Same problem on Java 7 and Java 8

This screenshot shows three cases
http://www.jthink.net/jaikoz/images/combos%20not%20aligned.jpg

Language, editable small (JComponent.sizeVariant)
Script, no editable small
Genre, editable normal


From anthony.petrov at oracle.com  Thu Dec 12 12:39:47 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 00:39:47 +0400
Subject: On OSX with Editable combo box the button is not aligned correctly
	with the combobox field
In-Reply-To: <52AA1896.7050900@fastmail.fm>
References: <52AA1896.7050900@fastmail.fm>
Message-ID: <52AA1F13.1050301@oracle.com>

Hi Paul,

Can you please file bugs at http://bugs.sun.com/ for all the issues that 
you encounter?

--
best regards,
Anthony

On 12/13/2013 12:12 AM, Paul Taylor wrote:
> With Editable combo box the button is not aligned correctly with the
> combobox field, at least I don't think so I'm struggling to find an
> example of editable combo in a native OSX application.
> Its worse using size variant small, with non editable combobox its fine.
>
> Same problem on Java 7 and Java 8
>
> This screenshot shows three cases
> http://www.jthink.net/jaikoz/images/combos%20not%20aligned.jpg
>
> Language, editable small (JComponent.sizeVariant)
> Script, no editable small
> Genre, editable normal
>

From paul_t100 at fastmail.fm  Fri Dec 13 03:49:42 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 13 Dec 2013 11:49:42 +0000
Subject: On OSX with Editable combo box the button is not aligned correctly
	with the combobox field
In-Reply-To: <52AA1F13.1050301@oracle.com>
References: <52AA1896.7050900@fastmail.fm> <52AA1F13.1050301@oracle.com>
Message-ID: <52AAF456.5080707@fastmail.fm>

On 12/12/2013 20:39, Anthony Petrov wrote:
> Hi Paul,
>
> Can you please file bugs at http://bugs.sun.com/ for all the issues 
> that you encounter?
Okay, Ive submitted bug reports for the editablecombo, and Apple menu 
bar bugs.
I'll go through the others when I can.

Paul

From anthony.petrov at oracle.com  Fri Dec 13 04:24:06 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 16:24:06 +0400
Subject: On OSX with Editable combo box the button is not aligned correctly
	with the combobox field
In-Reply-To: <52AAF456.5080707@fastmail.fm>
References: <52AA1896.7050900@fastmail.fm> <52AA1F13.1050301@oracle.com>
	<52AAF456.5080707@fastmail.fm>
Message-ID: <52AAFC66.2020303@oracle.com>

Thanks.

--
best regards,
Anthony

On 12/13/2013 03:49 PM, Paul Taylor wrote:
> On 12/12/2013 20:39, Anthony Petrov wrote:
>> Hi Paul,
>>
>> Can you please file bugs at http://bugs.sun.com/ for all the issues
>> that you encounter?
> Okay, Ive submitted bug reports for the editablecombo, and Apple menu
> bar bugs.
> I'll go through the others when I can.
>
> Paul

From damarasekara at typefi.com  Mon Dec 16 20:11:05 2013
From: damarasekara at typefi.com (Dinesh Amarasekara)
Date: Tue, 17 Dec 2013 14:11:05 +1000
Subject: Signing Mac OS X Apps
Message-ID: <CALRdcwzvVWGOKX0QCrMxUA1s45681jd3vAYcfTXz-ULMA8+9Jg@mail.gmail.com>

Hi,

I have bundled a java application using appbundler. But when I try to sign
the bundle it gives me the following error.

JavaAppLauncher malformed object (unknown load command 9)

Any input for this highly appreciated.

Thanks And Best Regards,
Dinesh.

PS : I ran the following to sign the bundle.

codesign -s "3rd Party Mac Developer Application: My Application
(AAABBBCCC)" "My Application.app"

-- 

*Dinesh Amarasekara * \  Typefi Systems Pty Ltd

Software Engineer  \  Research and Development

+61 7-3102-5444  \  damarasekara at typefi.com



*Eco-Tip: *Please consider the environment before printing this email

From paul_t100 at fastmail.fm  Tue Dec 17 01:12:12 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Tue, 17 Dec 2013 09:12:12 +0000
Subject: Signing Mac OS X Apps
In-Reply-To: <CALRdcwzvVWGOKX0QCrMxUA1s45681jd3vAYcfTXz-ULMA8+9Jg@mail.gmail.com>
References: <CALRdcwzvVWGOKX0QCrMxUA1s45681jd3vAYcfTXz-ULMA8+9Jg@mail.gmail.com>
Message-ID: <52B0156C.7000103@fastmail.fm>

On 17/12/2013 04:11, Dinesh Amarasekara wrote:
> Hi,
>
> I have bundled a java application using appbundler. But when I try to sign
> the bundle it gives me the following error.
>
> JavaAppLauncher malformed object (unknown load command 9)
>
> Any input for this highly appreciated.
>
> Thanks And Best Regards,
> Dinesh.
>
> PS : I ran the following to sign the bundle.
>
> codesign -s "3rd Party Mac Developer Application: My Application
> (AAABBBCCC)" "My Application.app"
>
I think you have to use the --deep option when signing now
After signing you can verify it was signed correctly using

/usr/bin/codesign --verify --deep  --verbose "My Application.app"

which will highlight any problems.

Paul

From damarasekara at typefi.com  Tue Dec 17 16:26:17 2013
From: damarasekara at typefi.com (Dinesh Amarasekara)
Date: Wed, 18 Dec 2013 10:26:17 +1000
Subject: Signing Mac OS X Apps
In-Reply-To: <52B0156C.7000103@fastmail.fm>
References: <CALRdcwzvVWGOKX0QCrMxUA1s45681jd3vAYcfTXz-ULMA8+9Jg@mail.gmail.com>
	<52B0156C.7000103@fastmail.fm>
Message-ID: <CALRdcwziavSgK9xjb04oJBqnapbSiGAW2h5TEFt+A_MevtnLGg@mail.gmail.com>

Hi Paul,

Thanks for this input. To verify it, I should sign the app first I guess.
However it gives me the error JavaAppLauncher malformed object (unknown
load command 9) when I try to do that. So I cannot run verify statement.
Any idea ?

Best Regards,
Dinesh.

From landonf at plausible.coop  Wed Dec 18 11:28:00 2013
From: landonf at plausible.coop (Landon Fuller)
Date: Wed, 18 Dec 2013 14:28:00 -0500
Subject: Building OpenJDK on Mavericks (OS X 10.9)
In-Reply-To: <52A72DA9.80006@oracle.com>
References: <8A93BEA9-88A6-4F78-9465-90B9F605AD51@gmail.com>	<C5BC8448-BFC5-4848-B74D-28A487A4E7C9@oracle.com>	<D7580DFA-4D45-474E-9E79-50594A5A0368@gmail.com>
	<F8EE84A8-64AF-4907-A616-DCC678DE7211@oracle.com>
	<52A72DA9.80006@oracle.com>
Message-ID: <32C43A9F-1336-4375-BB1B-CA6ABF7F41A0@plausible.coop>

MacPorts also provides an llvm-gcc-4.2 port; I was able to use this to build OpenJDK 7u45 with minimal headache.

The only gotcha was Accelerate.framework's reliance on the 'immintrin.h' header. This is a top-level compiler-shipped header that imports subheaders for the intrinsics supported by the current target; it's shipped with clang and more modern versions of GCC, but not with llvm-gcc-4.2.

I worked around this by providing a header search path containing a copy of modern GCC's immintrin.h:
	http://trac.macports.org/browser/users/landonf/openjdk7/dports/java/openjdk7/files/clang-compat-headers?rev=114871

The full build configuration can be found in my openjdk7 Portfile; it's not too hard to read, even if you're unfamiliar with MacPorts:
	http://trac.macports.org/browser/users/landonf/openjdk7/dports/java/openjdk7/Portfile?rev=114871

I'll be merging jtreg, openjdk7, and, if I have time, openjdk8 ports over to MacPorts trunk in the not-too-distant future.

Cheers,
Landon

On Dec 10, 2013, at 10:05 , Weijun Wang <weijun.wang at oracle.com> wrote:

> What I did is to save a copy of usr dir inside Xcode 4 and run
> 
>  bash configure --with-tools-dir=/saved/xcode4/usr/bin/ ...
> 
> --Max
> 
> On 12/10/13, 22:38, Staffan Larsen wrote:
>> 
>> On 10 dec 2013, at 14:48, William Moore <wmoore40 at gmail.com> wrote:
>> 
>>> Thanks David
>>> 
>>> Maybe I can do something with Mountain Lion running in a virtual machine. I?ll investigate that.
>> 
>> Having multiple XCode versions installed is also a work-around.
>> 
>> /Staffan
>> 
>>> 
>>> William
>>> 
>>> On 9 Dec 2013, at 6:26pm, David DeHaven <david.dehaven at oracle.com> wrote:
>>> 
>>>> 
>>>>> Back in September when I had Mountain Lion (OS X 10.8) I was able to build my own version of OpenJDK 7 Update 40.
>>>>> 
>>>>> Now I have Mavericks (OS X 10.9) and it fails to build Hotspot with the error:
>>>>> 
>>>>>> clang: error: argument unused during compilation: '-fcheck-new?
>>>>> 
>>>>> If I comment out the setting of this value in hotspot/make/bsd/makefiles/gcc.make I get other errors like:
>>>>> 
>>>>>> hotspot/src/share/vm/adlc/archDesc.cpp:335:35: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>>>>> 
>>>>> What do I have to do to make this compile?
>>>>> 
>>>>> I know very little about C programming. Any help will be greatly appreciated.
>>>>> 
>>>>> Best regards
>>>>> 
>>>>> William
>>>> 
>>>> Building JDK 8 with Xcode 5 is still a work in progress, I don't expect that effort to be backported to 7u so you might need to scrape up a copy of Xcode 4.6 to build with. The big issue is Xcode 5 does not include gcc and 7u does not build with clang without significant changes.
>>>> 
>>>> -DrD-
>>>> 
>>> 
>> 


From petr.pchelko at oracle.com  Wed Dec 25 05:26:32 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 25 Dec 2013 17:26:32 +0400
Subject: Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items
	are always in English whatever set as Preferred Language
In-Reply-To: <52A9E0CB.4080707@fastmail.fm>
References: <52A9E0CB.4080707@fastmail.fm>
Message-ID: <86057512-15DD-4713-942B-9AC0F45F47D2@oracle.com>

Hello, Paul.

Sorry for the delayed answer.

The problem is that we are relying on Cocoa to create these menu items. However, to properly understand the locale Cocoa needs a special key in the Info.plist file (CFBundleAllowMixedLocalizations). However when you are running a java application as java -jar ? there?s no Info.plist file, so Cocoa does not use the locale preferences and displays everything in English. We have the same problem with a native FileDialog. 

The problem does not seem to be fixable internally in JDK, because there?s no API to tell Cocoa that we wish to use CFBundleAllowMixedLocalizations key. The only possible workaround right now is to use the javafxpackager tool and create a native bundle with your application. Bundled apps have an Info.plist and Cocoa localization works well with them.

For more info please look at the following JDK bug: https://bugs.openjdk.java.net/browse/JDK-8019464 It?s about the FileDialog, but everything there applies to the default menu items as well.

With best regards. Petr.

12 ???. 2013 ?., ? 8:14 ????? ???????, Paul Taylor <paul_t100 at fastmail.fm> ???????(?):

> Using the Apple menu (Apple.laf.useScreenMenuBar) the special menu items are always in English whatever set as Preferred Language
> 
> OSX:System Preferences:Language and Region:Preferred Languages
> 
> i.e it stills say
> 
> Preferences...
> Show All
> Hide Others
> etc
> 
> in the first menu (my own menu items using my own resource bundle are fine)
> 
> instead of:
> 
> Pr?f?rences
> Tout afficher
> Masquer les autres
> 
> even if change preferred language from English to French and reboot
> 
> This works properly using Java 6
> 
> Is this a known bug, is quite problematic because it makes Java applications look rather amateurish in non-english env.
> 
> Paul
> 
> 


From paul_t100 at fastmail.fm  Wed Dec 25 10:23:10 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Wed, 25 Dec 2013 18:23:10 +0000
Subject: Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items
	are always in English whatever set as Preferred Language
In-Reply-To: <86057512-15DD-4713-942B-9AC0F45F47D2@oracle.com>
References: <52A9E0CB.4080707@fastmail.fm>
	<86057512-15DD-4713-942B-9AC0F45F47D2@oracle.com>
Message-ID: <52BB228E.8080407@fastmail.fm>

On 25/12/2013 13:26, Petr Pchelko wrote:
> Hello, Paul.
>
> Sorry for the delayed answer.
>
> The problem is that we are relying on Cocoa to create these menu items. However, to properly understand the locale Cocoa needs a special key in the Info.plist file (CFBundleAllowMixedLocalizations). However when you are running a java application as java -jar ? there?s no Info.plist file, so Cocoa does not use the locale preferences and displays everything in English. We have the same problem with a native FileDialog.
>
> The problem does not seem to be fixable internally in JDK, because there?s no API to tell Cocoa that we wish to use CFBundleAllowMixedLocalizations key. The only possible workaround right now is to use the javafxpackager tool and create a native bundle with your application. Bundled apps have an Info.plist and Cocoa localization works well with them.
>
> For more info please look at the following JDK bug: https://bugs.openjdk.java.net/browse/JDK-8019464 It?s about the FileDialog, but everything there applies to the default menu items as well.
>
> With best regards. Petr.
>
Thanks, my application is actually packaged using this fork of 
appbundler https://bitbucket.org/infinitekind/appbundler

So will
<key>CFBundleAllowMixedLocalizations</key>

work for that as well ?

paul


From petr.pchelko at oracle.com  Wed Dec 25 10:27:32 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 25 Dec 2013 22:27:32 +0400
Subject: Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items
	are always in English whatever set as Preferred Language
In-Reply-To: <52BB228E.8080407@fastmail.fm>
References: <52A9E0CB.4080707@fastmail.fm>
	<86057512-15DD-4713-942B-9AC0F45F47D2@oracle.com>
	<52BB228E.8080407@fastmail.fm>
Message-ID: <0B63D2AA-1585-4CB3-91A3-1E57CD74FECB@oracle.com>

Hello, Paul.

> Thanks, my application is actually packaged using this fork of appbundler https://bitbucket.org/infinitekind/appbundler
> 
> So will
> <key>CFBundleAllowMixedLocalizations</key>
> 
> work for that as well ?
I?ve never tried to use this tool, so I do not know. But you could simply try that just by adding
  <key>CFBundleAllowMixedLocalizations</key>
  <true/>
to the Info.plist of a bundled app. I suppose it should work. 
If it does not the javafxpackager is available in JDK8 EA builds and it works not only for JavaFX but for Swing applications too.

With best regards. Petr.

25 ???. 2013 ?., ? 10:23 ????? ???????, Paul Taylor <paul_t100 at fastmail.fm> ???????(?):

> On 25/12/2013 13:26, Petr Pchelko wrote:
>> Hello, Paul.
>> 
>> Sorry for the delayed answer.
>> 
>> The problem is that we are relying on Cocoa to create these menu items. However, to properly understand the locale Cocoa needs a special key in the Info.plist file (CFBundleAllowMixedLocalizations). However when you are running a java application as java -jar ? there?s no Info.plist file, so Cocoa does not use the locale preferences and displays everything in English. We have the same problem with a native FileDialog.
>> 
>> The problem does not seem to be fixable internally in JDK, because there?s no API to tell Cocoa that we wish to use CFBundleAllowMixedLocalizations key. The only possible workaround right now is to use the javafxpackager tool and create a native bundle with your application. Bundled apps have an Info.plist and Cocoa localization works well with them.
>> 
>> For more info please look at the following JDK bug: https://bugs.openjdk.java.net/browse/JDK-8019464 It?s about the FileDialog, but everything there applies to the default menu items as well.
>> 
>> With best regards. Petr.
>> 
> Thanks, my application is actually packaged using this fork of appbundler https://bitbucket.org/infinitekind/appbundler
> 
> So will
> <key>CFBundleAllowMixedLocalizations</key>
> 
> work for that as well ?
> 
> paul


From krueger at lesspain.de  Sun Dec 29 05:43:49 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sun, 29 Dec 2013 14:43:49 +0100
Subject: Bring Java windows into foreground when dragging over them
Message-ID: <CAEnqZEU1LQNvyaaCt8XtiPNVPuTE+CrmJ-CcVQPObD2OE+uoKw@mail.gmail.com>

Hi,

when I drag something over a Finder window that is partially in the
background it automatically brings itself in the background after a
short delay. Is this something I have to specifically program into my
Java application or is there some global flag/property to activate
this behavior or anything else I have to know to achieve this
properly?

Thanks,

Robert