From paul_t100 at fastmail.fm  Fri Nov  1 02:10:54 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 01 Nov 2013 09:10:54 +0000
Subject: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5
In-Reply-To: <B725A36D-08A1-4239-BFA5-59E1F475584E@gmail.com>
References: <52717C3A.9030404@fastmail.fm>	<5F1AEAA7-F082-4877-AAE7-EE05ABBB567C@gmail.com>	<5272F16B.8020500@fastmail.fm>
	<B725A36D-08A1-4239-BFA5-59E1F475584E@gmail.com>
Message-ID: <5273701E.2090003@fastmail.fm>

On 01/11/2013 01:41, Michael Hall wrote:
> On Oct 31, 2013, at 7:10 PM, Paul Taylor wrote:
>
>> On 31/10/2013 21:49, Michael Hall wrote:
>>> On Oct 30, 2013, at 4:38 PM, Paul Taylor wrote:
>>>
>>>> /Applications/Jaikoz.app/Contents/MacOS/Jaikoz
>>> I'm assuming this is the appbundler JavaAppLauncher. Which branch? java.net project or infinitekind? Which OS version was it built on?
>> Ah, I think you have it.
>>
>> It was the latest version of infinitekind on mavericks, and now I remember change something in the appbundler build file because it couldn't find some 10.7 files, is it possible these files on 10.9
> is it possible these files are not on 10.9? I would think some incompatibility is possible.
> You could maybe try building the native executable on 10.7 instead of 10.9. If it works, you have one executable that works for all. Otherwise you might have to resolve the incompatibility.
> For infinitekind, or both JavaAppLauncher projects, figuring out what the incompatibility is might be appreciated anyhow.
>
Hi Michael

Sorry that sentence didn't make much sense, I meant to say 'is it 
possible to install the missing files on OSX 10.9 so that appbundler 
builds without modification.'

Anyway, I have found my mistake in the build.xml for appbundler i modified

<arg value="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"/>
<arg value="-mmacosx-version-min=10.7"/>
       

to

<arg value="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk"/>
<arg value="-mmacosx-version-min=10.8"/>


I should have just changed the first line, and left the second line alone

<arg value="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk"/>
<arg value="-mmacosx-version-min=10.7"/>



Building my application using this version of Appbundler it now works 
okay on 10.7, 10.8 and 10.9

Ive looked at the Infinitekinds Appbundler and this changed has already 
been committed, but unfortunately that occurred after I downloaded it.

So sorry stupid mistake on my part but this backups my unanswered post 
on the Appbundler mailing list that it would be useful if Infinitekind 
made a prebuilt download available to help those of us who don't really 
understand non java stuff, and also had their own mailing list/bug 
tracker as there is no way to communicate on bitbucket except committing 
code and commenting on code, if that was the case I would have asked 
someone instead of blindly changing the build.xml without understanding 
what I was doing.

Paul

Paul




From christopherbrown06 at gmail.com  Fri Nov  1 09:33:52 2013
From: christopherbrown06 at gmail.com (Christopher Brown)
Date: Fri, 1 Nov 2013 17:33:52 +0100
Subject: File watching on Oracle JDK on Mac OS X and other platforms
Message-ID: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>

Hello,

As I understand it, the file watcher service introduced with JDK 7 uses
native (near real-time) notifications on Windows and Linux, but polling on
Mac OS X.

First off, is this correct?

Second, if it is, what is the polling interval on Mac OS X (and can it be
configured)?

(I originally posted this question to java-dev at lists.apple.com but reposted
here following a reply on that list).

Thanks,
Christopher

From tim.howe at bloodhoundcbc.com  Fri Nov  1 11:01:50 2013
From: tim.howe at bloodhoundcbc.com (Tim Howe)
Date: Fri, 1 Nov 2013 13:01:50 -0500
Subject: FullScreen (Exclusive) Swing Components Fail to Receive
	Keyboard Input on Java 7 on Mac OS X (Mountain) Lion
In-Reply-To: <6397C2AB-0364-4DEB-810D-82A7336F0B8C@oracle.com>
Message-ID: <CE996400.369%tim.howe@bloodhoundcbc.com>

On 10/30/13 1:05 PM, "Leonid Romanov" <leonid.romanov at oracle.com> wrote:

>I've just pushed the fix for this issue. Should appear in main JDK 8 repo
>after a while.

Thanks so much Leonid.

I'd love to try building with this patch and testing our application.  Is
it the one at 
<URL:http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/jdk.patch>?
And, I'm a little bit unfamiliar with the process so what timeframe (just
days vs weeks vs months) is "a while" as far as appearing in the repo?

Is there any chance this might get dropped into a future JDK 7 update as
well?  It appears the original bug was introduced in a JDK 7 update.

Thanks,
Tim



This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information.  If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message.  Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc.

From paul_t100 at fastmail.fm  Fri Nov  1 13:00:51 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 01 Nov 2013 20:00:51 +0000
Subject: Specifying splash screen in bundle appears to completely screw up
	using FileDialog
Message-ID: <52740873.8090006@fastmail.fm>

After fixing a load of Java 7 related problems the last two days I was 
all set to do a new release of my application, but when I did final 
check of functionality I noticed that when using FileDialogs they were 
opening a slightly different view (not FileDialog not JFileChooser) and 
they were indicating busy whenever I selected a folder, and they stayed 
busy unless I selected another folder and the select the first folder 
again. this was  major regression so I spent all afternoon checking my 
FileDialog related code which had been changed looking for what I could 
have changed that would cause this, nothing seemed to fix it.

So I then started rebuilding my code from different svn checkins to try 
and find out where it goes wrong, and the culprit was adding a splash 
screen to the application bundle !

I did have this in appbundle ant file (and I'm sure I've specified it 
correctly because the application did correctly show the splash screen 
when built with this included )

<option value="-splash:$APP_ROOT/Contents/Java/splash.png"/>

simply removing it and rebuilding and FileDialog now works as intended, 
and Ive added it and taken it out and rebuilt each time to check this 
because I couldn't believe it first time.

How the two relate I do not know but I would assume splash screens are 
pretty common, and the link with FileDialogs is so obscure it will be 
difficult for developers to link the issues.

I then found
     https://bugs.openjdk.java.net/browse/JDK-8009203

which looks to be the same issue, but the comment
       'The issue exists from the jdk7u6 on OS X, so it is not a 
regression'
make no sense, it is  a regression if moving from Java 6 to Java 7

And the comment
           'It is unlikely that the client would notice the problem as 
it's quite unusual to open the FileChooser immediately after the 
application loads.'
used to justify no fix until jdk 9 is incorrect, the problem occurs 
however long you wait. This really should be fixed for Jdk 8 at least IMO.

thanks Paul

From paul_t100 at fastmail.fm  Fri Nov  1 13:24:26 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 01 Nov 2013 20:24:26 +0000
Subject: Moving around Jtable with cursor key balnks out values
In-Reply-To: <5270FA82.10401@fastmail.fm>
References: <526C19D8.2060003@fastmail.fm>	<33714D41-2083-4B02-93AD-9B315C162837@tagtraum.com>	<5270F7FE.9000604@fastmail.fm>
	<5270FA82.10401@fastmail.fm>
Message-ID: <52740DFA.8080806@fastmail.fm>

On 30/10/2013 12:24, Paul Taylor wrote:
> On 30/10/2013 12:13, Paul Taylor wrote:
>> With Java 7 on OSX I find that as I move around my JTable cells with 
>> cursor keys it causes it to blank out every field in goes into.
>> Adding:
>> table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE)
>>
>> stops that issue happening, but then I have to press 'Enter' key to 
>> start editing.
>>
>> What I want to happen is that cursor keys just move the cursor 
>> without editing, and pressing any other key will start editing in 
>> that field. i.e I move to a field and press 'd', then will be 
>> displayed in the field. This is what happened in Java 6 on OSX 
>> (Quaqua) and with Java 7 on Windows.
>>
>>
>> Paul
>>
>>
> Apparently a bug was submitted for this, see
>
> http://stackoverflow.com/questions/11553197/spurious-calls-to-setvalueat-with-jtables-in-java-7-on-os-x-lion 
>
>
> but seems to have disappeared without being fixed, is it still in JIRA ?
>
> Paul
>
I found the issue, once again the analysis that decides to defer to this 
Java 9 is IMO poor
          https://bugs.openjdk.java.net/browse/JDK-8025126


The customer submitted workaround of using

putClientProperty("JTable.autoStartsEdit", Boolean.FALSE);

is not a useful workaround for me and many others.

I had to check for empty values in setValue() method of my model instead 
but this causes other problems such as now the cannot explicity set a 
value to blank because their modification gets ignored. Surely this 
terribly buggy behaviour is higher priority than some of the other hings 
being fixed.

Sorry to be complaining because in general Im very positive about Java 7 
on Mac, but at least someone complains directly about these issue I 
imagine they will remain low priority

Paul


From paul_t100 at fastmail.fm  Fri Nov  1 13:33:36 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 01 Nov 2013 20:33:36 +0000
Subject: Specifying splash screen in bundle appears to completely screw
	up using FileDialog
In-Reply-To: <52740873.8090006@fastmail.fm>
References: <52740873.8090006@fastmail.fm>
Message-ID: <52741020.5070807@fastmail.fm>

On 01/11/2013 20:00, Paul Taylor wrote:
> After fixing a load of Java 7 related problems the last two days I was 
> all set to do a new release of my application, but when I did final 
> check of functionality I noticed that when using FileDialogs they were 
> opening a slightly different view (not FileDialog not JFileChooser) 
> and they were indicating busy whenever I selected a folder, and they 
> stayed busy unless I selected another folder and the select the first 
> folder again. this was  major regression so I spent all afternoon 
> checking my FileDialog related code which had been changed looking for 
> what I could have changed that would cause this, nothing seemed to fix 
> it.
>
> So I then started rebuilding my code from different svn checkins to 
> try and find out where it goes wrong, and the culprit was adding a 
> splash screen to the application bundle !
>
> I did have this in appbundle ant file (and I'm sure I've specified it 
> correctly because the application did correctly show the splash screen 
> when built with this included )
>
> <option value="-splash:$APP_ROOT/Contents/Java/splash.png"/>
>
> simply removing it and rebuilding and FileDialog now works as 
> intended, and Ive added it and taken it out and rebuilt each time to 
> check this because I couldn't believe it first time.
>
> How the two relate I do not know but I would assume splash screens are 
> pretty common, and the link with FileDialogs is so obscure it will be 
> difficult for developers to link the issues.
>
> I then found
>     https://bugs.openjdk.java.net/browse/JDK-8009203
>
> which looks to be the same issue, but the comment
>       'The issue exists from the jdk7u6 on OS X, so it is not a 
> regression'
> make no sense, it is  a regression if moving from Java 6 to Java 7
>
> And the comment
>           'It is unlikely that the client would notice the problem as 
> it's quite unusual to open the FileChooser immediately after the 
> application loads.'
> used to justify no fix until jdk 9 is incorrect, the problem occurs 
> however long you wait. This really should be fixed for Jdk 8 at least 
> IMO.
>
> thanks Paul
>
This issue  may also be related 
https://bugs.openjdk.java.net/browse/JDK-8020681

Paul

From paul_t100 at fastmail.fm  Fri Nov  1 13:48:03 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 01 Nov 2013 20:48:03 +0000
Subject: Specifying splash screen in bundle appears to completely screw
	up using FileDialog
In-Reply-To: <52741020.5070807@fastmail.fm>
References: <52740873.8090006@fastmail.fm> <52741020.5070807@fastmail.fm>
Message-ID: <52741383.1080307@fastmail.fm>

On 01/11/2013 20:33, Paul Taylor wrote:
> On 01/11/2013 20:00, Paul Taylor wrote:
>> After fixing a load of Java 7 related problems the last two days I 
>> was all set to do a new release of my application, but when I did 
>> final check of functionality I noticed that when using FileDialogs 
>> they were opening a slightly different view (not FileDialog not 
>> JFileChooser) and they were indicating busy whenever I selected a 
>> folder, and they stayed busy unless I selected another folder and the 
>> select the first folder again. this was  major regression so I spent 
>> all afternoon checking my FileDialog related code which had been 
>> changed looking for what I could have changed that would cause this, 
>> nothing seemed to fix it.
>>
>> So I then started rebuilding my code from different svn checkins to 
>> try and find out where it goes wrong, and the culprit was adding a 
>> splash screen to the application bundle !
>>
>> I did have this in appbundle ant file (and I'm sure I've specified it 
>> correctly because the application did correctly show the splash 
>> screen when built with this included )
>>
>> <option value="-splash:$APP_ROOT/Contents/Java/splash.png"/>
>>
>> simply removing it and rebuilding and FileDialog now works as 
>> intended, and Ive added it and taken it out and rebuilt each time to 
>> check this because I couldn't believe it first time.
>>
>> How the two relate I do not know but I would assume splash screens 
>> are pretty common, and the link with FileDialogs is so obscure it 
>> will be difficult for developers to link the issues.
>>
>> I then found
>>     https://bugs.openjdk.java.net/browse/JDK-8009203
>>
>> which looks to be the same issue, but the comment
>>       'The issue exists from the jdk7u6 on OS X, so it is not a 
>> regression'
>> make no sense, it is  a regression if moving from Java 6 to Java 7
>>
>> And the comment
>>           'It is unlikely that the client would notice the problem as 
>> it's quite unusual to open the FileChooser immediately after the 
>> application loads.'
>> used to justify no fix until jdk 9 is incorrect, the problem occurs 
>> however long you wait. This really should be fixed for Jdk 8 at least 
>> IMO.
>>
>> thanks Paul
>>
> This issue  may also be related 
> https://bugs.openjdk.java.net/browse/JDK-8020681
>
> Paul
>
Heh, sorry to go on but I found the same issue reported back in December 
2012 and no triage done

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

in the bug tracker  they write

'The FileDialog won't work properly if it's shown while an AWT 
SplashScreen is showing.'

but that is not what the email that the issue is based it does not 
restrict the issue to when the splash screen is showing, this seems to 
have been incorrectly inferred by whoeever adde dto the bugtracker.

Paul




From mik3hall at gmail.com  Fri Nov  1 15:45:03 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 1 Nov 2013 17:45:03 -0500
Subject: File watching on Oracle JDK on Mac OS X and other platforms
In-Reply-To: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
References: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
Message-ID: <B5B47F6B-56AB-4B51-BFA3-FEABE9745AD7@gmail.com>

On Nov 1, 2013, at 11:33 AM, Christopher Brown wrote:

> Hello,
> 
> As I understand it, the file watcher service introduced with JDK 7 uses
> native (near real-time) notifications on Windows and Linux, but polling on
> Mac OS X.
> 
> First off, is this correct?

Yes, polling
> 
> Second, if it is, what is the polling interval on Mac OS X (and can it be
> configured)?

Don't know

This was part of nio.2 for JDK 7. There a couple mailing lists for that.
nio-dev at openjdk.java.net   
nio-discuss at openjdk.java.net    

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter




From dan.xu at oracle.com  Fri Nov  1 17:07:59 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 01 Nov 2013 17:07:59 -0700
Subject: File watching on Oracle JDK on Mac OS X and other platforms
In-Reply-To: <B5B47F6B-56AB-4B51-BFA3-FEABE9745AD7@gmail.com>
References: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
	<B5B47F6B-56AB-4B51-BFA3-FEABE9745AD7@gmail.com>
Message-ID: <5274425F.70905@oracle.com>


On 11/01/2013 03:45 PM, Michael Hall wrote:
> On Nov 1, 2013, at 11:33 AM, Christopher Brown wrote:
>
>> Hello,
>>
>> As I understand it, the file watcher service introduced with JDK 7 uses
>> native (near real-time) notifications on Windows and Linux, but polling on
>> Mac OS X.
>>
>> First off, is this correct?
> Yes, polling
>> Second, if it is, what is the polling interval on Mac OS X (and can it be
>> configured)?
> Don't know
>
> This was part of nio.2 for JDK 7. There a couple mailing lists for that.
> nio-dev at openjdk.java.net
> nio-discuss at openjdk.java.net
>
> Michael Hall
>
> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe
>
> AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
Hi Christopher,

We are aware that polling in Mac platform is not performance-friendly, 
and we are going to enhance it with the native facility provided on Mac 
platform, like kqueue-based WatchService. Thanks!

-Dan


From Alan.Bateman at oracle.com  Sat Nov  2 00:50:01 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 02 Nov 2013 07:50:01 +0000
Subject: File watching on Oracle JDK on Mac OS X and other platforms
In-Reply-To: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
References: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
Message-ID: <5274AEA9.2060105@oracle.com>

On 01/11/2013 16:33, Christopher Brown wrote:
> Hello,
>
> As I understand it, the file watcher service introduced with JDK 7 uses
> native (near real-time) notifications on Windows and Linux, but polling on
> Mac OS X.
>
> First off, is this correct?
>
> Second, if it is, what is the polling interval on Mac OS X (and can it be
> configured)?
>
As Dan mentioned, we do need to add a native implementation for Mac at 
some point (the original Mac port didn't have anything and the polling 
implementation is simple implementation when getting a port going or 
where the operating system doesn't have a facility).

As regards configuring the polling interval then it can be done on a per 
watched directory basis via a JDK-specific WatchEvent.Modifier, see 
com.sun.nio.file.SensitivityWatchEventModifier.

-Alan.

From christopherbrown06 at gmail.com  Sat Nov  2 04:22:20 2013
From: christopherbrown06 at gmail.com (Christopher Brown)
Date: Sat, 2 Nov 2013 12:22:20 +0100
Subject: File watching on Oracle JDK on Mac OS X and other platforms
In-Reply-To: <5274AEA9.2060105@oracle.com>
References: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
	<5274AEA9.2060105@oracle.com>
Message-ID: <CAN_qnoNgFKAU9eNm+cgWE6B0LYkcJ=0362K6izk=-+70mfd1JQ@mail.gmail.com>

Thanks Dan and Alan,

I found my answer concerning Windows, Linux, and Solaris here (comment from
Alan):
http://java.dzone.com/news/how-watch-file-system-changes

SensitivityWatchEventModifier does look like what I was looking for.  Is
JDK9 the target for the native Mac implementation?



On 2 November 2013 08:50, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 01/11/2013 16:33, Christopher Brown wrote:
>
>> Hello,
>>
>> As I understand it, the file watcher service introduced with JDK 7 uses
>> native (near real-time) notifications on Windows and Linux, but polling on
>> Mac OS X.
>>
>> First off, is this correct?
>>
>> Second, if it is, what is the polling interval on Mac OS X (and can it be
>> configured)?
>>
>>  As Dan mentioned, we do need to add a native implementation for Mac at
> some point (the original Mac port didn't have anything and the polling
> implementation is simple implementation when getting a port going or where
> the operating system doesn't have a facility).
>
> As regards configuring the polling interval then it can be done on a per
> watched directory basis via a JDK-specific WatchEvent.Modifier, see
> com.sun.nio.file.**SensitivityWatchEventModifier.
>
> -Alan.
>

From mik3hall at gmail.com  Sat Nov  2 07:24:11 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 2 Nov 2013 09:24:11 -0500
Subject: File watching on Oracle JDK on Mac OS X and other platforms
In-Reply-To: <CAN_qnoNgFKAU9eNm+cgWE6B0LYkcJ=0362K6izk=-+70mfd1JQ@mail.gmail.com>
References: <CAN_qnoMS7pMCgXZe39iUJbMOD8AqZC0ZkEgG1Rbqj7UJFS1v3w@mail.gmail.com>
	<5274AEA9.2060105@oracle.com>
	<CAN_qnoNgFKAU9eNm+cgWE6B0LYkcJ=0362K6izk=-+70mfd1JQ@mail.gmail.com>
Message-ID: <B17EBFA9-698D-4938-B105-899D4FED86D5@gmail.com>

I might just mention at this point that my trz package below does attempt a OS X kqueue WatchService. 
It passed nio basic tests but does not successfully get through the LotsOfEvents tests. It has a deadlock issue for that. I haven't figured out how to debug the problem since I am unsure how to debug kqueue and that seems to stop pumping events when the java goes into a wait. 
It is possibly questionable licensing since I started by modeling existing nio classes but in some cases had to make slight changes to my own mostly coped versions.
The kqueue implementation was to be a one of two WatchService I intended for OS X. The second would be based on fsevents which my understanding is might be more suited to larger numbers of files.

The package also includes non-WatchService related nio.2 OS X code for file attribute meta data.

I also added the code for the Apple FileManager extension since it was indicated at some point that this project might be ok with supporting the eawt extensions but possibly not the eio. So I added FileManager to my project. I'm not sure I have seen any additional support for eawt since though- like javadoc. I added a file helper companion class for FileManager, mostly based on LaunchServices API's. Determining applications associated with given file types, opening them with specified applications. 

As I recall, I haven't looked at any of this for a little bit. 

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From paul_t100 at fastmail.fm  Mon Nov  4 01:05:46 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 04 Nov 2013 09:05:46 +0000
Subject: How do I make my Java 7 OSX App draggable on toolbar only ?
In-Reply-To: <527293BC.3020308@fastmail.fm>
References: <527293BC.3020308@fastmail.fm>
Message-ID: <5277636A.40406@fastmail.fm>

On 31/10/2013 17:30, Paul Taylor wrote:
> Things were working okay with Java 6 ( and some custom libs) but now 
> by default a Java 7 application is only movable on Mac if you click 
> near the top of the window (like on Windows), however if I set
>
> toolbar.getRootPane().putClientProperty("apple.awt.draggableWindowBackground") 
>
>
> I can then move the window by dragging on the toolbar. Unfortunately 
> because this property is applied to the rootpane, and then is just one 
> rootpane for the frame that the whole applications is a part of the 
> window moves where-ever I drag on it, I only want to be able to drag 
> on it in the toolbar.
>
> The main part of my application is a JTable and I really don't want 
> the window to be moved when I dragclick here because it causes lots of 
> problems such as I can now no longer reorder by table columns by 
> dragging the table headers because that just moves the whole window. 
> How can I limit movement to either:
>
> 1. Only the JToolbar
> 2. Everywhere except the Jtable
>
> whichever is easiest.
>
> thanks Paul
>
Nevermind I found a solution, I used UnifiedToolbar from 
thehttp://code.google.com/p/macwidgets/ project with Java 6. Since 
moving to Java 7 and no longer using UnifiedToolbar I couldn't see a 
solution but delving into their code simply using WindowsDragger class 
works perfectly well

i.e.

     new WindowsDragger(frame, toolbar);
     new WindowsDragger(frame, statusbar)

In contrast the "apple.awt.draggableWindowBackground" option is only 
really useful if happy for the whole frame to be draggable.

Paul



From hs at tagtraum.com  Mon Nov  4 01:37:36 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 4 Nov 2013 10:37:36 +0100
Subject: How do I make my Java 7 OSX App draggable on toolbar only ?
In-Reply-To: <5277636A.40406@fastmail.fm>
References: <527293BC.3020308@fastmail.fm> <5277636A.40406@fastmail.fm>
Message-ID: <0627FE61-76D6-4A05-8857-C1FAA11CBE76@tagtraum.com>

On Nov 4, 2013, at 10:05 AM, Paul Taylor wrote:
> Nevermind I found a solution, I used UnifiedToolbar from thehttp://code.google.com/p/macwidgets/ project with Java 6. Since moving to Java 7 and no longer using UnifiedToolbar I couldn't see a solution but delving into their code simply using WindowsDragger class works perfectly well
> 
> i.e.
> 
>    new WindowsDragger(frame, toolbar);
>    new WindowsDragger(frame, statusbar)
> 
> In contrast the "apple.awt.draggableWindowBackground" option is only really useful if happy for the whole frame to be draggable.

In other words: it's not useful.
But it would be great, if there was something that worked the way Paul used it originally. I.e. a property that can be set on a panel that makes it so that you can drag the window by dragging a panel/container.

-hendrik

From paul_t100 at fastmail.fm  Mon Nov  4 02:45:40 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 04 Nov 2013 10:45:40 +0000
Subject: How do I make my Java 7 OSX App draggable on toolbar only ?
In-Reply-To: <0627FE61-76D6-4A05-8857-C1FAA11CBE76@tagtraum.com>
References: <527293BC.3020308@fastmail.fm> <5277636A.40406@fastmail.fm>
	<0627FE61-76D6-4A05-8857-C1FAA11CBE76@tagtraum.com>
Message-ID: <52777AD4.7010909@fastmail.fm>

On 04/11/2013 09:37, Hendrik Schreiber wrote:
> On Nov 4, 2013, at 10:05 AM, Paul Taylor wrote:
>> Nevermind I found a solution, I used UnifiedToolbar from thehttp://code.google.com/p/macwidgets/ project with Java 6. Since moving to Java 7 and no longer using UnifiedToolbar I couldn't see a solution but delving into their code simply using WindowsDragger class works perfectly well
>>
>> i.e.
>>
>>     new WindowsDragger(frame, toolbar);
>>     new WindowsDragger(frame, statusbar)
>>
>> In contrast the "apple.awt.draggableWindowBackground" option is only really useful if happy for the whole frame to be draggable.
> In other words: it's not useful.
> But it would be great, if there was something that worked the way Paul used it originally. I.e. a property that can be set on a panel that makes it so that you can drag the window by dragging a panel/container.
>
> -hendrik
Well it can be useful I use

apple.awt.draggableWindowBackground

in my SongKong app, and there is it is fine, but yes the option could really be improved on.

Paul



From alexandr.scherbatiy at oracle.com  Tue Nov  5 03:16:21 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 05 Nov 2013 15:16:21 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5272C1AB.9030202@gmail.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>
Message-ID: <5278D385.2000205@oracle.com>


    Thank you for the review.

   Could you look at the updated fix:
      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/

   - URL is parsed to protocol, host, port, and path parts in the 
LWCToolkit class.
      I checked that URL(protocol, host, port, file) constructor 
correctly handles -1 port value.
   - Only last file name after last '/' in the URL path  is converted to 
@2x name
   - Tests that check correct URL and path translation to @2x names are 
added to the ScalableImageTest

   Thanks,
   Alexandr.


On 11/1/2013 12:46 AM, Peter Levart wrote:
>
> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>> 2. I'm not sure that the proposed getScaledImageName() 
>>> implementation in ScalableToolkitImage works perfectly for URLs like 
>>> this:
>>>
>>> http://www.exampmle.com/dir/image
>>>
>>> In this case it will try to find 2x image here:
>>>
>>> http://www.example at 2x.com/dir/image
>>>
>>> which doesn't look correct.
>>        Fixed. Only path part of a URL is converted to path2x. 
>
> Hi Alexander,
>
> URLs like this:
>
> http://www.example.com/dir.ext/image
>
> will still be translated to:
>
> http://www.example.com/dir at 2x.ext/image
>
>
> I think you need to search for last '.' after the last  '/' in the 
> getScaledImageName();
>
>
> Also the following code has some additional bugs:
>
>   853         static Image toScalableImage(Image image, URL url) {
>   854
>   855             if (url != null && !url.toString().contains("@2x")
>   856                     && !(image instanceof ScalableToolkitImage)) {
>   857                 String protocol = url.getProtocol();
>   858                 String host = url.getHost();
>   859                 String file = url.getPath();
>   860                 String file2x =*host +*getScaledImageName(file);
>   861                 try {
>   862                     URL url2x = new URL(protocol, host, file2x);
>   863                     url2x.openStream();
>   864                     return new ScalableToolkitImage(image, getDefaultToolkit().getImage(url2x));
>   865                 } catch (Exception ignore) {
>   866                 }
>   867             }
>   868             return image;
>   869         }
>
> Why are you prepending *host* to getScaledImageName(file) in line 860? 
> Let's take the following URL for example:
>
> http://www.example.com/dir/image.jpg
>
> protocol = "http"
> host = "www.example.com"
> file = "/dir/image.jpg"
> file2x = "*www.example.com*/dir/image at 2x.jpg"
> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>
>
> You are missing a part in URL (de)construction - the optional port! 
> For example in the following URL:
>
> http://www.example.com:8080/dir/image.jpg
>
> You should extract the port from original URL and use it in new URL 
> construction if present (!= -1).
>
>
> I would also close the stream explicitly after probing for existence 
> of resource rather than delegating to GC which might not be promptly 
> and can cause resource exhaustion (think of MAX. # of open file 
> descriptors):
>
>         try (InputStream probe = url.openStream()) {}
>
>
>
> Regards, Peter
>
>


From alexandr.scherbatiy at oracle.com  Wed Nov  6 05:19:29 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 06 Nov 2013 17:19:29 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <52799DE1.8080906@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
Message-ID: <527A41E1.9020103@oracle.com>

On 11/6/2013 5:39 AM, Jim Graham wrote:
> Why is getScaledInstance() being consulted here?  It seems a misuse of 
> that method.
     We need to introduce a new API that allows developers to return 
scaled images for HiDPI displays.
     Scaled images are just new images N times bigger than the original 
one and created by designers.

     The good way is to allow a user to override a method like 
getScaledImage() which has either scaledFactor or width and height 
parameters and returns necessary scaled images.
     It could look like:
    -----------------
         final Image image1 = ImageIO.read("image1.png");
         final Image image2 = ImageIO.read("image2.png");
         final Image image3 = ImageIO.read("image3.png");

         final int WIDTH = image1.getWidth(null);
         final int HEIGHT = image1.getHeight(null);

         Image image = new BufferedImage(WIDTH, HEIGHT, 
BufferedImage.TYPE_INT_RGB) {
             @Override
             public Image getScaledImage(int width, int height) {
                 if (width < WIDTH && height < HEIGHT) {
                     return this;
                 } else if (width < 2 * WIDTH && height < 2 * HEIGHT) {
                     return image2;
                 } else if (width < 3 * WIDTH && height < 3 * HEIGHT) {
                     return image3;
                 }
             }
         };

         image.getGraphics().drawImage(image1, 0, 0, null);
    -----------------

     But the  getScaledImage(width, height) method looks similar to the 
getScaledInstance(width, height, hints). It also can confuse a user 
which method should be overridden to return
     the scaled version of an image.

    The current fix is based on the CCC request 8011059 where it has 
been approved to use the getScaledInstance(width, height, hints) method 
for this purposes.

> The method was designed to return a rescaled version of the same 
> pixels that you would get if you examined the raw pixels.  You are 
> overriding it to return a different image.  That does not fit in with 
> the original intent of that method as I created it.
>
> It is also causing implementation headaches (read reflection) in the 
> SG2D code to try to use it that way.
      The Image.SCALE_DEFAULT hint is used to retrieve user scaled 
images in the CCC request 8011059.
      That was a wrong idea. There are intersections with the original 
meaning with the SCALE_DEFAULT hint.
      Also there are performance regression and exceptions like OOM or 
IOBE if the getScaledInstance(width, height, hints) is not overridden 
and it is invoked for each image.

      The better way could be to use a new Image hint designed only to 
retrieve scaled images provided by a user.
      I have created the CCC request 8027655 for this.
      Once the request will be approved it will be possible to get rid 
of the reflection usage.

    Thanks,
    Alexandr.

>
> The @2x mechanism should be based on different API.  I guess it would 
> have to be internal-only for 8.0 and could be exposed to allow 
> developers to call it and possibly to be a provider for it in JDK9...
>
>             ...jim
>
> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>
>>     The reflection is used to skip the Image.getScaledInstance() method
>> call if it is not overridden by a user.
>>
>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> The fix looks fine to me in general. But there is at least one issue.
>>> I build you fix and test it:
>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>>> that jdk6 has the same FPS(15) on my system.
>>
>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>> retrieve a scaled image from Image.getScaledInstance() method.
>>     It always uses the ReplicateScaleFilter for images which
>> getScaledInstance() method has not been overridden.
>>     The ReplicateScaleFilter creates a lot of arrays and consumes the
>> CPU during the image parsing.
>>
>>     The better fix would be to introduce the new Image.SCALE_CUSTOM hint
>> which could be used to get a scaled image and does not use filters by
>> default.
>>     But it should be a separated bug with a new CCC request.
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>
>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>> Hi, Alexander,
>>>>>
>>>>> a few comments:
>>>>>
>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>      The isHiDPIImage() method is used to check that the
>>>> drawHiDPIImage should be called like:
>>>>         if (isHiDPIImage(img)) {
>>>>             return drawHiDPIImage(...);
>>>>         }
>>>>
>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>>> this:
>>>>>
>>>>> http://www.exampmle.com/dir/image
>>>>>
>>>>> In this case it will try to find 2x image here:
>>>>>
>>>>> http://www.example at 2x.com/dir/image
>>>>>
>>>>> which doesn't look correct.
>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>> which should be removed.
>>>>        Fixed.
>>>>
>>>>     - devScale is used instead of transform parsing in the
>>>> drawHiDPIImage() method just to not have performance regression more
>>>> than 2 times on HiDPI displays
>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>    Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>
>>>>>>    - Scaled image width and height are transformed according to the
>>>>>> AffineTransform type.
>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>
>>>>>>>   The JCK failures has been resolved:
>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE 
>>>>>>> width
>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>> height,
>>>>>>> hints).
>>>>>>>        leads that an Image filter is not able to create necessary
>>>>>>> arrays.  The fix uses the original image if width or height are 
>>>>>>> equal
>>>>>>> to Integer.MAX_VALUE.
>>>>>>>     - Using Image.SCALE_DEFAULT hint for the getScaledImage(width,
>>>>>>> height, hints) method to get the high resolution image interferes
>>>>>>> with
>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>        method in ToolkitImage in case if a high resolution image is
>>>>>>> not set.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the fix:
>>>>>>>>
>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>
>>>>>>>>   The IMAGE_SCALING rendering hint is added to the RenderingHints
>>>>>>>> class.
>>>>>>>>   Enabling the image scaling rendering hint forces the 
>>>>>>>> SunGraphics2D
>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>
>>>>>>>>   By default the image scaling rendering hint is enabled on HiDPI
>>>>>>>> display and disabled for standard displays.
>>>>>>>>
>>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>>> method and return necessary high resolution image
>>>>>>>>   according to the given image width and height.
>>>>>>>>
>>>>>>>>   For example:
>>>>>>>>   ---------------------
>>>>>>>>         final Image highResolutionImage =
>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>
>>>>>>>>             @Override
>>>>>>>>             public Image getScaledInstance(int width, int height,
>>>>>>>> int
>>>>>>>> hints) {
>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>                 }
>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>> hints);
>>>>>>>>             }
>>>>>>>>         };
>>>>>>>>   ---------------------
>>>>>>>>
>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>
>>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>>> look
>>>>>>>> perfect on Retina displays.
>>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>>> they
>>>>>>>> will be automatically drawn.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>


From Sergey.Bylokhov at oracle.com  Wed Nov  6 15:09:54 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 03:09:54 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <527AB743.8050106@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com>
Message-ID: <527ACC42.6060001@oracle.com>

Hi , Jim.
On 07.11.2013 1:40, Jim Graham wrote:
> On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
>> On 11/6/2013 5:39 AM, Jim Graham wrote:
>>> Why is getScaledInstance() being consulted here?  It seems a misuse of
>>> that method.
>>      We need to introduce a new API that allows developers to return
>> scaled images for HiDPI displays.
>
> Then we should introduce new API.
Well during draw of the image we should request appropriate scale image 
from the user, who possible know better how its image can be scaled.
What can be better, than a method which "Creates a scaled version of 
this image."?
>>      The good way is to allow a user to override a method like
>> getScaledImage() which has either scaledFactor or width and height
>> parameters and returns necessary scaled images.
>
> If that is a new API with new semantics, then I agree.
>
>>      But the  getScaledImage(width, height) method looks similar to the
>> getScaledInstance(width, height, hints). It also can confuse a user
>> which method should be overridden to return
>>      the scaled version of an image.
>
> A better name would help.  I don't think width/height are really the 
> best parameters for such a method since you want an image that can be 
> substituted and the original image has already established an aspect 
> ratio.  A single resolution would have been preferable.
But it can be used independently, if the graphics is scaled in one 
direction. And to allow the user to decide how to scale the picture 
depending on how it will be expanded. And there is no direct 
relationship with retina and its scale factor.

We can move deeper and request here the actual size of the image 
including transform of the graphics (<=TRANSFORM_TRANSLATESCALE). So the 
user can apply IMAGE_SCALING hint to the transformed sg2d and all images 
will have a chance to use custom scale instead of  some scaling from the 
sg2d.
>
> And there are 10 years of potential overrides that developers could 
> have created that could be even worse than the default implementation 
> from a performance perspective.  "Whether or not the method is 
> overridden" is a bad heuristic from the get go and it is much, much 
> more inappropriate to apply to a legacy method that has been in the 
> wild for over a decade. 
If user overrides this method and provides some specific scale algorithm 
is not what we want from the beginning?
"Whether or not the method is overridden" come in to play because 
default scale operation in SG2D and the results of default 
implementation of getScaledInstance is quite similar, but performance is 
extremely different.
So it can be rephrased as "Whether or not the default scale algorithm is 
use", so in the fix we use default from the S2G2 not Image.
>
> The suggestion to add a new hint to a decade old API is unwise. 
> Additionally, the hint requested "SCALE_CUSTOM" could mean anything 
> and is documented so loosely that resolution swapping is only one of 
> an infinite number of responses an application could make.  The spec 
> of that hint also violates the contract of the getScaledInstance() 
> method which states that the returned instance will be of the 
> requested size, but you are planning on returning an image that can 
> have a different size.
It return the image which is rendered to appropriate width and height by 
default. It is not necessary to be always the same sized image. Moreover 
it can be a different size image in case of negative width/height.
This hint will be enabled on the retina device by default, but can be 
enabled by the user as well for any graphics

In general an idea of the fix is: The image know better how it could be 
scaled
  - It could use some pixel replicate scale filters
  - it could use different files images
  - it could redraw itself from scratch if it use vectors graphics.
The only parameters it needed is width and height.

The CUSTOM hint is used for two reasons
  - to use default scale from graphics and to skip default in image
  - to explicitly document new usage of getScaledInstance().

And additionally about compatibility you can compare this version of the 
fix and version of jdk7(where demos was rewritten). If I understand it 
correctly nothing should be changed in demos in the current version of 
the fix(except new x2 images.)
http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk/src/closed/rev/335cba03699d

>
>
>             ...jim
>
>>> The @2x mechanism should be based on different API.  I guess it would
>>> have to be internal-only for 8.0 and could be exposed to allow
>>> developers to call it and possibly to be a provider for it in JDK9...
>>>
>>>             ...jim
>>>
>>> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>>>
>>>>     The reflection is used to skip the Image.getScaledInstance() 
>>>> method
>>>> call if it is not overridden by a user.
>>>>
>>>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>>>> Hi, Alexander.
>>>>> The fix looks fine to me in general. But there is at least one issue.
>>>>> I build you fix and test it:
>>>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>>>>> that jdk6 has the same FPS(15) on my system.
>>>>
>>>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>>>> retrieve a scaled image from Image.getScaledInstance() method.
>>>>     It always uses the ReplicateScaleFilter for images which
>>>> getScaledInstance() method has not been overridden.
>>>>     The ReplicateScaleFilter creates a lot of arrays and consumes the
>>>> CPU during the image parsing.
>>>>
>>>>     The better fix would be to introduce the new Image.SCALE_CUSTOM 
>>>> hint
>>>> which could be used to get a scaled image and does not use filters by
>>>> default.
>>>>     But it should be a separated bug with a new CCC request.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>>>
>>>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>>>
>>>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>>>> Hi, Alexander,
>>>>>>>
>>>>>>> a few comments:
>>>>>>>
>>>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>>>      The isHiDPIImage() method is used to check that the
>>>>>> drawHiDPIImage should be called like:
>>>>>>         if (isHiDPIImage(img)) {
>>>>>>             return drawHiDPIImage(...);
>>>>>>         }
>>>>>>
>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs 
>>>>>>> like
>>>>>>> this:
>>>>>>>
>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>
>>>>>>> In this case it will try to find 2x image here:
>>>>>>>
>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>
>>>>>>> which doesn't look correct.
>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>
>>>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>>>> which should be removed.
>>>>>>        Fixed.
>>>>>>
>>>>>>     - devScale is used instead of transform parsing in the
>>>>>> drawHiDPIImage() method just to not have performance regression more
>>>>>> than 2 times on HiDPI displays
>>>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>    Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>>>
>>>>>>>>    - Scaled image width and height are transformed according to 
>>>>>>>> the
>>>>>>>> AffineTransform type.
>>>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>   Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>>>
>>>>>>>>>   The JCK failures has been resolved:
>>>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE
>>>>>>>>> width
>>>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>>>> height,
>>>>>>>>> hints).
>>>>>>>>>        leads that an Image filter is not able to create necessary
>>>>>>>>> arrays.  The fix uses the original image if width or height are
>>>>>>>>> equal
>>>>>>>>> to Integer.MAX_VALUE.
>>>>>>>>>     - Using Image.SCALE_DEFAULT hint for the 
>>>>>>>>> getScaledImage(width,
>>>>>>>>> height, hints) method to get the high resolution image interferes
>>>>>>>>> with
>>>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>>>        method in ToolkitImage in case if a high resolution 
>>>>>>>>> image is
>>>>>>>>> not set.
>>>>>>>>>
>>>>>>>>>     Thanks,
>>>>>>>>>     Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the fix:
>>>>>>>>>>
>>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>>>
>>>>>>>>>>   The IMAGE_SCALING rendering hint is added to the 
>>>>>>>>>> RenderingHints
>>>>>>>>>> class.
>>>>>>>>>>   Enabling the image scaling rendering hint forces the
>>>>>>>>>> SunGraphics2D
>>>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>>>
>>>>>>>>>>   By default the image scaling rendering hint is enabled on 
>>>>>>>>>> HiDPI
>>>>>>>>>> display and disabled for standard displays.
>>>>>>>>>>
>>>>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>>>>> method and return necessary high resolution image
>>>>>>>>>>   according to the given image width and height.
>>>>>>>>>>
>>>>>>>>>>   For example:
>>>>>>>>>>   ---------------------
>>>>>>>>>>         final Image highResolutionImage =
>>>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>>>
>>>>>>>>>>             @Override
>>>>>>>>>>             public Image getScaledInstance(int width, int 
>>>>>>>>>> height,
>>>>>>>>>> int
>>>>>>>>>> hints) {
>>>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>>>                 }
>>>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>>>> hints);
>>>>>>>>>>             }
>>>>>>>>>>         };
>>>>>>>>>>   ---------------------
>>>>>>>>>>
>>>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>>>
>>>>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>>>>> look
>>>>>>>>>> perfect on Retina displays.
>>>>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>>>>> they
>>>>>>>>>> will be automatically drawn.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Nov  6 17:20:32 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 05:20:32 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <527ADA57.3020803@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com>
Message-ID: <527AEAE0.9000907@oracle.com>

On 07.11.2013 4:09, Jim Graham wrote:
> On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
>> Hi , Jim.
>> On 07.11.2013 1:40, Jim Graham wrote:
>>> On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
>>>> On 11/6/2013 5:39 AM, Jim Graham wrote:
>>>>> Why is getScaledInstance() being consulted here?  It seems a 
>>>>> misuse of
>>>>> that method.
>>>>      We need to introduce a new API that allows developers to return
>>>> scaled images for HiDPI displays.
>>>
>>> Then we should introduce new API.
>> Well during draw of the image we should request appropriate scale image
>> from the user, who possible know better how its image can be scaled.
>> What can be better, than a method which "Creates a scaled version of
>> this image."?
>
> That method "returns a scaled version of *this* image".  It 
> specifically refers to recombining the pixels of the image you would 
> normally get into a new image that, by default, renders at the 
> requested size.
>
> The method has parameters to control the pixel replication/elimination 
> *algorithm*.
Custom hint can be renamed to the BEST_EVER_QUALITY_AS_IMAGE_CANhint and 
write in doc that it is nop by default..
>
> This is a pixel manipulation method pure and simple.  It is also not 
> anywhere documented that it is used by drawImage(), in fact it is 
> documented that the developer call this method and then the result is 
> for the developer to use when they call drawImage().
>
> drawImage() should *NOT* be using this method on its own, and the 
> method should not be involved in choosing alternate designs.  It is 
> for manually resampling an image into a new permanent image.
Why not? We can document that. It is something related to 
|RenderingHints.KEY_INTERPOLATION| which was added as an alternate of 
image hints. But this new hints do not provide possibility to customize 
scaling by the user.
> But it can be used independently, if the graphics is scaled in one
>> direction. And to allow the user to decide how to scale the picture
>> depending on how it will be expanded. And there is no direct
>> relationship with retina and its scale factor.
>
> Currently we only have one case of HiDPI displays (retina) and they 
> have the same pixel scaling in both directions.  It is true that a 
> more complete API would allow for having different resolutions in X 
> and Y, though I'm not sure that will ever be a case needed in practice.
>
>> We can move deeper and request here the actual size of the image
>> including transform of the graphics (<=TRANSFORM_TRANSLATESCALE). So the
>> user can apply IMAGE_SCALING hint to the transformed sg2d and all images
>> will have a chance to use custom scale instead of  some scaling from the
>> sg2d.
>
> I see no reason for this.  We are trying to solve image fidelity for 
> retina displays here, (and hopefully whatever Windows comes up with 
> for similar purposes).  The graphics object already has plenty of 
> information at its disposal to determine how to scale images.
>
> I also don't think we want to take the transform into consideration.  
> We are either "on a hi res display" or we are not on such a display 
> and we should use the variant of the image that is appropriate for 
> that display, even if they are scaled up or down by 2x or more - we 
> don't want an image to suddenly change its look just because they are 
> animating its size (though we could offer a hint in the future that 
> might indicate that they would like us to do that, I don't think it 
> should be the standard or default behavior and I am not sure anyone 
> would ever actually want it in the first place as it creates a visual 
> discontinuity in what should be a smooth seamless process).
>
>>> And there are 10 years of potential overrides that developers could
>>> have created that could be even worse than the default implementation
>>> from a performance perspective.  "Whether or not the method is
>>> overridden" is a bad heuristic from the get go and it is much, much
>>> more inappropriate to apply to a legacy method that has been in the
>>> wild for over a decade.
>> If user overrides this method and provides some specific scale algorithm
>> is not what we want from the beginning?
>
> No, that method is provided for developers to call to get "scaled 
> versions" of an image.  If they've provided some custom code - of 
> unknown performance capability - in their libraries and apps then they 
> have probably not expected this to ever be used in any automatic sense 
> by drawImage().
>
>> "Whether or not the method is overridden" come in to play because
>> default scale operation in SG2D and the results of default
>> implementation of getScaledInstance is quite similar, but performance is
>> extremely different.
>> So it can be rephrased as "Whether or not the default scale algorithm is
>> use", so in the fix we use default from the S2G2 not Image.
> Fact: getScaledInstance() *MUST ALWAYS* return an image that is the 
> requested WxH.  It has no other option.  you can't override that *API 
> REQUIREMENT* in the documentation of a hint.  Read the documentation 
> for it: "A new Image object is returned which will render the image at 
> the specified width and height by default." 
Yes, I see. The image should be "new" and it does not say it should be 
the same object. And content of this "new" image depends from the hint 
which was passed to the method.
> In other words, if you call g.drawImage(thenewscaledinstance, x, y) 
> (i.e. the version with no w,h parameters in the drawImage() signature) 
> then it will draw at the size requested when "thenewscaledinstance" 
> was created.
>
>> In general an idea of the fix is: The image know better how it could be
>> scaled
>>   - It could use some pixel replicate scale filters
>>   - it could use different files images
>>   - it could redraw itself from scratch if it use vectors graphics.
>> The only parameters it needed is width and height.
>
> You are not understanding that it is a new scaled version of *THIS* 
> image.  The pixels from the original image must be used. This is about 
> pixel replication algorithms, not about redesigning a representation.
The user know what pixels contains in its image, and he know how to 
scale its better.
>
>> The CUSTOM hint is used for two reasons
>>   - to use default scale from graphics and to skip default in image
>>   - to explicitly document new usage of getScaledInstance().
>>
>> And additionally about compatibility you can compare this version of the
>> fix and version of jdk7(where demos was rewritten). If I understand it
>> correctly nothing should be changed in demos in the current version of
>> the fix(except new x2 images.)
>> http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk/src/closed/rev/335cba03699d 
>>
>
> I am not suggesting that we change the demos.  I am suggesting that we 
> handle this internally for now with an option to provide a developer 
> to inspect and/or intercept the process when we can create new API.
>
> In other words:
>
> package sun.awt.image;
>
> public interface MultiResImage {
>     public Image getResolutionVariant(float resolution);
> }
>
> public class MacImage extends Image implements MultiResImage {
>     public Image getResolutionVariant(float resolution) {
>         if (resolution >= 2f && ImageAt2x != null) {
>             return ImageAt2x;
>         }
>         return this;
>     }
> }
>
> SG2D.drawImage() {
>     if (img instanceof MultiResImage && dest.pixelscale != 1) {
>         img = ((MultiResImage) 
> img).getResolutionVariant(dest.pixelscale);
>     }
> }
In this example there is a problem. For example we have 2 
BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
  - Image A draws to the image B
  - Image B draws to the window.

When window is moving from the screen x1 to the screen x2 and back. How 
to handle this situation?
In this case getResolutionVariant() can return


Related  discussion:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html
>
>             ...jim
>
>>>>> The @2x mechanism should be based on different API.  I guess it would
>>>>> have to be internal-only for 8.0 and could be exposed to allow
>>>>> developers to call it and possibly to be a provider for it in JDK9...
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>>>>>
>>>>>>     The reflection is used to skip the Image.getScaledInstance()
>>>>>> method
>>>>>> call if it is not overridden by a user.
>>>>>>
>>>>>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Alexander.
>>>>>>> The fix looks fine to me in general. But there is at least one 
>>>>>>> issue.
>>>>>>> I build you fix and test it:
>>>>>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>>>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. 
>>>>>>> Note
>>>>>>> that jdk6 has the same FPS(15) on my system.
>>>>>>
>>>>>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>>>>>> retrieve a scaled image from Image.getScaledInstance() method.
>>>>>>     It always uses the ReplicateScaleFilter for images which
>>>>>> getScaledInstance() method has not been overridden.
>>>>>>     The ReplicateScaleFilter creates a lot of arrays and consumes 
>>>>>> the
>>>>>> CPU during the image parsing.
>>>>>>
>>>>>>     The better fix would be to introduce the new Image.SCALE_CUSTOM
>>>>>> hint
>>>>>> which could be used to get a scaled image and does not use 
>>>>>> filters by
>>>>>> default.
>>>>>>     But it should be a separated bug with a new CCC request.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>
>>>>>>>
>>>>>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>>>>>
>>>>>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>>>>>> Hi, Alexander,
>>>>>>>>>
>>>>>>>>> a few comments:
>>>>>>>>>
>>>>>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>>>>>      The isHiDPIImage() method is used to check that the
>>>>>>>> drawHiDPIImage should be called like:
>>>>>>>>         if (isHiDPIImage(img)) {
>>>>>>>>             return drawHiDPIImage(...);
>>>>>>>>         }
>>>>>>>>
>>>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>>>>> like
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>>>
>>>>>>>>> In this case it will try to find 2x image here:
>>>>>>>>>
>>>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>>>
>>>>>>>>> which doesn't look correct.
>>>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>>>
>>>>>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>>>>>> which should be removed.
>>>>>>>>        Fixed.
>>>>>>>>
>>>>>>>>     - devScale is used instead of transform parsing in the
>>>>>>>> drawHiDPIImage() method just to not have performance regression 
>>>>>>>> more
>>>>>>>> than 2 times on HiDPI displays
>>>>>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>>>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>    Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>>>>>
>>>>>>>>>>    - Scaled image width and height are transformed according to
>>>>>>>>>> the
>>>>>>>>>> AffineTransform type.
>>>>>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>   Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>>   The JCK failures has been resolved:
>>>>>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE
>>>>>>>>>>> width
>>>>>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>>>>>> height,
>>>>>>>>>>> hints).
>>>>>>>>>>>        leads that an Image filter is not able to create 
>>>>>>>>>>> necessary
>>>>>>>>>>> arrays.  The fix uses the original image if width or height are
>>>>>>>>>>> equal
>>>>>>>>>>> to Integer.MAX_VALUE.
>>>>>>>>>>>     - Using Image.SCALE_DEFAULT hint for the
>>>>>>>>>>> getScaledImage(width,
>>>>>>>>>>> height, hints) method to get the high resolution image 
>>>>>>>>>>> interferes
>>>>>>>>>>> with
>>>>>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>>>>>        method in ToolkitImage in case if a high resolution
>>>>>>>>>>> image is
>>>>>>>>>>> not set.
>>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>
>>>>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>>>>>   webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>>>>>
>>>>>>>>>>>>   The IMAGE_SCALING rendering hint is added to the
>>>>>>>>>>>> RenderingHints
>>>>>>>>>>>> class.
>>>>>>>>>>>>   Enabling the image scaling rendering hint forces the
>>>>>>>>>>>> SunGraphics2D
>>>>>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>>>>>
>>>>>>>>>>>>   By default the image scaling rendering hint is enabled on
>>>>>>>>>>>> HiDPI
>>>>>>>>>>>> display and disabled for standard displays.
>>>>>>>>>>>>
>>>>>>>>>>>>   User can override the getScaledInstance(width, height, 
>>>>>>>>>>>> hints)
>>>>>>>>>>>> method and return necessary high resolution image
>>>>>>>>>>>>   according to the given image width and height.
>>>>>>>>>>>>
>>>>>>>>>>>>   For example:
>>>>>>>>>>>>   ---------------------
>>>>>>>>>>>>         final Image highResolutionImage =
>>>>>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>>>>>
>>>>>>>>>>>>             @Override
>>>>>>>>>>>>             public Image getScaledInstance(int width, int
>>>>>>>>>>>> height,
>>>>>>>>>>>> int
>>>>>>>>>>>> hints) {
>>>>>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>>>>>                     return (width <= WIDTH && height <= 
>>>>>>>>>>>> HEIGHT)
>>>>>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>>>>>                 }
>>>>>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>>>>>> hints);
>>>>>>>>>>>>             }
>>>>>>>>>>>>         };
>>>>>>>>>>>>   ---------------------
>>>>>>>>>>>>
>>>>>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>>>>>
>>>>>>>>>>>>   There are no significant changes in the Java2D demo to 
>>>>>>>>>>>> make it
>>>>>>>>>>>> look
>>>>>>>>>>>> perfect on Retina displays.
>>>>>>>>>>>>   It needs only to put necessary images with the @2x 
>>>>>>>>>>>> postfix and
>>>>>>>>>>>> they
>>>>>>>>>>>> will be automatically drawn.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Nov  6 18:15:36 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 06:15:36 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <527AF470.1050300@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
	<527AF470.1050300@oracle.com>
Message-ID: <527AF7C8.3000007@oracle.com>

On 07.11.2013 6:01, Jim Graham wrote:
>
>
> On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
>>> In other words:
>>>
>>> package sun.awt.image;
>>>
>>> public interface MultiResImage {
>>>     public Image getResolutionVariant(float resolution);
>>> }
>>>
>>> public class MacImage extends Image implements MultiResImage {
>>>     public Image getResolutionVariant(float resolution) {
>>>         if (resolution >= 2f && ImageAt2x != null) {
>>>             return ImageAt2x;
>>>         }
>>>         return this;
>>>     }
>>> }
>>>
>>> SG2D.drawImage() {
>>>     if (img instanceof MultiResImage && dest.pixelscale != 1) {
>>>         img = ((MultiResImage)
>>> img).getResolutionVariant(dest.pixelscale);
>>>     }
>>> }
>> In this example there is a problem. For example we have 2
>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>   - Image A draws to the image B
>>   - Image B draws to the window.
>>
>> When window is moving from the screen x1 to the screen x2 and back. How
>> to handle this situation?
>> In this case getResolutionVariant() can return
>>
>>
>> Related  discussion:
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html 
>>
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html 
>>
>
> How does calling getScaledInstance() deal with that?  Note the above 
> was simply to demonstrate the visibility of the interface, not to be a 
> complete implementation...
For example:
  - getScaledInstance() will be called() when image B will be painted to 
the window with scale x2.
  - Inside B.getScaledInstance() the user can create BufferedImage C
  - get graphics from C and set new render hint to IMAGE_SCALING_ON ans 
set scalex2.
  - Apply to C absolutely the same rendering  which was used in B.
  - getScaledInstance() will be called for A.

>
>             ...jim


-- 
Best regards, Sergey.


From hs at tagtraum.com  Thu Nov  7 02:46:34 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 11:46:34 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527A41E1.9020103@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
Message-ID: <D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>

> 
>> 
>> The @2x mechanism should be based on different API.  I guess it would have to be internal-only for 8.0 and could be exposed to allow developers to call it and possibly to be a provider for it in JDK9...


PLEASE, PLEASE don't make us wait until JDK9 for something that worked really well in Apple's JDK6.

-hendrik

From hs at tagtraum.com  Thu Nov  7 04:37:17 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 13:37:17 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <CAFvQSYRaVcybAu8R=UuC_ksgYORtFCouiNeop+C_dOB-NU=GdA@mail.gmail.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<CAFvQSYRaVcybAu8R=UuC_ksgYORtFCouiNeop+C_dOB-NU=GdA@mail.gmail.com>
Message-ID: <EC8D7C7D-6A51-4E21-9D68-0ADF04220B52@tagtraum.com>

On Nov 7, 2013, at 1:03 PM, Clemens Eisserer wrote:

>> PLEASE, PLEASE don't make us wait until JDK9 for something that worked really well in Apple's JDK6.
> 
> An internal API doesn't mean you can't use it with JDK8, only that it
> is not part of the default API (which is more or less the same as with
> Apple's JDK6).

Admittedly, I didn't read through the whole thread ? moving the @2x naming to JDK9 just caught my eye.

> However wouldn't it better to wait for an early JDK8 fetaure update,
> instead of breaking the Image interface with an un-sound design
> forever?

Right, I forgot, Java is like Windows 32. Things stick around forever. ;-)

No, but seriously, proper Retina support is essential for the desktop. You can't ship a consumer application these days that does not support it.
To me it's one of the biggest obstacles for Java7 adoption on OS X.

As long as I have a way to create or load HiDPI images that I can use throughout my application (say e.g. in a JLabel) in Java8 or better Java7, I'm happy. If it's compatible with the Apple Java6 way of doing things (i.e. @2x), I'm even happier.

That's pretty much all I intended to convey with my plea above.

Cheers,

-hendrik

From Sergey.Bylokhov at oracle.com  Thu Nov  7 06:18:32 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 18:18:32 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <527B3ACD.8070708@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
	<527AF470.1050300@oracle.com> <527AF7C8.3000007@oracle.com>
	<527B3ACD.8070708@oracle.com>
Message-ID: <527BA138.4030604@oracle.com>

On 07.11.2013 11:01, Jim Graham wrote:
> On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
>>>> In this example there is a problem. For example we have 2
>>>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>>>   - Image A draws to the image B
>>>>   - Image B draws to the window.
>>>>
>>>> When window is moving from the screen x1 to the screen x2 and back. 
>>>> How
>>>> to handle this situation?
>>>> In this case getResolutionVariant() can return
>>>>
>>>>
>>>> Related  discussion:
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html 
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html 
>>>>
>>>>
>>>
>>> How does calling getScaledInstance() deal with that?  Note the above
>>> was simply to demonstrate the visibility of the interface, not to be a
>>> complete implementation...
>> For example:
>>   - getScaledInstance() will be called() when image B will be painted to
>> the window with scale x2.
>>   - Inside B.getScaledInstance() the user can create BufferedImage C
>>   - get graphics from C and set new render hint to IMAGE_SCALING_ON ans
>> set scalex2.
>>   - Apply to C absolutely the same rendering  which was used in B.
>>   - getScaledInstance() will be called for A.
>
> In particular, drawImage() has always been a "copy some pixels and 
> return *now*" API.  Even when we had asynchronous loading of images it 
> returned immediately if the image wasn't loaded, it didn't fork off or 
> branch to another rendering process.  I really don't think we should 
> be encouraging creating a new image inside a request to draw an image.
That's not true we already do some kind of of new image creation inside 
DrawImage.makeBufferedImage() for example;
>
> Nothing in those related discussions pointed at this either.  What I 
> see the need for is:
>
> - Toolkit images automatically supporting loading an @2x image if one 
> is associated with the image they are requested to load.  I think they 
> already do this and you just need a way for drawImage() to grab that 
> image if necessary.
I think no. They do not support.
>
> - All images to have an associated resolution or pixel scale.  @2x 
> variants of images, if we ever expose them directly, would claim 
> either a pixel scale of 2 or a DPI of ?144?, i.e. double the implicit 
> dpi of 72 that most images claim or that we've assumed by default.
That's why all related information: DPI,Scale, etc are not mentioned in 
the fix and api. just width and height are used, which is general and 
simple.
>
> - Destination drawables having a resolution or pixel scaling parameter 
> associated with them that lets G2D decide if it is going to use hiDPI 
> media or not.  It would request a HiDPI version of an image if needed, 
> but this should be a simple "choose this set of pixels or that set" 
> API, not an "I'll make you one right now" type of API.
It is already in the current version of the fix.
>
> - (not necessarily now, but soon) A way for someone to associate a 
> higher DPI version of an image with an existing image and to query any 
> alternate resolutions that we've already prepared (such as any @2x 
> version that we've already loaded).  This could either be 
> "Image.createMultiResImage(... list of images and resolutions ...)" or 
> perhaps a convention for listing alternate images in the properties.
It was intended to do not provide any mapping from some scale to the 
image, and leave it up to the user. So loading of the images will be 
lazily. Only if the image really needed it will be created and cached  
by the user.
>
> As far as the "images for buttons" example in the macosx-port thread, 
> if those images are loaded using Toolkit.getImage() and there is an 
> associated @2x image and we load that internally and make it available 
> via some sort of (internal for now) MultiResImage interface like I 
> described, then we've solved that problem for buttons.  It seemed like 
> that was all that they were asking for there and I see no reason to 
> create a "solve every hypothetical resolution issue" API now to meet 
> that need...
But we do not create any new API except two hints in Image and SG2D. 
Note that if compatibility is a problem from your point of view, we can 
control new hint in SG2D by some desktop property, and disable it by 
default. I think it can be useful to disable all hidpi support in this case.
>
>                 ...jim


-- 
Best regards, Sergey.


From ebakke at MIT.EDU  Thu Nov  7 08:23:11 2013
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Thu, 7 Nov 2013 16:23:11 +0000
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK
	demos look perfect on retina displays
In-Reply-To: <5278D385.2000205@oracle.com>
Message-ID: <52CAC6A8CE5503408F3482C89035832809C4B16E@OC11EXPO27.exchange.mit.edu>

Just passing by...

Will retina-enabled Image objects work with Toolkit.createCustomCursor [1]
under this patch?

(I have a spreadsheet application that requires an Excel-style "plus"
cursor when the user hovers over it, and I'd like to supply a
retina-enabled cursor image as well.)

-- Eirik

[1] 
http://docs.oracle.com/javase/6/docs/api/java/awt/Toolkit.html#createCustom
Cursor(java.awt.Image, java.awt.Point, java.lang.String)

On 11/5/13, 6:16 AM, "Alexander Scherbatiy"
<alexandr.scherbatiy at oracle.com> wrote:

>
>    Thank you for the review.
>
>   Could you look at the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>
>   - URL is parsed to protocol, host, port, and path parts in the
>LWCToolkit class.
>      I checked that URL(protocol, host, port, file) constructor
>correctly handles -1 port value.
>   - Only last file name after last '/' in the URL path  is converted to
>@2x name
>   - Tests that check correct URL and path translation to @2x names are
>added to the ScalableImageTest
>
>   Thanks,
>   Alexandr.
>
>
>On 11/1/2013 12:46 AM, Peter Levart wrote:
>>
>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>> this:
>>>>
>>>> http://www.exampmle.com/dir/image
>>>>
>>>> In this case it will try to find 2x image here:
>>>>
>>>> http://www.example at 2x.com/dir/image
>>>>
>>>> which doesn't look correct.
>>>        Fixed. Only path part of a URL is converted to path2x.
>>
>> Hi Alexander,
>>
>> URLs like this:
>>
>> http://www.example.com/dir.ext/image
>>
>> will still be translated to:
>>
>> http://www.example.com/dir at 2x.ext/image
>>
>>
>> I think you need to search for last '.' after the last  '/' in the
>> getScaledImageName();
>>
>>
>> Also the following code has some additional bugs:
>>
>>   853         static Image toScalableImage(Image image, URL url) {
>>   854
>>   855             if (url != null && !url.toString().contains("@2x")
>>   856                     && !(image instanceof ScalableToolkitImage)) {
>>   857                 String protocol = url.getProtocol();
>>   858                 String host = url.getHost();
>>   859                 String file = url.getPath();
>>   860                 String file2x =*host +*getScaledImageName(file);
>>   861                 try {
>>   862                     URL url2x = new URL(protocol, host, file2x);
>>   863                     url2x.openStream();
>>   864                     return new ScalableToolkitImage(image,
>>getDefaultToolkit().getImage(url2x));
>>   865                 } catch (Exception ignore) {
>>   866                 }
>>   867             }
>>   868             return image;
>>   869         }
>>
>> Why are you prepending *host* to getScaledImageName(file) in line 860?
>> Let's take the following URL for example:
>>
>> http://www.example.com/dir/image.jpg
>>
>> protocol = "http"
>> host = "www.example.com"
>> file = "/dir/image.jpg"
>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>
>>
>> You are missing a part in URL (de)construction - the optional port!
>> For example in the following URL:
>>
>> http://www.example.com:8080/dir/image.jpg
>>
>> You should extract the port from original URL and use it in new URL
>> construction if present (!= -1).
>>
>>
>> I would also close the stream explicitly after probing for existence
>> of resource rather than delegating to GC which might not be promptly
>> and can cause resource exhaustion (think of MAX. # of open file
>> descriptors):
>>
>>         try (InputStream probe = url.openStream()) {}
>>
>>
>>
>> Regards, Peter
>>
>>
>


From hs at tagtraum.com  Thu Nov  7 12:41:30 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 21:41:30 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527BF882.7030604@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<527BF882.7030604@oracle.com>
Message-ID: <9196D32E-5878-42DE-89AC-35D8A875FDFC@tagtraum.com>


On Nov 7, 2013, at 9:30 PM, Jim Graham wrote:

> How did Apple expose this in their JDK6?
> 
> For the record, I'm saying that getImage("myimage.[fmt]") can load the @2x image and drawImage() could use that when needed - all of that can happen without any public API.
> 
> But, for a developer to query a Toolkit Image loaded via getImage("...") to find out if it has an @2x variant, we can't do that via the existing getScaledInstance() method.  Also, if a developer programmatically develops a set of multi-res images, then getScaledInstance() is not the mechanism that should be used to supply those to drawImage().
> 
> What did Apple provide beyond getImage()/drawImage() support for @2x file/URL resources?
> 
> 			...jim


Sorry guys, to cause confusion. I really should have read the whole thread - I haven't (also see http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-November/006209.html). Apple didn't have any public APIs beyond the Toolkit.getImage(...); method. It loaded the appropriate image, i.e. a @2x version if available.

There wasn't anything else (not without hacking the private APIs -> http://blog.beatunes.com/2013/04/creating-retina-capable-images-with.html)

So - Jim - again sorry,

-hendrik

From hs at tagtraum.com  Thu Nov  7 13:11:36 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 22:11:36 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527C00A2.10309@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<527BF882.7030604@oracle.com>
	<9196D32E-5878-42DE-89AC-35D8A875FDFC@tagtraum.com>
	<527C00A2.10309@oracle.com>
Message-ID: <01085110-6540-4D1A-B16A-478029245AAF@tagtraum.com>


On Nov 7, 2013, at 10:05 PM, Jim Graham wrote:

> Thanks Hendrik, no apologies necessary.
> 
> I haven't been involved much in the MacOS port so my question was actually a legitimate call for information and not meant to criticize anyone's input.  I actually searched for a developer page that mentioned the MacOS port's retina handling and all I could find were references to setting the flag in your plist to enable retina - I didn't even find an official announcement that they would load the @2x for you, but I assumed that they would...


This http://lists.apple.com/archives/java-dev/2012/Jun/msg00069.html is probably the closest Apple ever came to an announcement/documentation of Retina support.

-hendrik


From damarasekara at typefi.com  Thu Nov  7 16:55:50 2013
From: damarasekara at typefi.com (Dinesh Amarasekara)
Date: Fri, 8 Nov 2013 10:55:50 +1000
Subject: Supporting Multiple GPUs on Mac OS X
Message-ID: <CALRdcwxWFVCs3r-NsiH=Wg+rGnasNNZC_mC1OTpQaT6E_D1RtA@mail.gmail.com>

Hi,

Can I know how to enable a Java Swing Application to run with multiple GPUs
on Mac OS X ? I tried with entering the following to the plist.info file.

<key>NSSupportsAutomaticGraphicsSwitching</key>
<true/>

However still it automatically switches to the discrete GPU on launch. Any
input regarding this matter is highly appreciated.

Thanks And Best Regards,
Dinesh.

-- 

*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  Fri Nov  8 08:48:01 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 08 Nov 2013 16:48:01 +0000
Subject: Problem with InetAddress.getLocalHost() on Java 7
Message-ID: <527D15C1.10500@fastmail.fm>

It works okay for me but for a particular customer 
InetAddress.getLocalHost() is failing with Java 7 although it works okay 
with Java 6 with the following exception

java.net.UnknownHostException: rupert: rupert: nodename nor servname 
provided, or not known
     at java.net.InetAddress.getLocalHost(InetAddress.java:1466)
Caused by: java.net.UnknownHostException: rupert: nodename nor servname 
provided, or not known
     at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
     at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:894)
     at 
java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1286)
     at java.net.InetAddress.getLocalHost(InetAddress.java:1462)

Is this by design ?

Paul


From Alan.Bateman at oracle.com  Mon Nov 11 01:02:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Nov 2013 09:02:37 +0000
Subject: Problem with InetAddress.getLocalHost() on Java 7
In-Reply-To: <527D15C1.10500@fastmail.fm>
References: <527D15C1.10500@fastmail.fm>
Message-ID: <52809D2D.500@oracle.com>

On 08/11/2013 16:48, Paul Taylor wrote:
> It works okay for me but for a particular customer 
> InetAddress.getLocalHost() is failing with Java 7 although it works 
> okay with Java 6 with the following exception
>
> java.net.UnknownHostException: rupert: rupert: nodename nor servname 
> provided, or not known
>     at java.net.InetAddress.getLocalHost(InetAddress.java:1466)
> Caused by: java.net.UnknownHostException: rupert: nodename nor 
> servname provided, or not known
>     at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
>     at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:894)
>     at 
> java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1286)
>     at java.net.InetAddress.getLocalHost(InetAddress.java:1462)
>
> Is this by design ?
This might be another case of JDK-7180557. Any chance that you could try 
the most recent build of JDK 8 and see if it duplicates?

-Alan

From paul_t100 at fastmail.fm  Mon Nov 11 01:09:04 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 11 Nov 2013 09:09:04 +0000
Subject: Problem with InetAddress.getLocalHost() on Java 7
In-Reply-To: <52809D2D.500@oracle.com>
References: <527D15C1.10500@fastmail.fm> <52809D2D.500@oracle.com>
Message-ID: <52809EB0.3090506@fastmail.fm>

On 11/11/2013 09:02, Alan Bateman wrote:
> On 08/11/2013 16:48, Paul Taylor wrote:
>> It works okay for me but for a particular customer 
>> InetAddress.getLocalHost() is failing with Java 7 although it works 
>> okay with Java 6 with the following exception
>>
>> java.net.UnknownHostException: rupert: rupert: nodename nor servname 
>> provided, or not known
>>     at java.net.InetAddress.getLocalHost(InetAddress.java:1466)
>> Caused by: java.net.UnknownHostException: rupert: nodename nor 
>> servname provided, or not known
>>     at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
>>     at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:894)
>>     at 
>> java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1286)
>>     at java.net.InetAddress.getLocalHost(InetAddress.java:1462)
>>
>> Is this by design ?
> This might be another case of JDK-7180557. Any chance that you could 
> try the most recent build of JDK 8 and see if it duplicates?
>
> -Alan
>
Trouble is I cannot replicate the problem myself even if remove entries 
from /etc/hosts it is only a problem some of my customers are having

Paul

From Alan.Bateman at oracle.com  Mon Nov 11 07:35:03 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Nov 2013 15:35:03 +0000
Subject: Problem with InetAddress.getLocalHost() on Java 7
In-Reply-To: <52809EB0.3090506@fastmail.fm>
References: <527D15C1.10500@fastmail.fm> <52809D2D.500@oracle.com>
	<52809EB0.3090506@fastmail.fm>
Message-ID: <5280F927.4000704@oracle.com>

On 11/11/2013 09:09, Paul Taylor wrote:
> Trouble is I cannot replicate the problem myself even if remove 
> entries from /etc/hosts it is only a problem some of my customers are 
> having
>
> Paul
The reports on this issue (assuming it is the same thing as JDK-7180557) 
were sparse and it took a while to find a system where this duplicated. 
The comments in the bug might be useful to help you duplicate it.

-Alan.


From paul_t100 at fastmail.fm  Mon Nov 11 07:48:26 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 11 Nov 2013 15:48:26 +0000
Subject: Problem with InetAddress.getLocalHost() on Java 7
In-Reply-To: <5280F927.4000704@oracle.com>
References: <527D15C1.10500@fastmail.fm> <52809D2D.500@oracle.com>
	<52809EB0.3090506@fastmail.fm> <5280F927.4000704@oracle.com>
Message-ID: <5280FC4A.5030807@fastmail.fm>

On 11/11/2013 15:35, Alan Bateman wrote:
> On 11/11/2013 09:09, Paul Taylor wrote:
>> Trouble is I cannot replicate the problem myself even if remove 
>> entries from /etc/hosts it is only a problem some of my customers are 
>> having
>>
>> Paul
> The reports on this issue (assuming it is the same thing as 
> JDK-7180557) were sparse and it took a while to find a system where 
> this duplicated. The comments in the bug might be useful to help you 
> duplicate it.
>
> -Alan.
>
>
ok, thanks Alan

From alexandr.scherbatiy at oracle.com  Mon Nov 11 07:59:22 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Nov 2013 19:59:22 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5278D385.2000205@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>
Message-ID: <5280FEDA.20202@oracle.com>


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

   Only internal API is exposed:
   - MultiResolutionImage interface with method 
"getResolutionVariant(int width, int height)" is added to the 
com.sun.awt package
   - Hints to switch on/off the resolution variant usage are added to 
SunHints class
   - Test is updated to use the  MultiResolutionImage interface

  Thanks,
  Alexandr.

On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>
>    Thank you for the review.
>
>   Could you look at the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>
>   - URL is parsed to protocol, host, port, and path parts in the 
> LWCToolkit class.
>      I checked that URL(protocol, host, port, file) constructor 
> correctly handles -1 port value.
>   - Only last file name after last '/' in the URL path  is converted 
> to @2x name
>   - Tests that check correct URL and path translation to @2x names are 
> added to the ScalableImageTest
>
>   Thanks,
>   Alexandr.
>
>
> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>
>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>> 2. I'm not sure that the proposed getScaledImageName() 
>>>> implementation in ScalableToolkitImage works perfectly for URLs 
>>>> like this:
>>>>
>>>> http://www.exampmle.com/dir/image
>>>>
>>>> In this case it will try to find 2x image here:
>>>>
>>>> http://www.example at 2x.com/dir/image
>>>>
>>>> which doesn't look correct.
>>>        Fixed. Only path part of a URL is converted to path2x. 
>>
>> Hi Alexander,
>>
>> URLs like this:
>>
>> http://www.example.com/dir.ext/image
>>
>> will still be translated to:
>>
>> http://www.example.com/dir at 2x.ext/image
>>
>>
>> I think you need to search for last '.' after the last  '/' in the 
>> getScaledImageName();
>>
>>
>> Also the following code has some additional bugs:
>>
>>   853         static Image toScalableImage(Image image, URL url) {
>>   854
>>   855             if (url != null && !url.toString().contains("@2x")
>>   856                     && !(image instanceof ScalableToolkitImage)) {
>>   857                 String protocol = url.getProtocol();
>>   858                 String host = url.getHost();
>>   859                 String file = url.getPath();
>>   860                 String file2x =*host +*getScaledImageName(file);
>>   861                 try {
>>   862                     URL url2x = new URL(protocol, host, file2x);
>>   863                     url2x.openStream();
>>   864                     return new ScalableToolkitImage(image, 
>> getDefaultToolkit().getImage(url2x));
>>   865                 } catch (Exception ignore) {
>>   866                 }
>>   867             }
>>   868             return image;
>>   869         }
>>
>> Why are you prepending *host* to getScaledImageName(file) in line 
>> 860? Let's take the following URL for example:
>>
>> http://www.example.com/dir/image.jpg
>>
>> protocol = "http"
>> host = "www.example.com"
>> file = "/dir/image.jpg"
>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>
>>
>> You are missing a part in URL (de)construction - the optional port! 
>> For example in the following URL:
>>
>> http://www.example.com:8080/dir/image.jpg
>>
>> You should extract the port from original URL and use it in new URL 
>> construction if present (!= -1).
>>
>>
>> I would also close the stream explicitly after probing for existence 
>> of resource rather than delegating to GC which might not be promptly 
>> and can cause resource exhaustion (think of MAX. # of open file 
>> descriptors):
>>
>>         try (InputStream probe = url.openStream()) {}
>>
>>
>>
>> Regards, Peter
>>
>>
>


From hs at tagtraum.com  Mon Nov 11 08:40:05 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 11 Nov 2013 17:40:05 +0100
Subject: 404 Java Bug Database
Message-ID: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>

Hey,

so after a bit of searching, I just realized that the Java bug database is now at https://bugs.openjdk.java.net/secure/Dashboard.jspa
That means there are a lot of broken links on the Oracle site, e.g. on http://www.oracle.com/technetwork/java/index.html "Java Bug Database" still points to http://www.oracle.com/us/sun/index.htm - which is less than helpful.

Perhaps some of the folks on this list, who work for Oracle could bring this up with the Oracle website people and fix this. I think it would make everybody's life a little easier.

Thanks,

-hendrik

From Fabrizio.Giudici at tidalwave.it  Mon Nov 11 08:53:15 2013
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Mon, 11 Nov 2013 17:53:15 +0100
Subject: 404 Java Bug Database
In-Reply-To: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
Message-ID: <op.w6d861sg2ilaq7@mistral.local>

On Mon, 11 Nov 2013 17:40:05 +0100, Hendrik Schreiber <hs at tagtraum.com>  
wrote:

> Hey,
>
> so after a bit of searching, I just realized that the Java bug database  
> is now at https://bugs.openjdk.java.net/secure/Dashboard.jspa
> That means there are a lot of broken links on the Oracle site, e.g. on  
> http://www.oracle.com/technetwork/java/index.html "Java Bug Database"  
> still points to http://www.oracle.com/us/sun/index.htm - which is less  
> than helpful.
>
> Perhaps some of the folks on this list, who work for Oracle could bring  
> this up with the Oracle website people and fix this. I think it would  
> make everybody's life a little easier.

Unfortunately, there's a whole bunch of broken links in the Java  
ecosystem. If it gets fixed as the e.g. https://jaxb.dev.java.net/*, still  
linked everywhere, that should be automatically redirected to  
https://jaxb.java.net/* and it doesn't (and this holds for *any* project  
at java.net), I don't see the thing with an optimistic attitude :-)

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From roger.lewis at oracle.com  Mon Nov 11 09:22:59 2013
From: roger.lewis at oracle.com (Roger Lewis)
Date: Mon, 11 Nov 2013 09:22:59 -0800
Subject: 404 Java Bug Database
In-Reply-To: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
Message-ID: <52811273.6080603@oracle.com>

Hi Hendrik,
    We are looking into the bugs.sun.com issue.

-Roger

On 11/11/13, 8:40 AM, Hendrik Schreiber wrote:
> Hey,
>
> so after a bit of searching, I just realized that the Java bug database is now at https://bugs.openjdk.java.net/secure/Dashboard.jspa
> That means there are a lot of broken links on the Oracle site, e.g. on http://www.oracle.com/technetwork/java/index.html "Java Bug Database" still points to http://www.oracle.com/us/sun/index.htm - which is less than helpful.
>
> Perhaps some of the folks on this list, who work for Oracle could bring this up with the Oracle website people and fix this. I think it would make everybody's life a little easier.
>
> Thanks,
>
> -hendrik


From roger.lewis at oracle.com  Mon Nov 11 09:24:58 2013
From: roger.lewis at oracle.com (Roger Lewis)
Date: Mon, 11 Nov 2013 09:24:58 -0800
Subject: 404 Java Bug Database
In-Reply-To: <op.w6d861sg2ilaq7@mistral.local>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
	<op.w6d861sg2ilaq7@mistral.local>
Message-ID: <528112EA.7070601@oracle.com>

Let me see if I can gent the jaxb redirect issue to the right team to be 
resolved.

-Roger


On 11/11/13, 8:53 AM, Fabrizio Giudici wrote:
> On Mon, 11 Nov 2013 17:40:05 +0100, Hendrik Schreiber 
> <hs at tagtraum.com> wrote:
>
>> Hey,
>>
>> so after a bit of searching, I just realized that the Java bug 
>> database is now at https://bugs.openjdk.java.net/secure/Dashboard.jspa
>> That means there are a lot of broken links on the Oracle site, e.g. 
>> on http://www.oracle.com/technetwork/java/index.html "Java Bug 
>> Database" still points to http://www.oracle.com/us/sun/index.htm - 
>> which is less than helpful.
>>
>> Perhaps some of the folks on this list, who work for Oracle could 
>> bring this up with the Oracle website people and fix this. I think it 
>> would make everybody's life a little easier.
>
> Unfortunately, there's a whole bunch of broken links in the Java 
> ecosystem. If it gets fixed as the e.g. https://jaxb.dev.java.net/*, 
> still linked everywhere, that should be automatically redirected to 
> https://jaxb.java.net/* and it doesn't (and this holds for *any* 
> project at java.net), I don't see the thing with an optimistic 
> attitude :-)
>


From Fabrizio.Giudici at tidalwave.it  Mon Nov 11 09:31:31 2013
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Mon, 11 Nov 2013 18:31:31 +0100
Subject: 404 Java Bug Database
In-Reply-To: <528112EA.7070601@oracle.com>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
	<op.w6d861sg2ilaq7@mistral.local> <528112EA.7070601@oracle.com>
Message-ID: <op.w6eaytco2ilaq7@mistral.local>

On Mon, 11 Nov 2013 18:24:58 +0100, Roger Lewis <roger.lewis at oracle.com>  
wrote:

> Let me see if I can gent the jaxb redirect issue to the right team to be  
> resolved.

BTW, as I said, it's not just jaxb: all the projects at java.net have  
this. It is clearly fixable by hand when you run into one, obviously, but  
it's quite annoying when you e.g. send a customer a Oracle document (there  
are many with old links of course) and the customer complains "Ah, but is  
this still supported? I see broken links" etc...

Thanks.


-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From hs at tagtraum.com  Mon Nov 11 10:43:15 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 11 Nov 2013 19:43:15 +0100
Subject: 404 Java Bug Database
In-Reply-To: <528112EA.7070601@oracle.com>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
	<op.w6d861sg2ilaq7@mistral.local> <528112EA.7070601@oracle.com>
Message-ID: <0E5BCEDC-BA65-469A-A4A0-20AF74A79ED1@tagtraum.com>

On Nov 11, 2013, at 6:24 PM, Roger Lewis wrote:

> Let me see if I can gent the jaxb redirect issue to the right team to be resolved.

That is great to hear, Roger!

Thanks for looking into this. I hope you don't encounter too much bureaucratic red tape... 

-hendrik

From jonathan.gibbons at oracle.com  Mon Nov 11 11:08:30 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Nov 2013 11:08:30 -0800
Subject: 404 Java Bug Database
In-Reply-To: <0E5BCEDC-BA65-469A-A4A0-20AF74A79ED1@tagtraum.com>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>	<op.w6d861sg2ilaq7@mistral.local>
	<528112EA.7070601@oracle.com>
	<0E5BCEDC-BA65-469A-A4A0-20AF74A79ED1@tagtraum.com>
Message-ID: <52812B2E.30706@oracle.com>

On 11/11/2013 10:43 AM, Hendrik Schreiber wrote:
> On Nov 11, 2013, at 6:24 PM, Roger Lewis wrote:
>
>> Let me see if I can gent the jaxb redirect issue to the right team to be resolved.
> That is great to hear, Roger!
>
> Thanks for looking into this. I hope you don't encounter too much bureaucratic red tape...
>
> -hendrik

"It would be nice" to run some sort of link checker over the relevant 
subset of the web site, and detect/fixup all such broken links into 
ex-Sun/Oracle properties.

-- Jon

From alexandr.scherbatiy at oracle.com  Tue Nov 12 02:05:29 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Nov 2013 14:05:29 +0400
Subject: [8] Review request for 8025126 [macosx] Invalid calls to setValueAt()
	within JTable in Java 7 on Mac OS X
Message-ID: <5281FD69.4010600@oracle.com>

  Hello,

Could you review the fix:

   bug: https://bugs.openjdk.java.net/browse/JDK-8025126
   webrev: http://cr.openjdk.java.net/~alexsch/8025126/webrev.00

   The extended key code is set to the key code if the key char is 
undefined.

Thanks,
Alexandr.


From Sergey.Bylokhov at oracle.com  Tue Nov 12 04:39:09 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Nov 2013 16:39:09 +0400
Subject: [8] Review request for 8025126 [macosx] Invalid calls to
	setValueAt() within JTable in Java 7 on Mac OS X
In-Reply-To: <5281FD69.4010600@oracle.com>
References: <5281FD69.4010600@oracle.com>
Message-ID: <5282216D.8030402@oracle.com>

Hi, Alexander for what version of jdk this fix?
Probably 8007156 should be backported?

On 12.11.2013 14:05, Alexander Scherbatiy wrote:
>  Hello,
>
> Could you review the fix:
>
>   bug: https://bugs.openjdk.java.net/browse/JDK-8025126
>   webrev: http://cr.openjdk.java.net/~alexsch/8025126/webrev.00
>
>   The extended key code is set to the key code if the key char is 
> undefined.
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Nov 12 05:37:41 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 12 Nov 2013 17:37:41 +0400
Subject: [8] Review request for 8025126 [macosx] Invalid calls to
	setValueAt() within JTable in Java 7 on Mac OS X
In-Reply-To: <5282216D.8030402@oracle.com>
References: <5281FD69.4010600@oracle.com> <5282216D.8030402@oracle.com>
Message-ID: <52822F25.1030006@oracle.com>

Hi, Alexander.
I accidental apply a patch on jdk7.
The fix looks good. I assume that all related regression/jck tests were 
checked.

On 12.11.2013 16:39, Sergey Bylokhov wrote:
> Hi, Alexander for what version of jdk this fix?
> Probably 8007156 should be backported?
>
> On 12.11.2013 14:05, Alexander Scherbatiy wrote:
>>  Hello,
>>
>> Could you review the fix:
>>
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8025126
>>   webrev: http://cr.openjdk.java.net/~alexsch/8025126/webrev.00
>>
>>   The extended key code is set to the key code if the key char is 
>> undefined.
>>
>> Thanks,
>> Alexandr.
>>
>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Tue Nov 12 07:05:29 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Nov 2013 19:05:29 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <52CAC6A8CE5503408F3482C89035832809C4B16E@OC11EXPO27.exchange.mit.edu>
References: <52CAC6A8CE5503408F3482C89035832809C4B16E@OC11EXPO27.exchange.mit.edu>
Message-ID: <528243B9.20704@oracle.com>

On 11/7/2013 8:23 PM, Eirik Bakke wrote:
> Just passing by...
>
> Will retina-enabled Image objects work with Toolkit.createCustomCursor [1]
> under this patch?

    This patch allows to create an image with different resolutions that 
can be used for the custom cursor as well.
    To make it work with custom cursor it needs to properly  pass these 
images to the native system.

    I have created an issue to track this: JDK-8028212 Custom cursor 
HiDPI support
       https://bugs.openjdk.java.net/browse/JDK-8028212

   Thanks,
   Alexandr.

>
> (I have a spreadsheet application that requires an Excel-style "plus"
> cursor when the user hovers over it, and I'd like to supply a
> retina-enabled cursor image as well.)
>
> -- Eirik
>
> [1]
> http://docs.oracle.com/javase/6/docs/api/java/awt/Toolkit.html#createCustom
> Cursor(java.awt.Image, java.awt.Point, java.lang.String)
>
> On 11/5/13, 6:16 AM, "Alexander Scherbatiy"
> <alexandr.scherbatiy at oracle.com> wrote:
>
>>     Thank you for the review.
>>
>>    Could you look at the updated fix:
>>       http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>
>>    - URL is parsed to protocol, host, port, and path parts in the
>> LWCToolkit class.
>>       I checked that URL(protocol, host, port, file) constructor
>> correctly handles -1 port value.
>>    - Only last file name after last '/' in the URL path  is converted to
>> @2x name
>>    - Tests that check correct URL and path translation to @2x names are
>> added to the ScalableImageTest
>>
>>    Thanks,
>>    Alexandr.
>>
>>
>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>>> this:
>>>>>
>>>>> http://www.exampmle.com/dir/image
>>>>>
>>>>> In this case it will try to find 2x image here:
>>>>>
>>>>> http://www.example at 2x.com/dir/image
>>>>>
>>>>> which doesn't look correct.
>>>>         Fixed. Only path part of a URL is converted to path2x.
>>> Hi Alexander,
>>>
>>> URLs like this:
>>>
>>> http://www.example.com/dir.ext/image
>>>
>>> will still be translated to:
>>>
>>> http://www.example.com/dir at 2x.ext/image
>>>
>>>
>>> I think you need to search for last '.' after the last  '/' in the
>>> getScaledImageName();
>>>
>>>
>>> Also the following code has some additional bugs:
>>>
>>>    853         static Image toScalableImage(Image image, URL url) {
>>>    854
>>>    855             if (url != null && !url.toString().contains("@2x")
>>>    856                     && !(image instanceof ScalableToolkitImage)) {
>>>    857                 String protocol = url.getProtocol();
>>>    858                 String host = url.getHost();
>>>    859                 String file = url.getPath();
>>>    860                 String file2x =*host +*getScaledImageName(file);
>>>    861                 try {
>>>    862                     URL url2x = new URL(protocol, host, file2x);
>>>    863                     url2x.openStream();
>>>    864                     return new ScalableToolkitImage(image,
>>> getDefaultToolkit().getImage(url2x));
>>>    865                 } catch (Exception ignore) {
>>>    866                 }
>>>    867             }
>>>    868             return image;
>>>    869         }
>>>
>>> Why are you prepending *host* to getScaledImageName(file) in line 860?
>>> Let's take the following URL for example:
>>>
>>> http://www.example.com/dir/image.jpg
>>>
>>> protocol = "http"
>>> host = "www.example.com"
>>> file = "/dir/image.jpg"
>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>
>>>
>>> You are missing a part in URL (de)construction - the optional port!
>>> For example in the following URL:
>>>
>>> http://www.example.com:8080/dir/image.jpg
>>>
>>> You should extract the port from original URL and use it in new URL
>>> construction if present (!= -1).
>>>
>>>
>>> I would also close the stream explicitly after probing for existence
>>> of resource rather than delegating to GC which might not be promptly
>>> and can cause resource exhaustion (think of MAX. # of open file
>>> descriptors):
>>>
>>>          try (InputStream probe = url.openStream()) {}
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>


From roger.lewis at oracle.com  Tue Nov 12 07:35:00 2013
From: roger.lewis at oracle.com (Roger Lewis)
Date: Tue, 12 Nov 2013 07:35:00 -0800
Subject: 404 Java Bug Database
In-Reply-To: <52811273.6080603@oracle.com>
References: <43727ED5-21E6-42CF-B2E8-DFBF2647F3AB@tagtraum.com>
	<52811273.6080603@oracle.com>
Message-ID: <52824AA4.7090501@oracle.com>

The site was brought back online yesterday later in the day.

-Roger


On 11/11/13, 9:22 AM, Roger Lewis wrote:
> Hi Hendrik,
>    We are looking into the bugs.sun.com issue.
>
> -Roger
>
> On 11/11/13, 8:40 AM, Hendrik Schreiber wrote:
>> Hey,
>>
>> so after a bit of searching, I just realized that the Java bug 
>> database is now at https://bugs.openjdk.java.net/secure/Dashboard.jspa
>> That means there are a lot of broken links on the Oracle site, e.g. 
>> on http://www.oracle.com/technetwork/java/index.html "Java Bug 
>> Database" still points to http://www.oracle.com/us/sun/index.htm - 
>> which is less than helpful.
>>
>> Perhaps some of the folks on this list, who work for Oracle could 
>> bring this up with the Oracle website people and fix this. I think it 
>> would make everybody's life a little easier.
>>
>> Thanks,
>>
>> -hendrik
>


From ebakke at MIT.EDU  Tue Nov 12 09:57:48 2013
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Tue, 12 Nov 2013 17:57:48 +0000
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK
	demos look perfect on retina displays
In-Reply-To: <528243B9.20704@oracle.com>
Message-ID: <52CAC6A8CE5503408F3482C89035832809C4ECBE@OC11EXPO27.exchange.mit.edu>

> I have created an issue to track this: JDK-8028212 Custom cursor HiDPI
>support
> https://bugs.openjdk.java.net/browse/JDK-8028212

Perfect--thanks!



On 11/12/13, 10:05 AM, "Alexander Scherbatiy"
<alexandr.scherbatiy at oracle.com> wrote:

>On 11/7/2013 8:23 PM, Eirik Bakke wrote:
>> Just passing by...
>>
>> Will retina-enabled Image objects work with Toolkit.createCustomCursor
>>[1]
>> under this patch?
>
>    This patch allows to create an image with different resolutions that
>can be used for the custom cursor as well.
>    To make it work with custom cursor it needs to properly  pass these
>images to the native system.
>
>    I have created an issue to track this: JDK-8028212 Custom cursor
>HiDPI support
>       https://bugs.openjdk.java.net/browse/JDK-8028212
>
>   Thanks,
>   Alexandr.
>
>>
>> (I have a spreadsheet application that requires an Excel-style "plus"
>> cursor when the user hovers over it, and I'd like to supply a
>> retina-enabled cursor image as well.)
>>
>> -- Eirik
>>
>> [1]
>> 
>>http://docs.oracle.com/javase/6/docs/api/java/awt/Toolkit.html#createCust
>>om
>> Cursor(java.awt.Image, java.awt.Point, java.lang.String)
>>
>> On 11/5/13, 6:16 AM, "Alexander Scherbatiy"
>> <alexandr.scherbatiy at oracle.com> wrote:
>>
>>>     Thank you for the review.
>>>
>>>    Could you look at the updated fix:
>>>       http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>
>>>    - URL is parsed to protocol, host, port, and path parts in the
>>> LWCToolkit class.
>>>       I checked that URL(protocol, host, port, file) constructor
>>> correctly handles -1 port value.
>>>    - Only last file name after last '/' in the URL path  is converted
>>>to
>>> @2x name
>>>    - Tests that check correct URL and path translation to @2x names are
>>> added to the ScalableImageTest
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>
>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>>>> this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>         Fixed. Only path part of a URL is converted to path2x.
>>>> Hi Alexander,
>>>>
>>>> URLs like this:
>>>>
>>>> http://www.example.com/dir.ext/image
>>>>
>>>> will still be translated to:
>>>>
>>>> http://www.example.com/dir at 2x.ext/image
>>>>
>>>>
>>>> I think you need to search for last '.' after the last  '/' in the
>>>> getScaledImageName();
>>>>
>>>>
>>>> Also the following code has some additional bugs:
>>>>
>>>>    853         static Image toScalableImage(Image image, URL url) {
>>>>    854
>>>>    855             if (url != null && !url.toString().contains("@2x")
>>>>    856                     && !(image instanceof
>>>>ScalableToolkitImage)) {
>>>>    857                 String protocol = url.getProtocol();
>>>>    858                 String host = url.getHost();
>>>>    859                 String file = url.getPath();
>>>>    860                 String file2x =*host
>>>>+*getScaledImageName(file);
>>>>    861                 try {
>>>>    862                     URL url2x = new URL(protocol, host,
>>>>file2x);
>>>>    863                     url2x.openStream();
>>>>    864                     return new ScalableToolkitImage(image,
>>>> getDefaultToolkit().getImage(url2x));
>>>>    865                 } catch (Exception ignore) {
>>>>    866                 }
>>>>    867             }
>>>>    868             return image;
>>>>    869         }
>>>>
>>>> Why are you prepending *host* to getScaledImageName(file) in line 860?
>>>> Let's take the following URL for example:
>>>>
>>>> http://www.example.com/dir/image.jpg
>>>>
>>>> protocol = "http"
>>>> host = "www.example.com"
>>>> file = "/dir/image.jpg"
>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>> url2x = 
>>>>URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>
>>>>
>>>> You are missing a part in URL (de)construction - the optional port!
>>>> For example in the following URL:
>>>>
>>>> http://www.example.com:8080/dir/image.jpg
>>>>
>>>> You should extract the port from original URL and use it in new URL
>>>> construction if present (!= -1).
>>>>
>>>>
>>>> I would also close the stream explicitly after probing for existence
>>>> of resource rather than delegating to GC which might not be promptly
>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>> descriptors):
>>>>
>>>>          try (InputStream probe = url.openStream()) {}
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>


From swingler at apple.com  Tue Nov 12 17:48:41 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 12 Nov 2013 17:48:41 -0800
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <528284FF.3080007@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>
Message-ID: <71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>

On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:

> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.

The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.

Regards,
Mike Swingler
Apple Inc.


From swingler at apple.com  Tue Nov 12 18:46:46 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 12 Nov 2013 18:46:46 -0800
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5282DB56.7090306@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>
Message-ID: <1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>

The story is a little more complicated: NSImage always picks the "best" representation based on the computed size of the backing pixel rect taking all graphics transforms into account. For icons, which usually have dozens of representations, there isn't a single "@2x" representation.

This means that by switching screens, an icon can flip from a cartoonish 16x16 rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only reps available. The multi-rep support in NSImage can also defer to a PDF representation if available when it can't find an exact dimension and bit-depth match for raster representations.

This does mean that an icon with 12 or so representations will visually glitch when smooth scaled as bits of detail come and go...but in the general case, most images tend to only have 2 reps and developers don't animate between them.

So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if the transform causes the rect in the pixel backing store to be the same size or smaller than the @1x.

I'll privately send along a little app that demonstrates this.

Regards,
Mike Swingler
Apple Inc.

On Nov 12, 2013, at 5:52 PM, Jim Graham <james.graham at oracle.com> wrote:

> Hi Mike,
> 
> Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001?
> 
> 		...jim
> 
> On 11/12/2013 5:48 PM, Mike Swingler wrote:
>> On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:
>> 
>>> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.
>> 
>> The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.
>> 
>> Regards,
>> Mike Swingler
>> Apple Inc.
>> 


From Sergey.Bylokhov at oracle.com  Wed Nov 13 04:33:35 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2013 16:33:35 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <528284FF.3080007@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>
Message-ID: <5283719F.1030700@oracle.com>

On 12.11.2013 23:43, Jim Graham wrote:
> Hi Alexander,
>
> Some minor issues with this fix:
>
> - It looks like the transform is used in SG2D to decide if the hiDPI 
> image should be used.  I'm not familiar with the Mac's native use of 
> @2x, but I thought that they hinged the decision off of the "retina 
> scale" of the display, not off of the current transform.  That way, if 
> you scale down an icon it doesn't change its look when it reaches .5x 
> scale (or .75x depending on the cutoff).  Personally, I think it is 
> better to not use the transform to keep animations smooth, but I'm not 
> sure what Apple did.
>
> - The logic in using the transform is also a bit murky.  I think if 
> you set the scale on a retina display to exactly 1/2 it would use the 
> HiDPI version even though the scale was 1:1.  Since I support not 
> examining the transform there, I'm going to present this as another 
> reason why we should just base it on devScale, but the logic could be 
> fixed if we really plan to use the transform here.
It also allow to the user to use a transform and a hint and force the 
images to draw the scaled version even to the BufferedImage fo ex. Which 
can be useful in case of sequential drawing of BI-> BI->retina.
> - Has any thought been given to my comments about MediaTracker and 
> image observer states for multi-res images?  I don't see any attempt 
> here to preload the @2x image.  The problem would probably only be 
> seen on multi-headed systems where one display is retina and one is 
> not - you would find the images suddenly reloading when you move the 
> window to the other screen and the application might not expect that 
> to happen.  Which image is the Observer registered on?  Since the 
> image is handed to the Observer, will an application be surprised when 
> their observer gets a handle to an image they've never seen?  Is it an 
> issue if one of the "alternate resolution variant" images leaks into 
> an application's "hands" via the observer callbacks?
That's could be a problem. Is it possible to wrap imageObserver, which 
was passed to the drawImage, and replace one image to another in the 
WrapperImageObserver.imageUpdate()?
>
>             ...jim
>
> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>
>>    Only internal API is exposed:
>>    - MultiResolutionImage interface with method
>> "getResolutionVariant(int width, int height)" is added to the
>> com.sun.awt package
>>    - Hints to switch on/off the resolution variant usage are added to
>> SunHints class
>>    - Test is updated to use the  MultiResolutionImage interface
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>
>>>    Thank you for the review.
>>>
>>>   Could you look at the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>
>>>   - URL is parsed to protocol, host, port, and path parts in the
>>> LWCToolkit class.
>>>      I checked that URL(protocol, host, port, file) constructor
>>> correctly handles -1 port value.
>>>   - Only last file name after last '/' in the URL path  is converted
>>> to @2x name
>>>   - Tests that check correct URL and path translation to @2x names are
>>> added to the ScalableImageTest
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>
>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>> like this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>> Hi Alexander,
>>>>
>>>> URLs like this:
>>>>
>>>> http://www.example.com/dir.ext/image
>>>>
>>>> will still be translated to:
>>>>
>>>> http://www.example.com/dir at 2x.ext/image
>>>>
>>>>
>>>> I think you need to search for last '.' after the last  '/' in the
>>>> getScaledImageName();
>>>>
>>>>
>>>> Also the following code has some additional bugs:
>>>>
>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>   854
>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>   856                     && !(image instanceof 
>>>> ScalableToolkitImage)) {
>>>>   857                 String protocol = url.getProtocol();
>>>>   858                 String host = url.getHost();
>>>>   859                 String file = url.getPath();
>>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>>   861                 try {
>>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>>   863                     url2x.openStream();
>>>>   864                     return new ScalableToolkitImage(image,
>>>> getDefaultToolkit().getImage(url2x));
>>>>   865                 } catch (Exception ignore) {
>>>>   866                 }
>>>>   867             }
>>>>   868             return image;
>>>>   869         }
>>>>
>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>> 860? Let's take the following URL for example:
>>>>
>>>> http://www.example.com/dir/image.jpg
>>>>
>>>> protocol = "http"
>>>> host = "www.example.com"
>>>> file = "/dir/image.jpg"
>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>> url2x = 
>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>
>>>>
>>>> You are missing a part in URL (de)construction - the optional port!
>>>> For example in the following URL:
>>>>
>>>> http://www.example.com:8080/dir/image.jpg
>>>>
>>>> You should extract the port from original URL and use it in new URL
>>>> construction if present (!= -1).
>>>>
>>>>
>>>> I would also close the stream explicitly after probing for existence
>>>> of resource rather than delegating to GC which might not be promptly
>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>> descriptors):
>>>>
>>>>         try (InputStream probe = url.openStream()) {}
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>
>>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Nov 13 08:11:16 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Nov 2013 20:11:16 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <528284FF.3080007@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>
Message-ID: <5283A4A4.60007@oracle.com>


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

   -  The default sun hint is added.
      However, it looks the same as the resolution variant ON hint right 
now. It would better to leave the behavior on the non HiDPI displays the 
same as it was before.
      So the resolution variant hint is disabled by default for non 
HiDPI displays.
   - Resolution variant hints description is updated.
   - The logic operator in the  isHiDPIImage() method is formatted.

    The @2x images are not preloaded in the LWCToolkit. It really can 
cause image reloading after moving a window from a display from one 
resolution to another.
    However, it is not clear during the MultiResolutionImage creation 
will the images be used on HiDPI displays or not.
    May be there should be a flag that enables the high resolution 
images preloading.

   The original image can be replaced by the high resolution one in the 
paint() method. It causes that the observer could get an image which is 
different from the original one.
   May be there is no any issue?  If a MultiResolutionImage is not used 
then all works as before. If a user implements MultiResolutionImage may 
be he needs to have an information
   about the actual drawn image in the observer even it is different 
from the original.

   Thanks,
   Alexandr.


On 11/12/2013 11:43 PM, Jim Graham wrote:
> Hi Alexander,
>
> Some minor issues with this fix:
>
> - All RenderingHints have a default setting where the system can 
> choose for you.  The primary thing that the default settings allow is 
> for the answer to be based off of another hint.  Often the QUALITY 
> hint provides the swing vote if an individual hint is left "DEFAULT".  
> That should probably also be the setting used for SG2D, and would 
> hinge off of the devScale, for example, as the deciding factor.
>
> - Descriptions for "on" and "off" should be something like "Use 
> resolution variants of images" and "Use only default resolution 
> variants of images" (and "Default resolution variant usage"). Most of 
> the other descriptions on hints are statements of what is going to 
> happen or what is going to be used rather than a simple 'the X state 
> is Y'.
>
> - It looks like the transform is used in SG2D to decide if the hiDPI 
> image should be used.  I'm not familiar with the Mac's native use of 
> @2x, but I thought that they hinged the decision off of the "retina 
> scale" of the display, not off of the current transform.  That way, if 
> you scale down an icon it doesn't change its look when it reaches .5x 
> scale (or .75x depending on the cutoff).  Personally, I think it is 
> better to not use the transform to keep animations smooth, but I'm not 
> sure what Apple did.
>
> - The logic in using the transform is also a bit murky.  I think if 
> you set the scale on a retina display to exactly 1/2 it would use the 
> HiDPI version even though the scale was 1:1.  Since I support not 
> examining the transform there, I'm going to present this as another 
> reason why we should just base it on devScale, but the logic could be 
> fixed if we really plan to use the transform here.
>
> - The new logic in "isHiDPIImage()" is confusing because you line up 
> logic operations from 2 different levels of parentheses.  I believe 
> that one version of our style guidelines included a rule that allowed 
> "indenting to parentheses level" and I would think that would be a 
> good rule to apply here.  Or do something else to make the logic flow 
> there less tricky to read.
>
> - Eventually we are going to need this support in more pipelines. I 
> believe that Win8 already has parameters that affect choices of 
> images, but they are only currently deployed on the Surface tablets 
> (i.e. there are no supported high DPI displays for desktop that I'm 
> aware of, but some of the Surface tablets ship with high DPI 
> screens).  What would the impact be if we moved this into a more 
> general class in src/share?  I suppose we might spend extra time 
> looking for variants of images that we don't need?
>
> - Has any thought been given to the issues that someone raised with 
> cursors?
>
> - Has any thought been given to my comments about MediaTracker and 
> image observer states for multi-res images?  I don't see any attempt 
> here to preload the @2x image.  The problem would probably only be 
> seen on multi-headed systems where one display is retina and one is 
> not - you would find the images suddenly reloading when you move the 
> window to the other screen and the application might not expect that 
> to happen.  Which image is the Observer registered on?  Since the 
> image is handed to the Observer, will an application be surprised when 
> their observer gets a handle to an image they've never seen?  Is it an 
> issue if one of the "alternate resolution variant" images leaks into 
> an application's "hands" via the observer callbacks?
>
>             ...jim
>
> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>
>>    Only internal API is exposed:
>>    - MultiResolutionImage interface with method
>> "getResolutionVariant(int width, int height)" is added to the
>> com.sun.awt package
>>    - Hints to switch on/off the resolution variant usage are added to
>> SunHints class
>>    - Test is updated to use the  MultiResolutionImage interface
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>
>>>    Thank you for the review.
>>>
>>>   Could you look at the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>
>>>   - URL is parsed to protocol, host, port, and path parts in the
>>> LWCToolkit class.
>>>      I checked that URL(protocol, host, port, file) constructor
>>> correctly handles -1 port value.
>>>   - Only last file name after last '/' in the URL path  is converted
>>> to @2x name
>>>   - Tests that check correct URL and path translation to @2x names are
>>> added to the ScalableImageTest
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>
>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>> like this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>> Hi Alexander,
>>>>
>>>> URLs like this:
>>>>
>>>> http://www.example.com/dir.ext/image
>>>>
>>>> will still be translated to:
>>>>
>>>> http://www.example.com/dir at 2x.ext/image
>>>>
>>>>
>>>> I think you need to search for last '.' after the last  '/' in the
>>>> getScaledImageName();
>>>>
>>>>
>>>> Also the following code has some additional bugs:
>>>>
>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>   854
>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>   856                     && !(image instanceof 
>>>> ScalableToolkitImage)) {
>>>>   857                 String protocol = url.getProtocol();
>>>>   858                 String host = url.getHost();
>>>>   859                 String file = url.getPath();
>>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>>   861                 try {
>>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>>   863                     url2x.openStream();
>>>>   864                     return new ScalableToolkitImage(image,
>>>> getDefaultToolkit().getImage(url2x));
>>>>   865                 } catch (Exception ignore) {
>>>>   866                 }
>>>>   867             }
>>>>   868             return image;
>>>>   869         }
>>>>
>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>> 860? Let's take the following URL for example:
>>>>
>>>> http://www.example.com/dir/image.jpg
>>>>
>>>> protocol = "http"
>>>> host = "www.example.com"
>>>> file = "/dir/image.jpg"
>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>> url2x = 
>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>
>>>>
>>>> You are missing a part in URL (de)construction - the optional port!
>>>> For example in the following URL:
>>>>
>>>> http://www.example.com:8080/dir/image.jpg
>>>>
>>>> You should extract the port from original URL and use it in new URL
>>>> construction if present (!= -1).
>>>>
>>>>
>>>> I would also close the stream explicitly after probing for existence
>>>> of resource rather than delegating to GC which might not be promptly
>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>> descriptors):
>>>>
>>>>         try (InputStream probe = url.openStream()) {}
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>
>>


From swingler at apple.com  Wed Nov 13 09:21:01 2013
From: swingler at apple.com (Mike Swingler)
Date: Wed, 13 Nov 2013 09:21:01 -0800
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5282ED9F.805@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>
Message-ID: <3F1315D7-D09F-46F2-8A72-4C43F9CE5D8F@apple.com>

On Nov 12, 2013, at 7:10 PM, Jim Graham <james.graham at oracle.com> wrote:

> So, then, it sounds like on the Mac the "default heuristic" should be to take the transform into account and choose @2x based on that.  We don't yet know if that matches the default Windows 8 heuristics, but we only have 1 platform that has this enabled so far.
> 
> One last question (OK 2) for Mike - I want to be sure that we get the algorithm right, you said "if the backing store would be the same size or smaller than the @1x" which implies that the code in the fix "if (w <= imgw && h <= imgh) regular : @2x" matches the heuristics in Cocoa? (i.e. && and <= are the correct comparison and logic?)

This check seems correct to me. If either the w or h of the destination rect needs more pixels than is available from w or h of a given representation, the logic should choose the next representation, or fall back to scaling up the available pixels in the largest representation (insert caveats about bit depth, color space, and vector drawing resources like PDF).

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

In the demo that I sent you ? the @2x gets chosen when displaying a scaled up image on a non-Retina display. The @2x is nothing special; it's just another representation. This is how NSImage has always worked long before Retina, since Mac OS X 10.0, AFAIK.

> Given that, I'd recommend:
> 
> - Add the DEFAULT setting for the SunHint which will basically say "do as Mac does when on a Mac"  (and eventually as Win8 does while on Win8, etc.)
> 
> - the current fix has the choice in the macosx code, which is good
> 
> - the current API provides the scaled dimensions, which is good for the mac code, but we may need to make more data available once we learn how other platforms solve this problem
> 
> - we may want to beef up the hints later with "choose based on Screen" vs "choose based on pixel size", but for now this API is sun.* private so lets just leave it with ON/OFF/DEFAULT.
> 
> - Hopefully the answers to the above 2 questions for Mike won't be surprising...
> 
> 			...jim

I hope I haven't surprised anyone. :-)

Regards,
Mike Swingler
Apple Inc.

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


From java3 at segal.org  Wed Nov 13 11:14:00 2013
From: java3 at segal.org (Mickey Segal)
Date: Wed, 13 Nov 2013 14:14:00 -0500
Subject: Local file reading by signed applets blocked by MacOS
Message-ID: <000601cee0a4$830d7a40$89286ec0$@segal.org>

A change in MacOS in the past week or two appears to have blocked local file reading by signed Java applets running Java 7.  I?ve illustrated the problem with a working example and full source code at http://www.segal.org/java/localFileRead/.  The problem does not seem to be related to Java 7 update 45 since it also occurs with Update 40, and that had been working fine until a week or two ago, as assessed by reports from users of a large applet.  The demo applet was prepared to demo the problem using concise code.  

 

A signed applet is supposed to be able to read and write local files.  Although this capability is restricted on some institutional networks, this is the first time these abilities have been restricted for individual users.

 

Does anyone know whether this is a bug, or done purposely by Apple?

 

Are there any workarounds of settings that a user can set to allow such file reading?

 

Since this appears to represent a change by Apple, should this be reported as an Apple bug, an Oracle Java bug, or both? 


From Sergey.Bylokhov at oracle.com  Wed Nov 13 11:25:47 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2013 23:25:47 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5283C9D5.30602@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> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com>
Message-ID: <5283D23B.6070505@oracle.com>

On 13.11.2013 22:49, Jim Graham wrote:
>
>
> On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
>> On 12.11.2013 23:43, Jim Graham wrote:
>>> - The logic in using the transform is also a bit murky.  I think if
>>> you set the scale on a retina display to exactly 1/2 it would use the
>>> HiDPI version even though the scale was 1:1.  Since I support not
>>> examining the transform there, I'm going to present this as another
>>> reason why we should just base it on devScale, but the logic could be
>>> fixed if we really plan to use the transform here.
>> It also allow to the user to use a transform and a hint and force the
>> images to draw the scaled version even to the BufferedImage fo ex. Which
>> can be useful in case of sequential drawing of BI-> BI->retina.
>
> I think you misunderstood me here.  I'm not saying anything about the 
> BI->BI->retina case.  I'm saying that even on pure retina your logic 
> chooses the wrong scale because of mistakes made in examining the 
> transform state type.
No I understood. But a transform of the sg2d already include devScale.
This part of the fix was changed from version to version. We could use 
devScale only, or a transform if it is scaled, or an any transform. If 
nobody objects, we could use any type of transform.
My point about BI1-BI2-retina is that the user cannot control devScale, 
and so cannot force BI1 to use scaled version. But if we take into 
account current transform of the SG2D, then user can control that via 
transform and hint.

>
> If devScale is 2, but the transform is a scale then the scales used to 
> compute the resolution image will be based solely on the transform.  
> If devScale is 2, but the transform is identity, then the scales used 
> to compute the resolution image should be 1.0 because that is the 
> actual scale being applied to the image, but the logic will use 2 
> (i.e. the devScale) instead because of bad handling of the 
> transformState.
>
> Also, in the case of TRANSFORM_GENERIC just the devScale is used even 
> if they scale it down to .001.
>
> You probably need to only use the transform if you are going to use it 
> at all and you need to use it for all transformState values (there may 
> be optimizations based on the transformState, but the most complete 
> transform type should not fall through to a default, neither should 
> the translate-only states).

>
>             ...jim


-- 
Best regards, Sergey.


From jesmith at kaon.com  Wed Nov 13 11:34:00 2013
From: jesmith at kaon.com (Joshua Smith)
Date: Wed, 13 Nov 2013 14:34:00 -0500
Subject: Local file reading by signed applets blocked by MacOS
In-Reply-To: <000601cee0a4$830d7a40$89286ec0$@segal.org>
References: <000601cee0a4$830d7a40$89286ec0$@segal.org>
Message-ID: <AE72A652-094A-49BE-9D2F-2842BD0CA5F0@kaon.com>

Did you include permissions in your Manifest?

It used to be that signing an applet was sufficient to get read permissions, but Oracle recently added the requirement that you explicitly list the permissions you want.

I am using a signed applet for uploading files, and not having any problems.

I use the "m" option to jar when I create the jar to put this into the manifest:

Codebase: *
Application-Name: { my application name }
Permissions: all-permissions

-Joshua

On Nov 13, 2013, at 2:14 PM, Mickey Segal <java3 at segal.org> wrote:

> A change in MacOS in the past week or two appears to have blocked local file reading by signed Java applets running Java 7.  I?ve illustrated the problem with a working example and full source code at http://www.segal.org/java/localFileRead/.  The problem does not seem to be related to Java 7 update 45 since it also occurs with Update 40, and that had been working fine until a week or two ago, as assessed by reports from users of a large applet.  The demo applet was prepared to demo the problem using concise code.  
> 
> 
> 
> A signed applet is supposed to be able to read and write local files.  Although this capability is restricted on some institutional networks, this is the first time these abilities have been restricted for individual users.
> 
> 
> 
> Does anyone know whether this is a bug, or done purposely by Apple?
> 
> 
> 
> Are there any workarounds of settings that a user can set to allow such file reading?
> 
> 
> 
> Since this appears to represent a change by Apple, should this be reported as an Apple bug, an Oracle Java bug, or both? 
> 


From Sergey.Bylokhov at oracle.com  Wed Nov 13 11:44:39 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2013 23:44:39 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5283D23B.6070505@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> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com> <5283D23B.6070505@oracle.com>
Message-ID: <5283D6A7.4040506@oracle.com>

On 13.11.2013 23:25, Sergey Bylokhov wrote:
>>>> - The logic in using the transform is also a bit murky.  I think if
>>>> you set the scale on a retina display to exactly 1/2 it would use the
>>>> HiDPI version even though the scale was 1:1.  Since I support not
>>>> examining the transform there, I'm going to present this as another
>>>> reason why we should just base it on devScale, but the logic could be
>>>> fixed if we really plan to use the transform here.
>>> It also allow to the user to use a transform and a hint and force the
>>> images to draw the scaled version even to the BufferedImage fo ex. 
>>> Which
>>> can be useful in case of sequential drawing of BI-> BI->retina.
>>
>> I think you misunderstood me here.  I'm not saying anything about the 
>> BI->BI->retina case.  I'm saying that even on pure retina your logic 
>> chooses the wrong scale because of mistakes made in examining the 
>> transform state type.
> No I understood. But a transform of the sg2d already include devScale.
> This part of the fix was changed from version to version. We could use 
> devScale only, or a transform if it is scaled, or an any transform. If 
> nobody objects, we could use any type of transform.
> My point about BI1-BI2-retina is that the user cannot control 
> devScale, and so cannot force BI1 to use scaled version. But if we 
> take into account current transform of the SG2D, then user can control 
> that via transform and hint.
I just realize that hint is not necessary now and can be skip it, 
because we use instanceof anyway(img instanceof MultiResolutionImage).
>
>>
>> If devScale is 2, but the transform is a scale then the scales used 
>> to compute the resolution image will be based solely on the 
>> transform.  If devScale is 2, but the transform is identity, then the 
>> scales used to compute the resolution image should be 1.0 because 
>> that is the actual scale being applied to the image, but the logic 
>> will use 2 (i.e. the devScale) instead because of bad handling of the 
>> transformState.
>>
>> Also, in the case of TRANSFORM_GENERIC just the devScale is used even 
>> if they scale it down to .001.
>>
>> You probably need to only use the transform if you are going to use 
>> it at all and you need to use it for all transformState values (there 
>> may be optimizations based on the transformState, but the most 
>> complete transform type should not fall through to a default, neither 
>> should the translate-only states).
>
>>
>>             ...jim
>
>


-- 
Best regards, Sergey.


From java3 at segal.org  Wed Nov 13 12:50:40 2013
From: java3 at segal.org (Mickey Segal)
Date: Wed, 13 Nov 2013 15:50:40 -0500
Subject: Local file reading by signed applets blocked by MacOS
Message-ID: <001101cee0b2$03ce3810$0b6aa830$@segal.org>

I?ve also demonstrated that the same problem affects a signed Java applet trying to write files on the Macintosh.  The write-up is at http://www.segal.org/java/localFileWrite/.  Each write-up references the other so as to give a more complete version of the problem.

 

Feedback would be appreciated so as to improve the usefulness of bug reports, as described in the original message.

 

I wrote:

 

A change in MacOS in the past week or two appears to have blocked local file reading by signed Java applets running Java 7.  I?ve illustrated the problem with a working example and full source code at http://www.segal.org/java/localFileRead/.  The problem does not seem to be related to Java 7 update 45 since it also occurs with Update 40, and that had been working fine until a week or two ago, as assessed by reports from users of a large applet.  The demo applet was prepared to demo the problem using concise code.  

 

A signed applet is supposed to be able to read and write local files.  Although this capability is restricted on some institutional networks, this is the first time these abilities have been restricted for individual users.

 

Does anyone know whether this is a bug, or done purposely by Apple?

 

Are there any workarounds of settings that a user can set to allow such file reading?

 

Since this appears to represent a change by Apple, should this be reported as an Apple bug, an Oracle Java bug, or both? 


From swingler at apple.com  Wed Nov 13 13:09:41 2013
From: swingler at apple.com (Mike Swingler)
Date: Wed, 13 Nov 2013 13:09:41 -0800
Subject: Local file reading by signed applets blocked by MacOS
In-Reply-To: <001101cee0b2$03ce3810$0b6aa830$@segal.org>
References: <001101cee0b2$03ce3810$0b6aa830$@segal.org>
Message-ID: <965634EE-92F7-4125-8BE2-615B31EFC51C@apple.com>

In Safari, you now have to explicitly drop the OS sandbox put around the Java process, per site:

Safari > Preferences > Security > Manage Website Settings? > Java > (your site) > Run in Unsafe Mode

Regards,
Mike Swingler
Apple Inc.

On Nov 13, 2013, at 12:50 PM, Mickey Segal <java3 at segal.org> wrote:

> I?ve also demonstrated that the same problem affects a signed Java applet trying to write files on the Macintosh.  The write-up is at http://www.segal.org/java/localFileWrite/.  Each write-up references the other so as to give a more complete version of the problem.
> 
> 
> 
> Feedback would be appreciated so as to improve the usefulness of bug reports, as described in the original message.
> 
> 
> 
> I wrote:
> 
> 
> 
> A change in MacOS in the past week or two appears to have blocked local file reading by signed Java applets running Java 7.  I?ve illustrated the problem with a working example and full source code at http://www.segal.org/java/localFileRead/.  The problem does not seem to be related to Java 7 update 45 since it also occurs with Update 40, and that had been working fine until a week or two ago, as assessed by reports from users of a large applet.  The demo applet was prepared to demo the problem using concise code.  
> 
> 
> 
> A signed applet is supposed to be able to read and write local files.  Although this capability is restricted on some institutional networks, this is the first time these abilities have been restricted for individual users.
> 
> 
> 
> Does anyone know whether this is a bug, or done purposely by Apple?
> 
> 
> 
> Are there any workarounds of settings that a user can set to allow such file reading?
> 
> 
> 
> Since this appears to represent a change by Apple, should this be reported as an Apple bug, an Oracle Java bug, or both? 
> 


From Sergey.Bylokhov at oracle.com  Wed Nov 13 13:55:37 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Nov 2013 01:55:37 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5283C9D5.30602@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> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com>
Message-ID: <5283F559.2020007@oracle.com>

Hello, Jim.
On 13.11.2013 22:49, Jim Graham wrote:
> That's could be a problem. Is it possible to wrap imageObserver, which
>> was passed to the drawImage, and replace one image to another in the
>> WrapperImageObserver.imageUpdate()?
>
> It's possible - the things to watch out for:
>
> - they could hand the same IO in for multiple drawImage calls to 
> multiple images
>
> - they could hand the same IO in repeatedly for the same image while 
> it is loading if the loading takes a while or the image is animated; 
> you don't want to necessarily create an infinite number of wrappers 
> for the same observer and register them all with the image loading 
> mechanism
>
> - the image that you report to them should probably be the original 
> image, not the resolution-specific underlying images
>
> - we need to deal with making sure that the information flowing to the 
> IO does not report complete until all resolution variants that we plan 
> to load are done
>
> - given Mike's answer to my previous questions, it looks like @2x is 
> not a retina-specific issue, all images do that even non non-retina 
> apparently so maybe we do want to load all variants up front?
>
> - we don't want to pass ERROR conditions to the IO unless all 
> resolution variants are errored, we should silently swallow any ERROR 
> conditions for just some of the resolution variants and make do with 
> what we have
Well, it is necessary to decide that it is simpler to bypass all these 
problems or to move them to the user. As ScalableToolkitImage 
implementation is trivial.
>
>             ...jim


-- 
Best regards, Sergey.


From java3 at segal.org  Wed Nov 13 14:47:01 2013
From: java3 at segal.org (Mickey Segal)
Date: Wed, 13 Nov 2013 17:47:01 -0500
Subject: Local file reading by signed applets blocked by MacOS
Message-ID: <000301cee0c2$44f5cdc0$cee16940$@segal.org>

I found a further problem and a workaround to both problems.

 

The workaround is to use Firefox, which does not suffer from the problem described below.  So it seems that a recent Safari update must be the problem.  In addition, the ability of a signed applet to use Runtime.getRuntime().exec to launch new browser windows also continues to work in Firefox, but doesn?t work in Safari.  

 

So it seems clear that a bug report should go to Apple, not Oracle.  Also, there is a good workaround to use Firefox, so we will let our users know that they can stay with Macintosh, but just avoid Safari.  

 

If others have input, particularly on ways of coaxing safari into working, that would be appreciated.     

 

I wrote:

 

I?ve also demonstrated that the same problem affects a signed Java applet trying to write files on the Macintosh.  The write-up is at http://www.segal.org/java/localFileWrite/.  Each write-up references the other so as to give a more complete version of the problem.

 

Feedback would be appreciated so as to improve the usefulness of bug reports, as described in the original message.

 

I wrote:

 

A change in MacOS in the past week or two appears to have blocked local file reading by signed Java applets running Java 7.  I?ve illustrated the problem with a working example and full source code at http://www.segal.org/java/localFileRead/.  The problem does not seem to be related to Java 7 update 45 since it also occurs with Update 40, and that had been working fine until a week or two ago, as assessed by reports from users of a large applet.  The demo applet was prepared to demo the problem using concise code.  

 

A signed applet is supposed to be able to read and write local files.  Although this capability is restricted on some institutional networks, this is the first time these abilities have been restricted for individual users.

 

Does anyone know whether this is a bug, or done purposely by Apple?

 

Are there any workarounds of settings that a user can set to allow such file reading?

 

Since this appears to represent a change by Apple, should this be reported as an Apple bug, an Oracle Java bug, or both? 


From java3 at segal.org  Thu Nov 14 05:39:33 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 14 Nov 2013 08:39:33 -0500
Subject: Local file reading by signed applets blocked by MacOS
In-Reply-To: <965634EE-92F7-4125-8BE2-615B31EFC51C@apple.com>
References: <001101cee0b2$03ce3810$0b6aa830$@segal.org>
	<965634EE-92F7-4125-8BE2-615B31EFC51C@apple.com>
Message-ID: <005701cee13e$f4bd6d40$de3847c0$@segal.org>

Thanks for the clarification.  The "Run in Unsafe Mode" language, however, is a bit extreme for a situation in which a user has already accepted a digital certificate.  Something along the lines of "Trust the digital certificate I already trusted" would seem more accurate.  However, even that reminds me of the security warning overreaction in Windows Vista, in which one constantly got dialog boxes of "do you want to do what you just asked to do".  Subsequent versions of Windows took a more Apple-like approach to security, but it sounds like Apple is now taking a Vista-like approach here.

We'll modify our warning about the Macintosh problems affecting our software to include this workaround, but due to one other Safari bug (http://www.segal.org/java/Hello/) and one other Macintosh Java problem that Oracle is blaming on Apple (http://www.segal.org/java/refresh4/), we already have a special warning on our software for Macintosh users leading to a list of problems to be worked around.

Mike Swingler [mailto:swingler at apple.com] wrote: 
Sent: Wednesday, November 13, 2013 4:10 PM

In Safari, you now have to explicitly drop the OS sandbox put around the Java process, per site:

Safari > Preferences > Security > Manage Website Settings? > Java > (your site) > Run in Unsafe Mode

Regards,
Mike Swingler
Apple Inc.



From vbarot at tibco.com  Mon Nov 18 14:51:05 2013
From: vbarot at tibco.com (Viral Barot)
Date: Mon, 18 Nov 2013 22:51:05 +0000
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
Message-ID: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>

Accessing AWT frame from a thread causes the application to freeze when executed with JRE 7. The AWT frame is created with SWT_AWT bridge.

Below is the test case in which call to frame.setVisible(true); from the AWT event dispatching thread does not return.

Test Case:
import java.awt.Button;
import java.awt.Color;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.lang.reflect.InvocationTargetException;

import javax.swing.JOptionPane;
import javax.swing.SwingUtilities;

import org.eclipse.swt.SWT;
import org.eclipse.swt.awt.SWT_AWT;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Composite;

public class Main {

  public static void main(String[] args) {



if(System.getProperty("os.name").toLowerCase().startsWith("mac")){
SWT_AWT.embeddedFrameClass = "sun.lwawt.macosx.CViewEmbeddedFrame";
}


    Display display = new Display();
    Shell shell = new Shell(display);
    shell.setText("Shell");
    shell.setSize(200, 200);
    shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_BLUE));



    final Composite composite = new Composite(shell, SWT.EMBEDDED);
    GridLayout gridLayout = new GridLayout();
    gridLayout.numColumns = 1;
    composite.setLayout(gridLayout);
    composite.setSize(200,200);
    composite.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WHITE));



    final java.awt.Frame frame  = SWT_AWT.new_Frame(composite);
frame.setVisible(false);
frame.setBackground(Color.red);
frame.setSize(200, 200);
    Button button = new Button("Submit");
    button.addActionListener(new ActionListener() {


@Override
public void actionPerformed(ActionEvent e) {


JOptionPane.showMessageDialog(null, "Hello");
}
});
    frame.add(button);
    frame.doLayout();



    try {
SwingUtilities.invokeAndWait(new Runnable() {


@Override
public void run() {
frame.setVisible(true);
}
});
} catch (InterruptedException e1) {
e1.printStackTrace();
} catch (InvocationTargetException e1) {
e1.printStackTrace();
}
    shell.open();



    while (!shell.isDisposed()) {
      if (!display.readAndDispatch())
        display.sleep();
    }
    display.dispose();



  }
}

Below is the thread dump for this.

"AWT-EventQueue-0" prio=5 tid=0x00007f8d0b087000 nid=0x8703 runnable [0x0000000195e40000]
   java.lang.Thread.State: RUNNABLE
at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
at java.awt.Component.updateCursorImmediately(Component.java:3123)
at java.awt.Component.show(Component.java:1626)
- locked <0x0000000160c5b8c8> (a java.awt.Component$AWTTreeLock)
at java.awt.Window.show(Window.java:1042)
at sun.awt.EmbeddedFrame.show(EmbeddedFrame.java:179)
at java.awt.Component.show(Component.java:1651)
at java.awt.Component.setVisible(Component.java:1603)
at java.awt.Window.setVisible(Window.java:1014)
at Main$2.run(Main.java:60)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

   Locked ownable synchronizers:
- None

While in the above test case if invokeLater is called instead of invokeAndWait, the test case runs fine. But in my application the invokeLater calls also freeze at same location.

This behavoir happens with SWT 3.7.2 as well as 4.3.





From ashesfall at gmail.com  Mon Nov 18 14:58:11 2013
From: ashesfall at gmail.com (Mike Murray)
Date: Mon, 18 Nov 2013 14:58:11 -0800
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
In-Reply-To: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
References: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
Message-ID: <CAFYxmCVAs-Y6Cm1bQnHrf-ROesQ2nR6ojbbzsZHkS67ftn=0BQ@mail.gmail.com>

This is a developer error. You can't call invoke and wait from an event
method because invoke and wait puts your new runnable on the queue but
since you are waiting from the queue itself it hangs. You need to comb your
codebase and deal with this issue. These invoke methods are to be used
outside the AWT dispatch thread.

-m


On Mon, Nov 18, 2013 at 2:51 PM, Viral Barot <vbarot at tibco.com> wrote:

> Accessing AWT frame from a thread causes the application to freeze when
> executed with JRE 7. The AWT frame is created with SWT_AWT bridge.
>
> Below is the test case in which call to frame.setVisible(true); from the
> AWT event dispatching thread does not return.
>
> Test Case:
> import java.awt.Button;
> import java.awt.Color;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.lang.reflect.InvocationTargetException;
>
> import javax.swing.JOptionPane;
> import javax.swing.SwingUtilities;
>
> import org.eclipse.swt.SWT;
> import org.eclipse.swt.awt.SWT_AWT;
> import org.eclipse.swt.layout.GridLayout;
> import org.eclipse.swt.widgets.Display;
> import org.eclipse.swt.widgets.Shell;
> import org.eclipse.swt.widgets.Composite;
>
> public class Main {
>
>   public static void main(String[] args) {
>
>
>
> if(System.getProperty("os.name").toLowerCase().startsWith("mac")){
> SWT_AWT.embeddedFrameClass = "sun.lwawt.macosx.CViewEmbeddedFrame";
> }
>
>
>     Display display = new Display();
>     Shell shell = new Shell(display);
>     shell.setText("Shell");
>     shell.setSize(200, 200);
>
> shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_BLUE));
>
>
>
>     final Composite composite = new Composite(shell, SWT.EMBEDDED);
>     GridLayout gridLayout = new GridLayout();
>     gridLayout.numColumns = 1;
>     composite.setLayout(gridLayout);
>     composite.setSize(200,200);
>
> composite.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WHITE));
>
>
>
>     final java.awt.Frame frame  = SWT_AWT.new_Frame(composite);
> frame.setVisible(false);
> frame.setBackground(Color.red);
> frame.setSize(200, 200);
>     Button button = new Button("Submit");
>     button.addActionListener(new ActionListener() {
>
>
> @Override
> public void actionPerformed(ActionEvent e) {
>
>
> JOptionPane.showMessageDialog(null, "Hello");
> }
> });
>     frame.add(button);
>     frame.doLayout();
>
>
>
>     try {
> SwingUtilities.invokeAndWait(new Runnable() {
>
>
> @Override
> public void run() {
> frame.setVisible(true);
> }
> });
> } catch (InterruptedException e1) {
> e1.printStackTrace();
> } catch (InvocationTargetException e1) {
> e1.printStackTrace();
> }
>     shell.open();
>
>
>
>     while (!shell.isDisposed()) {
>       if (!display.readAndDispatch())
>         display.sleep();
>     }
>     display.dispose();
>
>
>
>   }
> }
>
> Below is the thread dump for this.
>
> "AWT-EventQueue-0" prio=5 tid=0x00007f8d0b087000 nid=0x8703 runnable
> [0x0000000195e40000]
>    java.lang.Thread.State: RUNNABLE
> at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
> at
> sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
> at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
> at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
> at
> sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
> at java.awt.Component.updateCursorImmediately(Component.java:3123)
> at java.awt.Component.show(Component.java:1626)
> - locked <0x0000000160c5b8c8> (a java.awt.Component$AWTTreeLock)
> at java.awt.Window.show(Window.java:1042)
> at sun.awt.EmbeddedFrame.show(EmbeddedFrame.java:179)
> at java.awt.Component.show(Component.java:1651)
> at java.awt.Component.setVisible(Component.java:1603)
> at java.awt.Window.setVisible(Window.java:1014)
> at Main$2.run(Main.java:60)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
> at java.awt.EventQueue.access$200(EventQueue.java:103)
> at java.awt.EventQueue$3.run(EventQueue.java:694)
> at java.awt.EventQueue$3.run(EventQueue.java:692)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
>
>    Locked ownable synchronizers:
> - None
>
> While in the above test case if invokeLater is called instead of
> invokeAndWait, the test case runs fine. But in my application the
> invokeLater calls also freeze at same location.
>
> This behavoir happens with SWT 3.7.2 as well as 4.3.
>
>
>
>
>


-- 
--------------------------------------------------------------------------------------
Disco Mike - Amphicoelous (Original Mix)
Now available on Beatport
Buy it now at: http://btprt.dj/WeaNGz

From vbarot at tibco.com  Mon Nov 18 15:01:45 2013
From: vbarot at tibco.com (Viral Barot)
Date: Mon, 18 Nov 2013 23:01:45 +0000
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
In-Reply-To: <CAFYxmCVAs-Y6Cm1bQnHrf-ROesQ2nR6ojbbzsZHkS67ftn=0BQ@mail.gmail.com>
References: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
	<CAFYxmCVAs-Y6Cm1bQnHrf-ROesQ2nR6ojbbzsZHkS67ftn=0BQ@mail.gmail.com>
Message-ID: <F5DC3BEC-649C-4379-9AD2-37792CB2B29F@tibco.com>

I am calling the invokeAndWait from Main thread.

On Nov 18, 2013, at 2:58 PM, Mike Murray <ashesfall at gmail.com<mailto:ashesfall at gmail.com>>
 wrote:

This is a developer error. You can't call invoke and wait from an event method because invoke and wait puts your new runnable on the queue but since you are waiting from the queue itself it hangs. You need to comb your codebase and deal with this issue. These invoke methods are to be used outside the AWT dispatch thread.

-m


On Mon, Nov 18, 2013 at 2:51 PM, Viral Barot <vbarot at tibco.com<mailto:vbarot at tibco.com>> wrote:
Accessing AWT frame from a thread causes the application to freeze when executed with JRE 7. The AWT frame is created with SWT_AWT bridge.

Below is the test case in which call to frame.setVisible(true); from the AWT event dispatching thread does not return.

Test Case:
import java.awt.Button;
import java.awt.Color;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.lang.reflect.InvocationTargetException;

import javax.swing.JOptionPane;
import javax.swing.SwingUtilities;

import org.eclipse.swt.SWT;
import org.eclipse.swt.awt.SWT_AWT;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Composite;

public class Main {

  public static void main(String[] args) {



if(System.getProperty("os.name<http://os.name/>").toLowerCase().startsWith("mac")){
SWT_AWT.embeddedFrameClass = "sun.lwawt.macosx.CViewEmbeddedFrame";
}


    Display display = new Display();
    Shell shell = new Shell(display);
    shell.setText("Shell");
    shell.setSize(200, 200);
    shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_BLUE));



    final Composite composite = new Composite(shell, SWT.EMBEDDED);
    GridLayout gridLayout = new GridLayout();
    gridLayout.numColumns = 1;
    composite.setLayout(gridLayout);
    composite.setSize(200,200);
    composite.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WHITE));



    final java.awt.Frame frame  = SWT_AWT.new_Frame(composite);
frame.setVisible(false);
frame.setBackground(Color.red);
frame.setSize(200, 200);
    Button button = new Button("Submit");
    button.addActionListener(new ActionListener() {


@Override
public void actionPerformed(ActionEvent e) {


JOptionPane.showMessageDialog(null, "Hello");
}
});
    frame.add(button);
    frame.doLayout();



    try {
SwingUtilities.invokeAndWait(new Runnable() {


@Override
public void run() {
frame.setVisible(true);
}
});
} catch (InterruptedException e1) {
e1.printStackTrace();
} catch (InvocationTargetException e1) {
e1.printStackTrace();
}
    shell.open();



    while (!shell.isDisposed()) {
      if (!display.readAndDispatch())
        display.sleep();
    }
    display.dispose();



  }
}

Below is the thread dump for this.

"AWT-EventQueue-0" prio=5 tid=0x00007f8d0b087000 nid=0x8703 runnable [0x0000000195e40000]
   java.lang.Thread.State: RUNNABLE
at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
at java.awt.Component.updateCursorImmediately(Component.java:3123)
at java.awt.Component.show(Component.java:1626)
- locked <0x0000000160c5b8c8> (a java.awt.Component$AWTTreeLock)
at java.awt.Window.show(Window.java:1042)
at sun.awt.EmbeddedFrame.show(EmbeddedFrame.java:179)
at java.awt.Component.show(Component.java:1651)
at java.awt.Component.setVisible(Component.java:1603)
at java.awt.Window.setVisible(Window.java:1014)
at Main$2.run(Main.java:60)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

   Locked ownable synchronizers:
- None

While in the above test case if invokeLater is called instead of invokeAndWait, the test case runs fine. But in my application the invokeLater calls also freeze at same location.

This behavoir happens with SWT 3.7.2 as well as 4.3.







--
--------------------------------------------------------------------------------------
Disco Mike - Amphicoelous (Original Mix)
Now available on Beatport
Buy it now at: http://btprt.dj/WeaNGz


From ashesfall at gmail.com  Mon Nov 18 15:04:34 2013
From: ashesfall at gmail.com (Mike Murray)
Date: Mon, 18 Nov 2013 15:04:34 -0800
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
In-Reply-To: <F5DC3BEC-649C-4379-9AD2-37792CB2B29F@tibco.com>
References: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
	<CAFYxmCVAs-Y6Cm1bQnHrf-ROesQ2nR6ojbbzsZHkS67ftn=0BQ@mail.gmail.com>
	<F5DC3BEC-649C-4379-9AD2-37792CB2B29F@tibco.com>
Message-ID: <CAFYxmCUkjQTJCJMenDabibGQRqK1dfL3fY08uyxMhH_eZ_ukbg@mail.gmail.com>

Oh, I apologize. the poor formatting of my email client caused me to
misread your code sample.


On Mon, Nov 18, 2013 at 3:01 PM, Viral Barot <vbarot at tibco.com> wrote:

>  I am calling the invokeAndWait from Main thread.
>
>  On Nov 18, 2013, at 2:58 PM, Mike Murray <ashesfall at gmail.com>
>  wrote:
>
>  This is a developer error. You can't call invoke and wait from an event
> method because invoke and wait puts your new runnable on the queue but
> since you are waiting from the queue itself it hangs. You need to comb your
> codebase and deal with this issue. These invoke methods are to be used
> outside the AWT dispatch thread.
>
>  -m
>
>
> On Mon, Nov 18, 2013 at 2:51 PM, Viral Barot <vbarot at tibco.com> wrote:
>
>> Accessing AWT frame from a thread causes the application to freeze when
>> executed with JRE 7. The AWT frame is created with SWT_AWT bridge.
>>
>> Below is the test case in which call to frame.setVisible(true); from the
>> AWT event dispatching thread does not return.
>>
>> Test Case:
>> import java.awt.Button;
>> import java.awt.Color;
>> import java.awt.event.ActionEvent;
>> import java.awt.event.ActionListener;
>> import java.lang.reflect.InvocationTargetException;
>>
>> import javax.swing.JOptionPane;
>> import javax.swing.SwingUtilities;
>>
>> import org.eclipse.swt.SWT;
>> import org.eclipse.swt.awt.SWT_AWT;
>> import org.eclipse.swt.layout.GridLayout;
>> import org.eclipse.swt.widgets.Display;
>> import org.eclipse.swt.widgets.Shell;
>> import org.eclipse.swt.widgets.Composite;
>>
>> public class Main {
>>
>>   public static void main(String[] args) {
>>
>>
>>
>> if(System.getProperty("os.name").toLowerCase().startsWith("mac")){
>> SWT_AWT.embeddedFrameClass = "sun.lwawt.macosx.CViewEmbeddedFrame";
>> }
>>
>>
>>     Display display = new Display();
>>     Shell shell = new Shell(display);
>>     shell.setText("Shell");
>>     shell.setSize(200, 200);
>>
>> shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_BLUE));
>>
>>
>>
>>     final Composite composite = new Composite(shell, SWT.EMBEDDED);
>>     GridLayout gridLayout = new GridLayout();
>>     gridLayout.numColumns = 1;
>>     composite.setLayout(gridLayout);
>>     composite.setSize(200,200);
>>
>> composite.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WHITE));
>>
>>
>>
>>     final java.awt.Frame frame  = SWT_AWT.new_Frame(composite);
>> frame.setVisible(false);
>> frame.setBackground(Color.red);
>> frame.setSize(200, 200);
>>     Button button = new Button("Submit");
>>     button.addActionListener(new ActionListener() {
>>
>>
>> @Override
>> public void actionPerformed(ActionEvent e) {
>>
>>
>> JOptionPane.showMessageDialog(null, "Hello");
>> }
>> });
>>     frame.add(button);
>>     frame.doLayout();
>>
>>
>>
>>     try {
>> SwingUtilities.invokeAndWait(new Runnable() {
>>
>>
>> @Override
>> public void run() {
>> frame.setVisible(true);
>> }
>> });
>> } catch (InterruptedException e1) {
>> e1.printStackTrace();
>> } catch (InvocationTargetException e1) {
>> e1.printStackTrace();
>> }
>>     shell.open();
>>
>>
>>
>>     while (!shell.isDisposed()) {
>>       if (!display.readAndDispatch())
>>         display.sleep();
>>     }
>>     display.dispose();
>>
>>
>>
>>   }
>> }
>>
>> Below is the thread dump for this.
>>
>> "AWT-EventQueue-0" prio=5 tid=0x00007f8d0b087000 nid=0x8703 runnable
>> [0x0000000195e40000]
>>    java.lang.Thread.State: RUNNABLE
>> at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
>> at
>> sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
>> at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
>> at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
>> at
>> sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
>> at java.awt.Component.updateCursorImmediately(Component.java:3123)
>> at java.awt.Component.show(Component.java:1626)
>> - locked <0x0000000160c5b8c8> (a java.awt.Component$AWTTreeLock)
>> at java.awt.Window.show(Window.java:1042)
>> at sun.awt.EmbeddedFrame.show(EmbeddedFrame.java:179)
>> at java.awt.Component.show(Component.java:1651)
>> at java.awt.Component.setVisible(Component.java:1603)
>> at java.awt.Window.setVisible(Window.java:1014)
>> at Main$2.run(Main.java:60)
>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
>> at java.awt.EventQueue.access$200(EventQueue.java:103)
>> at java.awt.EventQueue$3.run(EventQueue.java:694)
>> at java.awt.EventQueue$3.run(EventQueue.java:692)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
>> at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
>> at
>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
>> at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
>>
>>    Locked ownable synchronizers:
>> - None
>>
>> While in the above test case if invokeLater is called instead of
>> invokeAndWait, the test case runs fine. But in my application the
>> invokeLater calls also freeze at same location.
>>
>> This behavoir happens with SWT 3.7.2 as well as 4.3.
>>
>>
>>
>>
>>
>
>
>  --
>
> --------------------------------------------------------------------------------------
> Disco Mike - Amphicoelous (Original Mix)
> Now available on Beatport
> Buy it now at: http://btprt.dj/WeaNGz
>
>
>


-- 
--------------------------------------------------------------------------------------
Disco Mike - Amphicoelous (Original Mix)
Now available on Beatport
Buy it now at: http://btprt.dj/WeaNGz

From petr.pchelko at oracle.com  Mon Nov 18 22:55:33 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 19 Nov 2013 10:55:33 +0400
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
In-Reply-To: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
References: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
Message-ID: <D77D051E-F553-44A9-B631-50CC3DB792DF@oracle.com>

Hello, Viral.

It's known that there are some deadlocks in SWT_AWT bridge on Mac. Here's an example:
https://bugs.openjdk.java.net/browse/JDK-8020165

It would be useful if you also post the dump of an Appkit thread to identify your particular case.

The deadlock occurs because AWT is called on the main thread. So the main thread get blocked
on some internal AWT lock, while the EventDispatchThread is trying to perform a synchronous operation
on the main thread. It's not quite obvious how to fix that internally, because for the normal AWT application
we have a strict rule not to acquire locks on the Appkit thread. 

For now the workaround could be to wrap all the usages of AWT inside invokeLater (except the initial  
SWT_AWT.new_Frame(composite) call). This should fix your deadlock. 

Also, which version of SWT are you using? The newer versions are patched so that you could not set the 
embeddedFrameClass explicitly. That patch also contains additional changes in bridge initialization,
so the bridge does not work quite well with older versions. This could be another reason of your deadlock.

With best regards. Petr.

On 19.11.2013, at 2:51, Viral Barot <vbarot at tibco.com> wrote:

> Accessing AWT frame from a thread causes the application to freeze when executed with JRE 7. The AWT frame is created with SWT_AWT bridge.
> 
> Below is the test case in which call to frame.setVisible(true); from the AWT event dispatching thread does not return.
> 
> Test Case:
> import java.awt.Button;
> import java.awt.Color;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.lang.reflect.InvocationTargetException;
> 
> import javax.swing.JOptionPane;
> import javax.swing.SwingUtilities;
> 
> import org.eclipse.swt.SWT;
> import org.eclipse.swt.awt.SWT_AWT;
> import org.eclipse.swt.layout.GridLayout;
> import org.eclipse.swt.widgets.Display;
> import org.eclipse.swt.widgets.Shell;
> import org.eclipse.swt.widgets.Composite;
> 
> public class Main {
> 
>  public static void main(String[] args) {
> 
> 
> 
> if(System.getProperty("os.name").toLowerCase().startsWith("mac")){
> SWT_AWT.embeddedFrameClass = "sun.lwawt.macosx.CViewEmbeddedFrame";
> }
> 
> 
>    Display display = new Display();
>    Shell shell = new Shell(display);
>    shell.setText("Shell");
>    shell.setSize(200, 200);
>    shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_BLUE));
> 
> 
> 
>    final Composite composite = new Composite(shell, SWT.EMBEDDED);
>    GridLayout gridLayout = new GridLayout();
>    gridLayout.numColumns = 1;
>    composite.setLayout(gridLayout);
>    composite.setSize(200,200);
>    composite.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WHITE));
> 
> 
> 
>    final java.awt.Frame frame  = SWT_AWT.new_Frame(composite);
> frame.setVisible(false);
> frame.setBackground(Color.red);
> frame.setSize(200, 200);
>    Button button = new Button("Submit");
>    button.addActionListener(new ActionListener() {
> 
> 
> @Override
> public void actionPerformed(ActionEvent e) {
> 
> 
> JOptionPane.showMessageDialog(null, "Hello");
> }
> });
>    frame.add(button);
>    frame.doLayout();
> 
> 
> 
>    try {
> SwingUtilities.invokeAndWait(new Runnable() {
> 
> 
> @Override
> public void run() {
> frame.setVisible(true);
> }
> });
> } catch (InterruptedException e1) {
> e1.printStackTrace();
> } catch (InvocationTargetException e1) {
> e1.printStackTrace();
> }
>    shell.open();
> 
> 
> 
>    while (!shell.isDisposed()) {
>      if (!display.readAndDispatch())
>        display.sleep();
>    }
>    display.dispose();
> 
> 
> 
>  }
> }
> 
> Below is the thread dump for this.
> 
> "AWT-EventQueue-0" prio=5 tid=0x00007f8d0b087000 nid=0x8703 runnable [0x0000000195e40000]
>   java.lang.Thread.State: RUNNABLE
> at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
> at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
> at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
> at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
> at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
> at java.awt.Component.updateCursorImmediately(Component.java:3123)
> at java.awt.Component.show(Component.java:1626)
> - locked <0x0000000160c5b8c8> (a java.awt.Component$AWTTreeLock)
> at java.awt.Window.show(Window.java:1042)
> at sun.awt.EmbeddedFrame.show(EmbeddedFrame.java:179)
> at java.awt.Component.show(Component.java:1651)
> at java.awt.Component.setVisible(Component.java:1603)
> at java.awt.Window.setVisible(Window.java:1014)
> at Main$2.run(Main.java:60)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
> at java.awt.EventQueue.access$200(EventQueue.java:103)
> at java.awt.EventQueue$3.run(EventQueue.java:694)
> at java.awt.EventQueue$3.run(EventQueue.java:692)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
> 
>   Locked ownable synchronizers:
> - None
> 
> While in the above test case if invokeLater is called instead of invokeAndWait, the test case runs fine. But in my application the invokeLater calls also freeze at same location.
> 
> This behavoir happens with SWT 3.7.2 as well as 4.3.
> 
> 
> 
> 


From alexandr.scherbatiy at oracle.com  Tue Nov 19 05:06:37 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Nov 2013 17:06:37 +0400
Subject: <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos
	look perfect on retina displays
In-Reply-To: <5283D2F9.6010100@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>
Message-ID: <528B625D.7060406@oracle.com>


   Could you review the updated fix:
      http://cr.openjdk.java.net/~alexsch/8011059/webrev.08/
      - Some related to the ToolkitImage staff is moved from SunToolkit 
to ToolkitImageUtil
      - MultiResolutionToolkitImage is moved from the LWCToolkit to 
sun.awt.image package
      - Preloading for the resolution variants is added
      - Algorithm for the retrieving resolution variants in 
g.drawImage() method is updated
      - The test is updated

    See more comments inline:

On 11/13/2013 11:28 PM, Jim Graham wrote:
> Hi Alexander,
>
> Please read my followup message on the wording for the SunHint 
> descriptions.  The version you used in this webrev contains multiple 
> conflicting uses of the word "default".
>
> The default value for the hint should be DEFAULT.  Note that Mike has 
> already stated that NSImage uses @2x even on non-retina displays so it 
> is not clear that the default should be different depending on devScale.
      The fix sets the resolution variant hint to default on Mac OS X 
and to off for other platforms now.
>
> Mike's latest response raises the question - if someone creates an 
> application with embedded @2x images, then they will get @2x on Macs 
> even if they have a non-retina display (if they use Cocoa). If we 
> follow the same principles here, then a developer developing a Java 
> app on a non-retina Mac would see the @2x images when they scale up 
> and might get the impression that the @2x images will be used on any 
> display with a transform, but the code to deal with them is only in 
> the Mac platform code.  Should this support be more universal than that?
>
> The logic for choosing the image scale is incorrect per my previous 
> email.  You special case only TRANSLATESCALE which ignores cases where 
> the transform was "scaled down to identity" on a retina display (i.e. 
> those cases should not default to devScale), and ignores any transform 
> with any non-scale components (i.e. g.scale(100,100); g.rotate(.001); 
> will use the default resolution even though they scaled it up a lot).
      The new logic uses the transform to get the destination image 
width and height.
      There is the trick question about the general transform type 
because image sides are not equal after the transformation in this case. 
So we could use only one side,
      or maximum value from opposite sides or may be an average value.

> The parameter passed to the getResVariant method is based on the 
> subimage size, but the method treats it as if it were based on the 
> full image size.  Either compute the scaled size of the full image, or 
> inform the method of the sub-image being scaled, or simply pass in the 
> scales, otherwise you will get the default image for any sub-image 
> renderings of less than half of the original image even if they are 
> rendered at retina scales.
    This is my fault. I really missed this part.  It is updated in the fix.

> The code in LWCToolkit.getImage() is not thread safe.  You do lock 
> around the cache in the putImage() method, but you could end up 
> replacing the image twice with 2 different scalable versions of the 
> image since the code in LWCToolkit decided whether to make the image 
> outside of any synchronization.
     Fixed.
>
> The File/URL code in LWCToolkit is not protected by security 
> permission checks like the code in SunToolkit.
    Fixed.
> The fixes to LWCToolkit require a network connection for every image 
> created to see if the @2x version exists.  Originally I thought that 
> would be an immense performance hit, but I see that a 
> url.openConnection() is done in SunToolkit to verify permissions. This 
> would, however, double the amount of network traffic for every image. 
> Also, I'm not sure if url.openConnection() is less overhead than the 
> openStream() method used in SunToolkit...?

     The algorithm that gets the scaled image size is based on the width 
and height of both images original and scaled. That means that both 
images should be already preloaded.
     In other case we need to draw the original image (because it is not 
possible to know the destination image size)  and wait for more 
drawImage(Image ) calls to try to load the scaled image.

     It seems that multi-resolution image preloading fixes image drawing 
issue as well as issue with the image observers. An image observer is 
not called from the g.drawImage()
     method in case if both images images are preloded and the original 
image does not have errors.

     The fix does not use url.openConnection() now. It tries to preload 
the @2x image and if it is successful it preloads the original image as 
well.

    I also look at the custom cursor part of the HiDPI issues. A user 
needs to prepare the MultiResolutionImage and we can use 
CImage.createFromImages(List<Image> images)
    method to create necessary NSImage. This means that it should be 
possible to obtain all resolution variants from the MultiResolutionImage.
    I have included the "List<Image> getResolutionVariants()" method to 
the MultiResolutionImage for that.

   Thanks,
   Alexandr.

>
>             ...jim
>
> On 11/13/13 8:11 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.07/
>>
>>    -  The default sun hint is added.
>>       However, it looks the same as the resolution variant ON hint right
>> now. It would better to leave the behavior on the non HiDPI displays the
>> same as it was before.
>>       So the resolution variant hint is disabled by default for non
>> HiDPI displays.
>>    - Resolution variant hints description is updated.
>>    - The logic operator in the  isHiDPIImage() method is formatted.
>>
>>     The @2x images are not preloaded in the LWCToolkit. It really can
>> cause image reloading after moving a window from a display from one
>> resolution to another.
>>     However, it is not clear during the MultiResolutionImage creation
>> will the images be used on HiDPI displays or not.
>>     May be there should be a flag that enables the high resolution
>> images preloading.
>>
>>    The original image can be replaced by the high resolution one in the
>> paint() method. It causes that the observer could get an image which is
>> different from the original one.
>>    May be there is no any issue?  If a MultiResolutionImage is not used
>> then all works as before. If a user implements MultiResolutionImage may
>> be he needs to have an information
>>    about the actual drawn image in the observer even it is different
>> from the original.
>>
>>    Thanks,
>>    Alexandr.
>>
>>
>> On 11/12/2013 11:43 PM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> Some minor issues with this fix:
>>>
>>> - All RenderingHints have a default setting where the system can
>>> choose for you.  The primary thing that the default settings allow is
>>> for the answer to be based off of another hint.  Often the QUALITY
>>> hint provides the swing vote if an individual hint is left "DEFAULT".
>>> That should probably also be the setting used for SG2D, and would
>>> hinge off of the devScale, for example, as the deciding factor.
>>>
>>> - Descriptions for "on" and "off" should be something like "Use
>>> resolution variants of images" and "Use only default resolution
>>> variants of images" (and "Default resolution variant usage"). Most of
>>> the other descriptions on hints are statements of what is going to
>>> happen or what is going to be used rather than a simple 'the X state
>>> is Y'.
>>>
>>> - It looks like the transform is used in SG2D to decide if the hiDPI
>>> image should be used.  I'm not familiar with the Mac's native use of
>>> @2x, but I thought that they hinged the decision off of the "retina
>>> scale" of the display, not off of the current transform.  That way, if
>>> you scale down an icon it doesn't change its look when it reaches .5x
>>> scale (or .75x depending on the cutoff).  Personally, I think it is
>>> better to not use the transform to keep animations smooth, but I'm not
>>> sure what Apple did.
>>>
>>> - The logic in using the transform is also a bit murky.  I think if
>>> you set the scale on a retina display to exactly 1/2 it would use the
>>> HiDPI version even though the scale was 1:1.  Since I support not
>>> examining the transform there, I'm going to present this as another
>>> reason why we should just base it on devScale, but the logic could be
>>> fixed if we really plan to use the transform here.
>>>
>>> - The new logic in "isHiDPIImage()" is confusing because you line up
>>> logic operations from 2 different levels of parentheses.  I believe
>>> that one version of our style guidelines included a rule that allowed
>>> "indenting to parentheses level" and I would think that would be a
>>> good rule to apply here.  Or do something else to make the logic flow
>>> there less tricky to read.
>>>
>>> - Eventually we are going to need this support in more pipelines. I
>>> believe that Win8 already has parameters that affect choices of
>>> images, but they are only currently deployed on the Surface tablets
>>> (i.e. there are no supported high DPI displays for desktop that I'm
>>> aware of, but some of the Surface tablets ship with high DPI
>>> screens).  What would the impact be if we moved this into a more
>>> general class in src/share?  I suppose we might spend extra time
>>> looking for variants of images that we don't need?
>>>
>>> - Has any thought been given to the issues that someone raised with
>>> cursors?
>>>
>>> - Has any thought been given to my comments about MediaTracker and
>>> image observer states for multi-res images?  I don't see any attempt
>>> here to preload the @2x image.  The problem would probably only be
>>> seen on multi-headed systems where one display is retina and one is
>>> not - you would find the images suddenly reloading when you move the
>>> window to the other screen and the application might not expect that
>>> to happen.  Which image is the Observer registered on?  Since the
>>> image is handed to the Observer, will an application be surprised when
>>> their observer gets a handle to an image they've never seen? Is it an
>>> issue if one of the "alternate resolution variant" images leaks into
>>> an application's "hands" via the observer callbacks?
>>>
>>>             ...jim
>>>
>>> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>>>
>>>>    Only internal API is exposed:
>>>>    - MultiResolutionImage interface with method
>>>> "getResolutionVariant(int width, int height)" is added to the
>>>> com.sun.awt package
>>>>    - Hints to switch on/off the resolution variant usage are added to
>>>> SunHints class
>>>>    - Test is updated to use the  MultiResolutionImage interface
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>    Thank you for the review.
>>>>>
>>>>>   Could you look at the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>>>
>>>>>   - URL is parsed to protocol, host, port, and path parts in the
>>>>> LWCToolkit class.
>>>>>      I checked that URL(protocol, host, port, file) constructor
>>>>> correctly handles -1 port value.
>>>>>   - Only last file name after last '/' in the URL path  is converted
>>>>> to @2x name
>>>>>   - Tests that check correct URL and path translation to @2x names 
>>>>> are
>>>>> added to the ScalableImageTest
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>>>
>>>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>>>> like this:
>>>>>>>>
>>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>>
>>>>>>>> In this case it will try to find 2x image here:
>>>>>>>>
>>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>>
>>>>>>>> which doesn't look correct.
>>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>
>>>>>> Hi Alexander,
>>>>>>
>>>>>> URLs like this:
>>>>>>
>>>>>> http://www.example.com/dir.ext/image
>>>>>>
>>>>>> will still be translated to:
>>>>>>
>>>>>> http://www.example.com/dir at 2x.ext/image
>>>>>>
>>>>>>
>>>>>> I think you need to search for last '.' after the last '/' in the
>>>>>> getScaledImageName();
>>>>>>
>>>>>>
>>>>>> Also the following code has some additional bugs:
>>>>>>
>>>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>>>   854
>>>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>>>   856                     && !(image instanceof
>>>>>> ScalableToolkitImage)) {
>>>>>>   857                 String protocol = url.getProtocol();
>>>>>>   858                 String host = url.getHost();
>>>>>>   859                 String file = url.getPath();
>>>>>>   860                 String file2x =*host 
>>>>>> +*getScaledImageName(file);
>>>>>>   861                 try {
>>>>>>   862                     URL url2x = new URL(protocol, host, 
>>>>>> file2x);
>>>>>>   863                     url2x.openStream();
>>>>>>   864                     return new ScalableToolkitImage(image,
>>>>>> getDefaultToolkit().getImage(url2x));
>>>>>>   865                 } catch (Exception ignore) {
>>>>>>   866                 }
>>>>>>   867             }
>>>>>>   868             return image;
>>>>>>   869         }
>>>>>>
>>>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>>>> 860? Let's take the following URL for example:
>>>>>>
>>>>>> http://www.example.com/dir/image.jpg
>>>>>>
>>>>>> protocol = "http"
>>>>>> host = "www.example.com"
>>>>>> file = "/dir/image.jpg"
>>>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>>>> url2x =
>>>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>>>
>>>>>>
>>>>>> You are missing a part in URL (de)construction - the optional port!
>>>>>> For example in the following URL:
>>>>>>
>>>>>> http://www.example.com:8080/dir/image.jpg
>>>>>>
>>>>>> You should extract the port from original URL and use it in new URL
>>>>>> construction if present (!= -1).
>>>>>>
>>>>>>
>>>>>> I would also close the stream explicitly after probing for existence
>>>>>> of resource rather than delegating to GC which might not be promptly
>>>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>>>> descriptors):
>>>>>>
>>>>>>         try (InputStream probe = url.openStream()) {}
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>>
>>>>>
>>>>
>>


From java3 at segal.org  Tue Nov 19 11:49:24 2013
From: java3 at segal.org (Mickey Segal)
Date: Tue, 19 Nov 2013 14:49:24 -0500
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
Message-ID: <000901cee560$73af4310$5b0dc930$@segal.org>

Is this problem related to the problem described in the bug report about the refresh problem shown at http://www.segal.org/java/refresh4/ ?  

Apple seems to have concluded this is Oracle's problem and Oracle seems to have concluded this is Apple's problem.

Petr Pchelko wrote:

It's known that there are some deadlocks in SWT_AWT bridge on Mac. Here's an example:
https://bugs.openjdk.java.net/browse/JDK-8020165

It would be useful if you also post the dump of an Appkit thread to identify your particular case.

The deadlock occurs because AWT is called on the main thread. So the main thread get blocked on some internal AWT lock, while the EventDispatchThread is trying to perform a synchronous operation on the main thread. It's not quite obvious how to fix that internally, because for the normal AWT application we have a strict rule not to acquire locks on the Appkit thread. 

For now the workaround could be to wrap all the usages of AWT inside invokeLater (except the initial
SWT_AWT.new_Frame(composite) call). This should fix your deadlock. 

Also, which version of SWT are you using? The newer versions are patched so that you could not set the embeddedFrameClass explicitly. That patch also contains additional changes in bridge initialization, so the bridge does not work quite well with older versions. This could be another reason of your deadlock. 


From paul_t100 at fastmail.fm  Wed Nov 20 02:05:47 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Wed, 20 Nov 2013 10:05:47 +0000
Subject: CheckboxMenuItem added to dock fires itemevent returning String rather
	than CheckboxMenuItem
Message-ID: <528C897B.2040000@fastmail.fm>

On OSX Java 7 (1.7.0_40) I wanted to add some mutually exclusive 
CheckBoxItems to the dock menu, in order to create the mutual 
exclusivity I  used the answer here by 
http://stackoverflow.com/questions/13596428/adding-a-checkbox-group-to-a-java-menu/20092694#20092694 
provided by Julian Wright to create the equivalent of ButtonGroup 
available for JCheckBoxMenuItems


But I ran into a problem, the object returned by ItemEvent is of type 
String rather than CheckBoxMenuItem, I worked round it with the code 
below but this is an OSX bug isnt it ?

|import  java.awt.*;
import  java.awt.event.ItemEvent;
import  java.awt.event.ItemListener;
import  java.util.HashSet;
import  java.util.Set;

public  class  CheckboxMenuItemGroup  implements  ItemListener
{

     private  Set<CheckboxMenuItem>  items=  new  HashSet<CheckboxMenuItem>();

     public  void  add(CheckboxMenuItem  cbmi)  {
         cbmi.addItemListener(this);
         cbmi.setState(false);
         items.add(cbmi);
     }

     @Override
     public  void  itemStateChanged(ItemEvent  e)  {
         if  (e.getStateChange()  ==  ItemEvent.SELECTED)  {

             String  itemAffected=  (String)e.getItem();
             for  (CheckboxMenuItem  item:  items)  {
                 if  (item.getLabel()  !=  itemAffected)  item.setState(false);
             }
         }
     }

     public  void  selectItem(CheckboxMenuItem  itemToSelect)  {
         for  (CheckboxMenuItem  item:  items)  {
             item.setState(item==  itemToSelect);
         }
     }|


From alexandr.scherbatiy at oracle.com  Thu Nov 21 05:41:59 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 21 Nov 2013 17:41:59 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <528C9A67.3000109@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> <528C25FD.3020707@oracle.com>
	<528C334F.4000608@oracle.com> <528C9A67.3000109@oracle.com>
Message-ID: <528E0DA7.5090301@oracle.com>

On 11/20/2013 3:17 PM, Jim Graham wrote:
> In looking through the ToolkitImage code some more it occurs to me 
> that it was already designed (moreso in a previous life) to hold onto 
> multiple representations of the image anyway.  In a prior life in 1.0 
> and 1.1 it held separate ImageRepresentation objects for each size it 
> was scaled to (via drawImage(w,h)), but that was simplified to a 
> single ImageRep when we converted to Java2D and started doing scaling 
> on the fly for all drawImage() operations. Still, the concept of an 
> alternate resolution version of the image is probably more in line 
> with the ImageRepresentation object within the ToolkitImage than in 
> having multiple ToolkitImage objects and a wrapper for them.
>
> This would also deal more naturally with the ImageObserver issue since 
> there really would be only one Image and SG2D would not deal with the 
> sub-representations, it would be dealt with in the DrawImage pipeline 
> code when it queries the ToolkitImage for the ImageRepresentation object.
>
> In the end, I think that design would be simpler overall, would it be 
> possible to shift those gears for this fix?  If not, we should 
> consider it for a near-term future cleanup task perhaps...

     I think that it would be better to postpone this cleanup to a 
near-term future task.

    Thanks,
    Alexandr.


>
>             ...jim
>
> On 11/19/2013 7:58 PM, Jim Graham wrote:
>> Based on the information below, I have the following suggestions...
>>
>> We should probably allow asynchronous loading of the scaled 
>> resolution variants.  This is a minor variation of what the 
>> ImageObserver was originally designed for, but technically might 
>> violate some developer's expectations if they have only dealt with a 
>> post-Java2D version of Java.  Some education might be helpful here.
>>
>> The wording on drawImage(dxy12, sxy12) should probably be reworded to 
>> indicate that asynchronous scaling would not happen, but alternate 
>> versions of the image may be accessed.
>>
>> In all cases, if the version of the image that we would ideally want 
>> to show hasn't been loaded, but the standard version has (or if @2x 
>> was loaded, but we want the regular version too?) then we should 
>> probably go with the version that was loaded, but still trigger the 
>> loading of the alternate version and notify their Observer as it is 
>> loaded.
>>
>> I also examined the places in the code where we notify the 
>> ImageObserver.  A search for the observer method should show all 
>> places we call it, but the primary ones look like they are fairly few 
>> places.  If we tag the resolution variant images with the composite 
>> image from which they came, then we can have those few places do 
>> something like:
>>
>> Image obsimg = (img instanceof SunToolkitImage) ? (() 
>> img).getObservedImage() : img;
>>
>> I think in most cases the img is already known to be our internal 
>> SunToolkit image and so we don't even need to check instanceof...
>>
>>              ...jim
>>
>> On 11/19/2013 7:01 PM, Jim Graham wrote:
>>> I did some more reading about the various ways in which the 
>>> ImageObserver is used and noticed the following points, some of 
>>> which may be to our advantage.
>>>
>>> Many of the drawImage() calls mention that they will notify the 
>>> observer as the image is "scaled or converted for the output 
>>> device".  I believe in the world before 2D, we would often have to 
>>> load or convert the image asynchronously for various changes in the 
>>> output.  When we created the 2D interface and added some on-the-fly 
>>> image scaling code, we mentioned that scaling was no longer 
>>> asynchronous, but technically the API is still designed for 
>>> asynchronous operations when the rendering parameters change.
>>>
>>> However, the drawImage() call that takes 8 parameters dxy12, sxy12 - 
>>> specifically includes the words:
>>>
>>>       * This method always uses the unscaled version of the image
>>>       * to render the scaled rectangle and performs the required
>>>       * scaling on the fly. It does not use a cached, scaled version
>>>       * of the image for this operation. Scaling of the image from 
>>> source
>>>       * to destination is performed such that the first coordinate
>>>       * of the source rectangle is mapped to the first coordinate of
>>>       * the destination rectangle, and the second source coordinate is
>>>       * mapped to the second destination coordinate. The subimage is
>>>       * scaled and flipped as needed to preserve those mappings.
>>>      public abstract boolean drawImage(Image img,
>>>                                        int dx1, int dy1, int dx2, 
>>> int dy2,
>>>                                        int sx1, int sy1, int sx2, 
>>> int sy2,
>>>                                        ImageObserver observer);
>>>
>>> which basically, at the time it was created in 1.1, was an opt "out" 
>>> of the asynchronous operations that might happen when you scaled an 
>>> image with drawImage(xywh).  As worded, this would suggest that this 
>>> method does not use the @2x version and always uses the default 
>>> resolution version, but those words were not put there for this 
>>> particular intent, they were put there to indicate that we weren't 
>>> going to do an off-line scaling of the pixels which sometimes 
>>> happened in 1.0.x and possibly 1.1 (for the other calls that 
>>> predated 1.1 until Java2D).
>>>
>>> I also found the Component.prepareImage() and Component.checkImage() 
>>> methods which also take an ImageObserver.  Those methods imply that 
>>> they will possibly start the process and return information on a 
>>> particular version of an image appropriate for the current output 
>>> device.  There is even a prepareImage(w,h) method that gets an image 
>>> ready to render at the indicated size.  Given that these methods are 
>>> on component, it probably makes sense to have that code look up 
>>> which representation would be used for those indicated dimensions on 
>>> the indicated output device that the Component is displayed on.
>>>
>>>              ...jim
>>>


From alexandr.scherbatiy at oracle.com  Thu Nov 21 06:15:45 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 21 Nov 2013 18:15:45 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <528BFA66.7040307@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>
Message-ID: <528E1591.90309@oracle.com>


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

On 11/20/2013 3:55 AM, Jim Graham wrote:
> Hi Alexander:
>
> SunHints:
>> ON - Always use resolution-specific variants of images
>> OFF - Use only the standard resolution of an image
>> DEFAULT - Choose image resolutions based on a default heuristic
>>
>> (perhaps add "(when available)" to ON?)
>
> Note that I think you are still using the descriptions I asked for in 
> the first quotation which I then revised because they were confusing.  
> Please use the latter descriptions (ON, OFF, DEFAULT above).
     Updated.

>
> SG2D:
>
> - If you rewrite getTransformedDestImageSize() to return the 
> resolution variant instead of a Dimension then you avoid having to 
> create a Dimension object that gets immediately tested for null again 
> and/or consumed by the caller.  Just move the call to 
> getResolutionVariant() inside the helper method and rename it.
     Updated.
>
> - In getTransformedDestImageSize - dx,dy,sx,sy - should be named 
> dw,dh,sw,sh?
     Updated.
>
> - Also in getTransformedDestImageSize - the array of Point objects is 
> problematic because they are used for the return values and that means 
> early truncation/rounding, the methods that take arrays of doubles are 
> generally less problematic in terms of garbage generation.  Also, you 
> can use deltaTransform() because you don't need to worry about 
> translation components since you only want the distance.  Finally, why 
> not use the optimization I gave to just grab the matrix elements 
> directly and do the calculations on them instead of 3 separate point 
> transforms which have predictable outcomes?  Here is the 
> recommendation again:
>
>> And even for the case of GENERAL transform, the above can be 
>> simplified.  The tx.deltaTransform method in that case simply loads 
>> the array with:
>>
>> { m00, m10, m01, m11 }
>>
>> and so the hypot methods are simply:
>>
>> xScale = Math.hypot(tx.getScaleX(), tx.getShearY());
>> yScale = Math.hypot(tx.getShearX(), tx.getScaleY());
>
> Multiply those values with dw,dh and you have your answer. Another way 
> to look at this is that your 3 transformed points were basically:
>
>     { dx1 * m00 + dy1 * m01 + tx,  dx1 * m10 + dy1 * m11 + ty }
>     { dx2 * m00 + dy1 * m01 + tx,  dx2 * m10 + dy1 * m11 + ty }
>     { dx1 * m00 + dy2 * m01 + tx,  dx1 * m10 + dy2 * m11 + ty }
>
> Subtracting [1] - [0] for the distance calculation eliminates a lot of 
> terms and gives you:
>
>     Math.hypot((dx2 - dx1) * m00, (dx2 - dx1) * m10)
> ==  (dx2 - dx1) * Math.hypot(m00, m10);
> ==  (dx2 - dx1) * Math.hypot(tx.getScaleX(), tx.getShearY());
>
> Subtracting [2] - [0] also reduces:
>
>     Math.hypot((dy2 - dy1) * m01, (dy2 - dy1) * m11);
> ==  (dy2 - dy1) * Math.hypot(m01, m11);
> ==  (dy2 - dy1) * Math.hypot(tx.getShearX(), tx.getScaleY());
>
> - Also in getTransformeDestImageSize - the usage of the 
> transform.getType() is off, some of the values are bitmasks so a <= 
> comparison isn't the right comparison to use.  I'd use the following 
> structure:
     Updated.

>
> To check if it is "identity-ish", I'd use:
>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP)) == 0)
> To check for scale, use:
>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP | TYPE_SCALE_MASK)) == 0)
> and then the distance/hypot equations are in the final else as they 
> are now.
     Updated.
>
> - In calculating scaledWidth/width and the cast to float - even though 
> I think the precedence order is on your side, I usually add extra 
> parentheses to highlight the order so that people reading the code 
> and/or modifying it don't mess it up.  My cutoff on what is obvious to 
> a casual reader is usually "additive vs. multiplicative" and anything 
> more subtle than that I use parentheses just in case someone comes 
> along who is less familiar with the order and decides to interpose 
> some additional operations that get in the way of the proper 
> calculation.  I would have written "((float) sW) / w" 
      Updated.
> just to make it obvious.
>
> In LWCToolkit.java:
>
> - there is a lot of string manipulation going on for every image 
> fetch.  I guess this would only hurt those who use the Toolkit as 
> their image storage (getting the image every time they need it), so 
> I'm not going to worry about it, but it would be good to eventually 
> get this integrated into the caching mechanism better so that a quick 
> lookup of a previously loaded image could return faster.
>
> One thing I did not examine very closely was the transfer of hash 
> lookup and security code to the new utility class.  You should get a 
> double-check from another engineer on that code.
>
> Some more inline comments:
>
> On 11/19/2013 5:06 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>       http://cr.openjdk.java.net/~alexsch/8011059/webrev.08/
>>       - Some related to the ToolkitImage staff is moved from 
>> SunToolkit to ToolkitImageUtil
>
> I'm not sure why this was done - it added a bunch of busy-work for 
> approving the webrev that I don't have time for.  Hopefully someone 
> else can verify the cut/paste and refactoring.
     I have reverted it back.
>
>>       - Preloading for the resolution variants is added
>
> I'm not familiar with the ImageIcon, but it looks like the use of it 
> for the resolution variant causes the resolution variant images to be 
> aggressively kicked off immediately rather than as the image is used.  
> For an application that loads 1000 images and then only renders 10 of 
> them, it will get 1000 4xsized images (@2x have 4x pixels) loaded for 
> 990 images that would never have been loaded previously.  Am I 
> misreading how the ImageIcon is used there?
>
>>       The fix sets the resolution variant hint to default on Mac OS X 
>> and to off for other platforms now.
>
> I'm still not sure why it isn't just left as DEFAULT on all 
> platforms.  The other platforms don't even create resolution images 
> anyway so their default is to just use the existing image which is 
> fine.  We should not have platform issues affecting the default values 
> for hints.

     A user can create custom MultiResolution image.  If our target is 
to show the resolution variant according to the current transform on all 
platforms then it is ok.
>
>>       The new logic uses the transform to get the destination image 
>> width and height.
>>       There is the trick question about the general transform type 
>> because image sides are not equal after the transformation in this 
>> case. So we could use only one side,
>>       or maximum value from opposite sides or may be an average value.
>
> It looks like you are supplying the independent w,h and the default 
> implementation of getResolutionVariant() is using "dispw <= imgw && 
> disph <= imgh" which I think I asked Mike about and he said that was 
> correct.  Is there another issue I'm missing?
>
>>> The parameter passed to the getResVariant method is based on the 
>>> subimage size, but the method treats it as if it were based on the 
>>> full image size. Either compute the scaled size of the full image, 
>>> or inform the method of the sub-image being scaled, or simply pass 
>>> in the scales, otherwise you will get the default image for any 
>>> sub-image renderings of less than half of the original image even if 
>>> they are rendered at retina scales.
>>     This is my fault. I really missed this part.  It is updated in 
>> the fix.
>
> I think this is done in a fairly reasonable first approximation. It 
> works for the only case we have currently which is @2x images where 
> the incoming integers translate into outgoing integers, but we'll have 
> to revisit these exact calculations if we ever want to support 
> non-integer-scale resolution variants (I think Win8 might have a 
> number of non-integer scales).
>
>>      The algorithm that gets the scaled image size is based on the 
>> width and height of both images original and scaled. That means that 
>> both images should be already preloaded.
>>      In other case we need to draw the original image (because it is 
>> not possible to know the destination image size)  and wait for more 
>> drawImage(Image ) calls to try to load the scaled image.
>
> I don't like preloading them because we never preloaded the images 
> previously and this will be a huge memory concern, not to mention the 
> fact that we used to return nearly immediately from getImage() and now 
> we have to load an entire (4x pixels) image to just return from that 
> method.  This all needs to be done asynchronously.
      I reverted it back.
>
> Also, the code in getImageWithResolutionVariants() appears to wrap the 
> image afresh every time it is called.  If you call it twice with a 
> given string then the first time will make a regular image and store 
> it there, then make a scaled image and replace it with the scaled 
> image.  The second call will retrieve the scaled image left by the 
> first call and then combine it with a second instance of the scaled 
> image to make a new doubly-nested scaled image and store that in the 
> hash.
    fixed.
>
>>      It seems that multi-resolution image preloading fixes image 
>> drawing issue as well as issue with the image observers. An image 
>> observer is not called from the g.drawImage()
>>      method in case if both images images are preloded and the 
>> original image does not have errors.
>
> What about the other cases of errors?  What if they switch back and 
> forth between the resolutions?  What image is reported in the callback 
> for the non-scaled image?
       If an image is preloaded and the base image does not have errors 
than the image observer is not called. That was a point for the image 
preloading.
>
> What happens for MediaTracker?
>
>>      The fix does not use url.openConnection() now. It tries to 
>> preload the @2x image and if it is successful it preloads the 
>> original image as well.
>
> getImage() is not supposed to preload anything.  Also, I didn't see 
> where it preloads the original image, just the resolution variant.
      We do not need to preload the original image. The 
MultiResolutionImage which is based on the original image should be 
preloaded instead.

    In the last fix the images are not preloaded. I read the previous 
message there it is suggested to keep the original image in the 
ToolkitImage.
    However, a user can create it's own MultiResolutionImage 
implementation. So I added the static containsResolutionVariant() method 
and updated
    necessary observers in our code. Usually the code "image!= img" is 
changed to "MultiResolutionImage.containsResolutionVariant(image, img)"
    and x, y, width, and height values are recalculated.  The same 
should be done in a user's code.

>>     I also look at the custom cursor part of the HiDPI issues. A user 
>> needs to prepare the MultiResolutionImage and we can use 
>> CImage.createFromImages(List<Image> images)
>>     method to create necessary NSImage. This means that it should be 
>> possible to obtain all resolution variants from the 
>> MultiResolutionImage.
>>     I have included the "List<Image> getResolutionVariants()" method 
>> to the MultiResolutionImage for that.
>
> I was going to ask about that new method.  Why does the developer need 
> to manually intercede here?  They should be able to grab an image that 
> has an @2x variant, use MediaTracker or some other mechanism to make 
> sure it is loaded, then create the cursor and the code that creates 
> the cursor should notice the resolution variations and deal with it on 
> its own...
      Mac OS X gets a necessary image based on the current transform. A 
user can create its own MultiResolutionImage that contains images for 
the scales, for example, 0.5, 0.7, 1, 3.2.
      We need to know a list of all images to create the NSImage.

   Thanks,
   Alexandr.

>
>             ...jim


From alexandr.scherbatiy at oracle.com  Fri Nov 22 02:53:54 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 22 Nov 2013 14:53:54 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <528E3145.1020105@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>
Message-ID: <528F37C2.8050907@oracle.com>

On 11/21/2013 8:13 PM, Jim Graham wrote:
> Hi Alexander,
>
> I just noticed that the new interface was created in com.sun.  I also 
> note that you discuss a number of issues below that relate to a 
> developer creating one of their own Multi-Resolution images.  We 
> should not be exporting an interface at this point for a developer to 
> do any of that.  Any use of these interfaces beyond our own internal 
> use to support @2x images will be unsupported in JDK8 as we do not 
> have time to properly test and expose an interface with the remaining 
> time in the JDK8 release schedule.  This interface should be moved to 
> the internal sun.* hierarchy until we have time to vet it.

    I see that NSImage on Mac OS X has API to work with representations 
and has methods like 
addRepresentation/removeRepresentation/bestRepresentationForRect.

    Does it mean that it is possible to use not only @2x images in an 
application but create NSImage with different images resolutions as well?
    Should we support the same thing in Java? For example, a user wants 
to provide images with resolutions 0.5, 1, 2, and 3. According to the 
current transform the best resolution variant should be chosen.

   The MultiResolutionImage is in com.sun* package and it still means 
that it can be changed or removed. It can require the CCC request, though.
   Putting it to sun.com prevents using this feature in applets.

   I do not see any compatibility risks with the current fix. If a user 
does not provide @2x images or explicitly overrides the 
MultiResolutionImage nothing should be changed in his code.

   The time testing of this API is the same as testing TollkitImages 
that can hold @2x images.
   We also will have the feedback about these API earlier.  It is better 
than introducing a public API in next release that will be difficult to 
change.

>
> All of the places that call containsResolutionVariant() are pointing 
> out a bug with this implementation.  The resolution variants are 
> internal implementation details and should never be leaked through any 
> current interfaces.  It looks like most of the cases involve 
> imageUpdate() methods that should be receiving a reference to the 
> original image, not the resolution variant. These pieces of could 
> should not be changing and the fact that you had to change them points 
> out that you've created a huge compatibility issue that blocks this 
> solution.

     If someone uses the API with multi-resolution images he needs also 
update his code according to this image usage.
     It should be up to a user to preload all resolutions or only part 
of them using the MediaTracker.

     The only place where an image is replaced to a resolution variant 
and the image observer is invoked is the drawImage(Image,..,ImageObserver).

    There are 3 solutions how it can be handled:
      - Preload an image with all resolution variants. The image 
observer is not invoked in this case.
      - Using the original image in the image observer for the 
resolution variant (x,y,w,h should be rescaled).
      - Using the resolution variant in the observer

    The first one is not good solution for the ToolkitImage because it 
is designed to load asynchronously.
    The second one still  can be surprising for a user because he has 
notification that the original image has been already preloaded. Note 
that a user can do something with this image so his actions will be 
based on the image with another resolution.
    The third one provides the actual information to the user. However, 
it requires that the user update his code in the image observer.  There 
are no compatibility problems. If multi-resolution images are not used 
nothing should be changed. If they used, image observers should be 
updated accordingly.

    Thanks,
    Alexandr.

>
> On 11/21/2013 6:15 AM, Alexander Scherbatiy wrote:
>>>
>>> To check if it is "identity-ish", I'd use:
>>>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP)) == 0)
>>> To check for scale, use:
>>>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP | TYPE_SCALE_MASK)) == 0)
>>> and then the distance/hypot equations are in the final else as they 
>>> are now.
>>      Updated.
>
> The test at line 3152 is sub-optimal.  If the transform includes both 
> a SCALE and a TRANSLATE then this optimization will fail to trigger 
> and the code will fall through to the default case (which produces the 
> correct output, but misses the optimization).  Note above that I 
> include the FLIP and TRANSLATE flags in with the SCALE mask to take 
> care of this in my pseudo-code above.
>
>>>>       - Some related to the ToolkitImage staff is moved from 
>>>> SunToolkit to ToolkitImageUtil
>>>
>>> I'm not sure why this was done - it added a bunch of busy-work for 
>>> approving the webrev that I don't have time for. Hopefully someone 
>>> else can verify the cut/paste and refactoring.
>>      I have reverted it back.
>
> Thanks, it is much easier to verify what was modified now.
>
>>> I'm still not sure why it isn't just left as DEFAULT on all 
>>> platforms.  The other platforms don't even create resolution images 
>>> anyway so their default is to just use the existing image which is 
>>> fine.  We should not have platform issues affecting the default 
>>> values for hints.
>>
>>      A user can create custom MultiResolution image.  If our target 
>> is to show the resolution variant according to the current transform 
>> on all platforms then it is ok.
>
> If and when we expose the ability to create these images then the 
> developer would want them to be used on all platforms if they are 
> going to the trouble of manually creating them.  Until then the @2x 
> images are only created on MacOS anyway so the value of the hint is 
> irrelevant on other platforms.  Arguably, we might want to start 
> loading the @2x images on other platforms too, but I think we can go 
> into the 8.0 release with just MacOS support and worry about using it 
> on other platforms in an 8 update release.  In either case, the 
> default hint value should be DEFAULT.
>
>>     However, a user can create it's own MultiResolutionImage 
>> implementation. So I added the static containsResolutionVariant() 
>> method and updated
>>     necessary observers in our code. Usually the code "image!= img" 
>> is changed to "MultiResolutionImage.containsResolutionVariant(image, 
>> img)"
>
> We should not be catering to custom uses at this point until a later 
> release.
>
> If any of this code requires changes to ImageObservers then that is a 
> bug as I mentioned above.
>
>>     and x, y, width, and height values are recalculated.  The same 
>> should be done in a user's code.
>
> We should not require changes to developer's ImageObserver code to 
> support @2x.
>
>>> I was going to ask about that new method.  Why does the developer 
>>> need to manually intercede here?  They should be able to grab an 
>>> image that has an @2x variant, use MediaTracker or some other 
>>> mechanism to make sure it is loaded, then create the cursor and the 
>>> code that creates the cursor should notice the resolution variations 
>>> and deal with it on its own...
>>       Mac OS X gets a necessary image based on the current transform. 
>> A user can create its own MultiResolutionImage that contains images 
>> for the scales, for example, 0.5, 0.7, 1, 3.2.
>>       We need to know a list of all images to create the NSImage.
>
> Any code that triggers an image to load and then looks for that same 
> reference in its imageUpdate() method (which is the case in the 
> MediaTracker code) should continue to work.  That was the point I was 
> trying to make and I've reiterated this above. MediaTracker (which 
> should support @2x images without any code changes) simply makes a 
> good test case that we've handled the compatibility issues here...
>
>             ...jim


From hs at tagtraum.com  Fri Nov 22 05:51:30 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 22 Nov 2013 14:51:30 +0100
Subject: Swing on Retina displays... ahem... on Windows
Message-ID: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>

Hey guys,

I know this is off topic for this particular list, but since you all have been working on Retina support so much, I figured I bring it up here as well.

I just had a chance to try out 1.7.0_45 on Windows 7 (via Parallels 9). Java nicely takes advantage of the high resolution, however, it's not great.

When using Swing and the standard look and feel, everything is tiny, but proportions are correct (examples attached).
When using Swing and the Windows look and feel, fonts are scaled appropriately, but JTable rowHeight is still at 16 pixels and looks quite awkward.

So, the standard look and feel needs scaling, and the Windows look and feel needs some polishing. Other than that: neat!
Filed an Oracle bug 9008405?perhaps someone with access to the system wants to attach the screenshots.

Cheers,

-hendrik



Code:

import javax.swing.*;
import javax.swing.table.DefaultTableModel;
import java.awt.*;

/**
 * Demo table to demonstrate bad row height on HiDPI displays.
 */
public class TableRowHeight {

    public static void main(String[] args) throws ClassNotFoundException, UnsupportedLookAndFeelException, InstantiationException, IllegalAccessException {
        UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
        final JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        final JTable table = new JTable();
        final DefaultTableModel dataModel = new DefaultTableModel(4, 1);
        dataModel.setValueAt("Some String", 0, 0);
        dataModel.setValueAt("Some String", 1, 0);
        dataModel.setValueAt("Some String", 2, 0);
        dataModel.setValueAt("Some String", 3, 0);
        table.setModel(dataModel);
        table.setAutoCreateColumnsFromModel(true);
        frame.getContentPane().setLayout(new BorderLayout());
        frame.getContentPane().add(table, BorderLayout.CENTER);
        frame.getContentPane().add(new JLabel("Label"), BorderLayout.NORTH);
        final JMenuBar menuBar = new JMenuBar();
        menuBar.add(new JMenu("Menu"));
        frame.setJMenuBar(menuBar);
        frame.setBounds(100, 100, 300, 300);
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                frame.setVisible(true);
            }
        });
    }

}


From hs at tagtraum.com  Fri Nov 22 07:07:59 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 22 Nov 2013 16:07:59 +0100
Subject: Swing on Retina displays... ahem... on Windows
In-Reply-To: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>
References: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>
Message-ID: <772967C1-F2A4-4CF0-B463-72A6694A3417@tagtraum.com>

On Nov 22, 2013, at 14:51, Hendrik Schreiber <hs at tagtraum.com> wrote:

> [...]

I should add that this only happens with DPI scaling.
And since the images didn't make it through, here they are:

http://www.tagtraum.com/download/default_LaF.png
http://www.tagtraum.com/download/windows_LaF.png

Cheers,

-hendrik

From hs at tagtraum.com  Sat Nov 23 02:12:21 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sat, 23 Nov 2013 11:12:21 +0100
Subject: Swing on Retina displays... ahem... on Windows
In-Reply-To: <772967C1-F2A4-4CF0-B463-72A6694A3417@tagtraum.com>
References: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>
	<772967C1-F2A4-4CF0-B463-72A6694A3417@tagtraum.com>
Message-ID: <79735574-3040-4C88-9A51-8E798FBDD6A5@tagtraum.com>

On Nov 22, 2013, at 16:07, Hendrik Schreiber <hs at tagtraum.com> wrote:

> On Nov 22, 2013, at 14:51, Hendrik Schreiber <hs at tagtraum.com> wrote:
> 
>> [...]
> 
> I should add that this only happens with DPI scaling.
> And since the images didn't make it through, here they are:

On second thought, perhaps the 16 pixels Table.rowHeight is the correct approach.
And scaling up fonts to be a lot larger (as it happens in Win L&F) is what's wrong.

Because it violates write once, run anywhere.

On OS X you guys have been struggling to implement MultiResolutionImages and the like, so that if the physical display resolution is high, Java can automatically render a high resolution version of a given image. In the same spirit the L&F font sizes aren't suddenly changed, but instead they are rendered with greater detail. Because we use a virtual desktop resolution.

Now, if on Windows with Windows L&F suddenly all fonts are a lot larger, but images are still the same size (status quo) and in relation to labels way too small, things look out of proportion, layouts are broken.

The OS X solution allows for seamless migration, even if the programmer does not supply MultiResolutionImages. The current (1.7.0_45) Windows L&F does not allow this.

And regardless which approach is better: Shouldn't both L&Fs use the same approach?!

If you agree and have access to the Oracle bug database, please add this opinion as a comment (Oracle bug id 9008405). Or better?talk to the guys in charge of Windows L&F.

Thanks,

-hendrik

PS: I hate the fact that I cannot see the bug I filed anywhere and add comments to it myself. Or can I?

From hs at tagtraum.com  Mon Nov 25 00:52:10 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 25 Nov 2013 09:52:10 +0100
Subject: Focus border of JButton.buttonType=roundRect is cut off
Message-ID: <3201AE26-87A8-4D97-ABCA-D4D93688D0E5@tagtraum.com>

Hi,

the focus border of a "roundRect" JButton (as originally defined in https://developer.apple.com/library/mac/technotes/tn2007/tn2196.html ? I couldn't find a more recent documentation) is cut off left and right in the current Oracle 1.7.0_45 release. Seems like something with the sizing is off.

I uploaded a screenshot to http://www.tagtraum.com/download/focus_border.png

Is this a known issue, or should I file a bug report at http://bugreport.sun.com/bugreport/ (or is there a better place?)?

Thanks,

-hendrik

Code to reproduce on 1.7.0_45 on OS X 10.9:

import javax.swing.*;
import java.awt.*;

public class RoundedRectangleButton {

    public static void main(String[] args) {
        final JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.getContentPane().setLayout(new BorderLayout());
        final JButton button = new JButton("FocusedButton");
        button.putClientProperty("JButton.buttonType", "roundRect");
        frame.add(button, BorderLayout.NORTH);
        frame.add(new JPanel(), BorderLayout.CENTER);
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                frame.setBounds(200, 200, 200, 70);
                frame.setVisible(true);
            }
        });
    }

}


From paul_t100 at fastmail.fm  Mon Nov 25 03:07:52 2013
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 25 Nov 2013 11:07:52 +0000
Subject: Dragging an image from Webpage within Firefox no longer provides
	it as DataFlavour java.net.URL/java.util.List on OSX with Java 7
Message-ID: <52932F88.9050704@fastmail.fm>

So on Windows with Java 7  I receive an image dragged frrm a webpage in 
these flavours (plus others) but these are two I'm interested in

25/11/2013 
10.31.07:com.jthink.jaikoz.draganddrop.FileDropTarget:drop:SEVERE: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-url;representationclass=java.net.URL]
25/11/2013 
10.31.07:com.jthink.jaikoz.draganddrop.FileDropTarget:drop:SEVERE: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List]

On OSX with Java 6 I received at least one of the two above, but now 
with Java 7 (1.7.0_40) I no longer receive either

I found these bugs that seem related

https://bugs.openjdk.java.net/browse/JDK-7124379
https://bugs.openjdk.java.net/browse/JDK-8005932

Could I have a comment on this please.

Paul

From Sergey.Bylokhov at oracle.com  Mon Nov 25 03:36:29 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Nov 2013 15:36:29 +0400
Subject: Focus border of JButton.buttonType=roundRect is cut off
In-Reply-To: <3201AE26-87A8-4D97-ABCA-D4D93688D0E5@tagtraum.com>
References: <3201AE26-87A8-4D97-ABCA-D4D93688D0E5@tagtraum.com>
Message-ID: <5293363D.6010401@oracle.com>

Hi, Hendrik.
Looks like the similar issue was fixed for textured buttons:
https://bugs.openjdk.java.net/browse/JDK-8000435
It would be good if you create a new issue. Thanks!

On 25.11.2013 12:52, Hendrik Schreiber wrote:
> Hi,
>
> the focus border of a "roundRect" JButton (as originally defined in https://developer.apple.com/library/mac/technotes/tn2007/tn2196.html ? I couldn't find a more recent documentation) is cut off left and right in the current Oracle 1.7.0_45 release. Seems like something with the sizing is off.
>
> I uploaded a screenshot to http://www.tagtraum.com/download/focus_border.png
>
> Is this a known issue, or should I file a bug report at http://bugreport.sun.com/bugreport/ (or is there a better place?)?
>
> Thanks,
>
> -hendrik
>
> Code to reproduce on 1.7.0_45 on OS X 10.9:
>
> import javax.swing.*;
> import java.awt.*;
>
> public class RoundedRectangleButton {
>
>      public static void main(String[] args) {
>          final JFrame frame = new JFrame();
>          frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
>          frame.getContentPane().setLayout(new BorderLayout());
>          final JButton button = new JButton("FocusedButton");
>          button.putClientProperty("JButton.buttonType", "roundRect");
>          frame.add(button, BorderLayout.NORTH);
>          frame.add(new JPanel(), BorderLayout.CENTER);
>          SwingUtilities.invokeLater(new Runnable() {
>              public void run() {
>                  frame.setBounds(200, 200, 200, 70);
>                  frame.setVisible(true);
>              }
>          });
>      }
>
> }
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Nov 25 03:54:01 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 Nov 2013 15:54:01 +0400
Subject: Swing on Retina displays... ahem... on Windows
In-Reply-To: <79735574-3040-4C88-9A51-8E798FBDD6A5@tagtraum.com>
References: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>	<772967C1-F2A4-4CF0-B463-72A6694A3417@tagtraum.com>
	<79735574-3040-4C88-9A51-8E798FBDD6A5@tagtraum.com>
Message-ID: <52933A59.5050401@oracle.com>

Hi, Hendrik.
Your issue now in the accepted state:
https://bugs.openjdk.java.net/browse/JDK-8029087
Thanks!

On 23.11.2013 14:12, Hendrik Schreiber wrote:
> On Nov 22, 2013, at 16:07, Hendrik Schreiber <hs at tagtraum.com> wrote:
>
>> On Nov 22, 2013, at 14:51, Hendrik Schreiber <hs at tagtraum.com> wrote:
>>
>>> [...]
>> I should add that this only happens with DPI scaling.
>> And since the images didn't make it through, here they are:
> On second thought, perhaps the 16 pixels Table.rowHeight is the correct approach.
> And scaling up fonts to be a lot larger (as it happens in Win L&F) is what's wrong.
>
> Because it violates write once, run anywhere.
>
> On OS X you guys have been struggling to implement MultiResolutionImages and the like, so that if the physical display resolution is high, Java can automatically render a high resolution version of a given image. In the same spirit the L&F font sizes aren't suddenly changed, but instead they are rendered with greater detail. Because we use a virtual desktop resolution.
>
> Now, if on Windows with Windows L&F suddenly all fonts are a lot larger, but images are still the same size (status quo) and in relation to labels way too small, things look out of proportion, layouts are broken.
>
> The OS X solution allows for seamless migration, even if the programmer does not supply MultiResolutionImages. The current (1.7.0_45) Windows L&F does not allow this.
>
> And regardless which approach is better: Shouldn't both L&Fs use the same approach?!
>
> If you agree and have access to the Oracle bug database, please add this opinion as a comment (Oracle bug id 9008405). Or better?talk to the guys in charge of Windows L&F.
>
> Thanks,
>
> -hendrik
>
> PS: I hate the fact that I cannot see the bug I filed anywhere and add comments to it myself. Or can I?


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Mon Nov 25 05:51:44 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 25 Nov 2013 17:51:44 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <529000B4.6070503@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>
Message-ID: <529355F0.4040506@oracle.com>



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

  - FLIP and TRANSLATE bit masks are also included for the SCALE 
transform checking

  - LWCToolkit checks an image in cache before requesting 
multi-resolution image creation to prevent excessive string manipulation.
    It needs to make imgCache accessible from the LWCToolkit or move 
image2x staff calculation to the SunToolkit to use the right 
synchronization.
    imgCache is not created per Application context so there can be 
issues to make it protected. The image2x staff does not relate to 
SunToolkit.
    That is why all staff related to ToolkitImage creation used to move 
into ToolkitImageUtil in some previous fix. I just skipped the 
synchronization for this particular case.

  - The containsResolutionVariant method is removed from the 
MultiResolutionImage

  - The image observer is nullified in drawImage(Image,..ImageObserver) 
method for the resolution variant.
    The original image is always loaded because it needs to know the 
image width and height for the resolution variant size calculation.
     Only the original image sends notifications that an image is 
loaded. The resolution variant is drawn silently so it does not break 
existed image observer implementation.

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).

   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.
   -----------------------

   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.

   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.

   Thanks,
   Alexandr.


>
>>    I do not see any compatibility risks with the current fix. If a 
>> user does not provide @2x images or explicitly overrides the 
>> MultiResolutionImage nothing should be changed in his code.
>
> If a developer uses a stock Java module in their app and they hand it 
> some @2x-enabled images then that code could fail.
>
> If a developer creates an app and then later a graphic artist replaces 
> its media with a new set of media that includes @2x images then the 
> app could fail.
>
> If an applet is deployed that uses stock imagery from its own web site 
> and someone on the web team for that same company/organization decides 
> to start introducing @2x media for a better web experience, then that 
> code could fail.
>
> And, the changes introduced represent not "new functionality" but 
> existing behaviors that we've specified that are being violated - and 
> violated for reasons external to that code (i.e. whether or not a 
> particular file is found in the file system or on a web site).
>
> Also, even if it could be attributed to something that was also fully 
> complicit amongst all parties involved, this feature can be deployed 
> without requiring code changes and we should do that. The current 
> issues with the image being returned in imageUpdate are avoidable, 
> inconvenient, and in violation of the existing drawImage/ImageObserver 
> contract.
>
>>    The time testing of this API is the same as testing TollkitImages 
>> that can hold @2x images.
>>    We also will have the feedback about these API earlier.  It is 
>> better than introducing a public API in next release that will be 
>> difficult to change.
>
> Release cycles have vetting of new public API built in to their 
> scheduling in a responsible manner.  An 11th hour sudden introduction 
> of a new API, especially one that is necessary for some developers to 
> use a new feature, is a lot more irresponsible.
>
>>> All of the places that call containsResolutionVariant() are pointing 
>>> out a bug with this implementation.  The resolution variants are 
>>> internal implementation details and should never be leaked through 
>>> any current interfaces.  It looks like most of the cases involve 
>>> imageUpdate() methods that should be receiving a reference to the 
>>> original image, not the resolution variant. These pieces of could 
>>> should not be changing and the fact that you had to change them 
>>> points out that you've created a huge compatibility issue that 
>>> blocks this solution.
>>
>>      If someone uses the API with multi-resolution images he needs 
>> also update his code according to this image usage.
>
> First, their "use" of the new feature is not a code change, it is the 
> appearance of a new file in their deployment, or on a web site that 
> they tried to access.  There isn't as much explicit intent there as 
> you are making it out to be.
>
>>      It should be up to a user to preload all resolutions or only 
>> part of them using the MediaTracker.
>
> (And, btw, I didn't see MediaTracker on the list of places that were 
> changed to be aware of the new images.  Also, the 
> prepareImage/checkImage methods that MT uses to trigger loading 
> weren't necessarily up to the task of preloading the necessary image 
> variants.)
>
>>      The only place where an image is replaced to a resolution 
>> variant and the image observer is invoked is the 
>> drawImage(Image,..,ImageObserver).
>
> Component.prepareImage() and Component.checkImage() are also intended 
> to trigger and track the loading of the required representation of an 
> image for the indicated Component.
>
>>     There are 3 solutions how it can be handled:
>>       - Preload an image with all resolution variants. The image 
>> observer is not invoked in this case.
>>       - Using the original image in the image observer for the 
>> resolution variant (x,y,w,h should be rescaled).
>>       - Using the resolution variant in the observer
>>
>>     The first one is not good solution for the ToolkitImage because 
>> it is designed to load asynchronously.
>
> Agreed.
>
>>     The second one still  can be surprising for a user because he has 
>> notification that the original image has been already preloaded. Note 
>> that a user can do something with this image so his actions will be 
>> based on the image with another resolution.
>
> It would be far less surprising than the third option which starts to 
> mention an image that he never interacted with.
>
> It would also be similar to the behavior in 1.0 where we could 
> asynchronously reload the image in order to perform simple scaling on 
> it.  In other words, this may be outdated behavior, but it is not new 
> behavior.
>
>>     The third one provides the actual information to the user. 
>> However, it requires that the user update his code in the image 
>> observer.  There are no compatibility problems. If multi-resolution 
>> images are not used nothing should be changed. If they used, image 
>> observers should be updated accordingly.
>
> The fact that it requires the user to update his code to avoid bugs is 
> a non-starter.  It means that they have work to do to use @2x images, 
> they can't just install the new files into their deployment.  It means 
> that they will experience all sorts of "left hand didn't coordinate 
> with right hand" issues in their deployment and testing as often media 
> is managed by a different team than the code.  It also means we are 
> exposing an internal implementation detail rather than making it "just 
> work".  It also means that we are explicitly violating a long-standing 
> API contract in a way that directly impacts them.
>
> The added information is not required for them to use the image and is 
> of questionable value given that the interactions they make with the 
> image are based on the design space of the unscaled variant - 
> information relative to a scaled variant then requires a bit of work 
> for them to use.  We may want to provide this information at some 
> point, but for now we should not be introducing new behavior to a 
> really old API contract...
>
>             ...jim


From vbarot at tibco.com  Mon Nov 25 06:53:59 2013
From: vbarot at tibco.com (Viral Barot)
Date: Mon, 25 Nov 2013 14:53:59 +0000
Subject: Java 7 Application freeze at
	sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition
In-Reply-To: <D77D051E-F553-44A9-B631-50CC3DB792DF@oracle.com>
References: <A232E998-05A4-44CA-9432-C7CD6E763ABF@tibco.com>
	<D77D051E-F553-44A9-B631-50CC3DB792DF@oracle.com>
Message-ID: <9EC4635D-F027-4475-9663-9FAD4D8056DE@tibco.com>

Hi Petr,
Here is the dump of the Appkit thread and the AWT Thread. As I indicated earlier our original application does not call invokeAndWait, it uses invokeLater to make changes to the frame once the frame is created in Appkit thread. Also I see this issue with SWT 3.7.2 as well as the latest 4.3.

"AWT-EventQueue-0" prio=5 tid=0x00007fcc9b357000 nid=0xbf03 runnable [0x0000000167cac000]
   java.lang.Thread.State: RUNNABLE
	at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
	at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
	at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
	at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
	at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
	at java.awt.Component.updateCursorImmediately(Component.java:3123)
	at java.awt.Component.hide(Component.java:1696)
	- locked <0x0000000158b7a4e0> (a java.awt.Component$AWTTreeLock)
	at java.awt.Window.hide(Window.java:1116)
	at sun.awt.EmbeddedFrame.hide(EmbeddedFrame.java:192)
	at java.awt.Component.show(Component.java:1653)
	at java.awt.Component.setVisible(Component.java:1603)
	at java.awt.Window.setVisible(Window.java:1014)
	at com.tibco.cep.studio.ui.overview.OverviewUtils.refreshOverview(OverviewUtils.java:122)
	at com.tibco.cep.studio.ui.overview.OverviewUtils$1.run(OverviewUtils.java:51)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

   Locked ownable synchronizers:
	- None
 
"AppKit Thread" prio=5 tid=0x00007fcc9a803800 nid=0x707 waiting for monitor entry [0x00007fff58cb2000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.awt.Container.addImpl(Container.java:1077)
	- waiting to lock <0x0000000158b7a4e0> (a java.awt.Component$AWTTreeLock)
	at java.awt.Container.add(Container.java:966)
	at com.tomsawyer.canvas.swing.TSBaseSwingCanvas.setInnerCanvas(SourceFile:4258)
	at com.tomsawyer.interactive.swing.TSSwingCanvas.setInnerCanvas(SourceFile:798)
	at com.tomsawyer.canvas.swing.TSBaseSwingCanvas.createGUI(SourceFile:3870)
	at com.tomsawyer.canvas.swing.TSBaseSwingCanvas.<init>(SourceFile:138)
	at com.tomsawyer.interactive.swing.TSSwingCanvas.<init>(SourceFile:160)
	at com.tomsawyer.interactive.swing.TSSwingCanvas.<init>(SourceFile:138)
	at com.tibco.cep.diagramming.drawing.DrawingCanvas.<init>(DrawingCanvas.java:37)
	at com.tibco.cep.diagramming.drawing.DiagramManager.initialize(DiagramManager.java:233)
	at com.tibco.cep.diagramming.drawing.DiagramManager.<init>(DiagramManager.java:196)
	at com.tibco.cep.studio.ui.diagrams.EntityDiagramManager.<init>(EntityDiagramManager.java:135)
	at com.tibco.cep.studio.ui.diagrams.EventDiagramManager.<init>(EventDiagramManager.java:87)
	at com.tibco.cep.studio.ui.editors.events.EventDiagramEditor.getDiagramManager(EventDiagramEditor.java:24)
	at com.tibco.cep.studio.ui.editors.EntityDiagramEditor.addFormPage(EntityDiagramEditor.java:85)
	at com.tibco.cep.studio.ui.editors.EntityDiagramEditor.createUIEditorPage(EntityDiagramEditor.java:77)
	at com.tibco.cep.studio.ui.editors.EntityDiagramEditor.createPages(EntityDiagramEditor.java:54)
	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:670)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:313)
	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)
	at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)
	at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
	at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1245)
	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1198)
	at org.eclipse.ui.internal.PartStack.presentationSelectionChanged(PartStack.java:834)
	at org.eclipse.ui.internal.PartStack.access$1(PartStack.java:823)
	at org.eclipse.ui.internal.PartStack$1.selectPart(PartStack.java:137)
	at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation$1.handleEvent(TabbedStackPresentation.java:133)
	at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:269)
	at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:278)
	at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.access$1(DefaultTabFolder.java:1)
	at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder$2.handleEvent(DefaultTabFolder.java:88)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4128)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1457)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1480)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1465)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1270)
	at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.java:2746)
	at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:1433)
	at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:257)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4128)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1457)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1480)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1465)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1270)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3974)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3613)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

   Locked ownable synchronizers:
	- None



On Nov 18, 2013, at 10:55 PM, Petr Pchelko <petr.pchelko at oracle.com> wrote:

> Hello, Viral.
> 
> It's known that there are some deadlocks in SWT_AWT bridge on Mac. Here's an example:
> https://bugs.openjdk.java.net/browse/JDK-8020165
> 
> It would be useful if you also post the dump of an Appkit thread to identify your particular case.
> 
> The deadlock occurs because AWT is called on the main thread. So the main thread get blocked
> on some internal AWT lock, while the EventDispatchThread is trying to perform a synchronous operation
> on the main thread. It's not quite obvious how to fix that internally, because for the normal AWT application
> we have a strict rule not to acquire locks on the Appkit thread. 
> 
> For now the workaround could be to wrap all the usages of AWT inside invokeLater (except the initial  
> SWT_AWT.new_Frame(composite) call). This should fix your deadlock. 
> 
> Also, which version of SWT are you using? The newer versions are patched so that you could not set the 
> embeddedFrameClass explicitly. That patch also contains additional changes in bridge initialization,
> so the bridge does not work quite well with older versions. This could be another reason of your deadlock.
> 
> With best regards. Petr.
> 
> On 19.11.2013, at 2:51, Viral Barot <vbarot at tibco.com> wrote:
> 
>> Accessing AWT frame from a thread causes the application to freeze when executed with JRE 7. The AWT frame is created with SWT_AWT bridge.
>> 
>> Below is the test case in which call to frame.setVisible(true); from the AWT event dispatching thread does not return.
>> 
>> Test Case:
>> import java.awt.Button;
>> import java.awt.Color;
>> import java.awt.event.ActionEvent;
>> import java.awt.event.ActionListener;
>> import java.lang.reflect.InvocationTargetException;
>> 
>> import javax.swing.JOptionPane;
>> import javax.swing.SwingUtilities;
>> 
>> import org.eclipse.swt.SWT;
>> import org.eclipse.swt.awt.SWT_AWT;
>> import org.eclipse.swt.layout.GridLayout;
>> import org.eclipse.swt.widgets.Display;
>> import org.eclipse.swt.widgets.Shell;
>> import org.eclipse.swt.widgets.Composite;
>> 
>> public class Main {
>> 
>> public static void main(String[] args) {
>> 
>> 
>> 
>> if(System.getProperty("os.name").toLowerCase().startsWith("mac")){
>> SWT_AWT.embeddedFrameClass = "sun.lwawt.macosx.CViewEmbeddedFrame";
>> }
>> 
>> 
>>   Display display = new Display();
>>   Shell shell = new Shell(display);
>>   shell.setText("Shell");
>>   shell.setSize(200, 200);
>>   shell.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_BLUE));
>> 
>> 
>> 
>>   final Composite composite = new Composite(shell, SWT.EMBEDDED);
>>   GridLayout gridLayout = new GridLayout();
>>   gridLayout.numColumns = 1;
>>   composite.setLayout(gridLayout);
>>   composite.setSize(200,200);
>>   composite.setBackground(Display.getDefault().getSystemColor(SWT.COLOR_WHITE));
>> 
>> 
>> 
>>   final java.awt.Frame frame  = SWT_AWT.new_Frame(composite);
>> frame.setVisible(false);
>> frame.setBackground(Color.red);
>> frame.setSize(200, 200);
>>   Button button = new Button("Submit");
>>   button.addActionListener(new ActionListener() {
>> 
>> 
>> @Override
>> public void actionPerformed(ActionEvent e) {
>> 
>> 
>> JOptionPane.showMessageDialog(null, "Hello");
>> }
>> });
>>   frame.add(button);
>>   frame.doLayout();
>> 
>> 
>> 
>>   try {
>> SwingUtilities.invokeAndWait(new Runnable() {
>> 
>> 
>> @Override
>> public void run() {
>> frame.setVisible(true);
>> }
>> });
>> } catch (InterruptedException e1) {
>> e1.printStackTrace();
>> } catch (InvocationTargetException e1) {
>> e1.printStackTrace();
>> }
>>   shell.open();
>> 
>> 
>> 
>>   while (!shell.isDisposed()) {
>>     if (!display.readAndDispatch())
>>       display.sleep();
>>   }
>>   display.dispose();
>> 
>> 
>> 
>> }
>> }
>> 
>> Below is the thread dump for this.
>> 
>> "AWT-EventQueue-0" prio=5 tid=0x00007f8d0b087000 nid=0x8703 runnable [0x0000000195e40000]
>>  java.lang.Thread.State: RUNNABLE
>> at sun.lwawt.macosx.CCursorManager.nativeGetCursorPosition(Native Method)
>> at sun.lwawt.macosx.CCursorManager.getCursorPosition(CCursorManager.java:54)
>> at sun.lwawt.LWCursorManager.updateCursorImpl(LWCursorManager.java:79)
>> at sun.lwawt.LWCursorManager.updateCursor(LWCursorManager.java:56)
>> at sun.lwawt.LWComponentPeer.updateCursorImmediately(LWComponentPeer.java:852)
>> at java.awt.Component.updateCursorImmediately(Component.java:3123)
>> at java.awt.Component.show(Component.java:1626)
>> - locked <0x0000000160c5b8c8> (a java.awt.Component$AWTTreeLock)
>> at java.awt.Window.show(Window.java:1042)
>> at sun.awt.EmbeddedFrame.show(EmbeddedFrame.java:179)
>> at java.awt.Component.show(Component.java:1651)
>> at java.awt.Component.setVisible(Component.java:1603)
>> at java.awt.Window.setVisible(Window.java:1014)
>> at Main$2.run(Main.java:60)
>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
>> at java.awt.EventQueue.access$200(EventQueue.java:103)
>> at java.awt.EventQueue$3.run(EventQueue.java:694)
>> at java.awt.EventQueue$3.run(EventQueue.java:692)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
>> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
>> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
>> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
>> 
>>  Locked ownable synchronizers:
>> - None
>> 
>> While in the above test case if invokeLater is called instead of invokeAndWait, the test case runs fine. But in my application the invokeLater calls also freeze at same location.
>> 
>> This behavoir happens with SWT 3.7.2 as well as 4.3.
>> 
>> 
>> 
>> 
> 


From hs at tagtraum.com  Mon Nov 25 07:40:03 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 25 Nov 2013 16:40:03 +0100
Subject: Focus border of JButton.buttonType=roundRect is cut off
In-Reply-To: <5293363D.6010401@oracle.com>
References: <3201AE26-87A8-4D97-ABCA-D4D93688D0E5@tagtraum.com>
	<5293363D.6010401@oracle.com>
Message-ID: <C9584D08-1ECF-43FA-9A3F-448BA0D75258@tagtraum.com>

On Nov 25, 2013, at 12:36, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Hendrik.
> Looks like the similar issue was fixed for textured buttons:
> https://bugs.openjdk.java.net/browse/JDK-8000435
> It would be good if you create a new issue. Thanks!

Thanks, Sergey - I submitted the bug.

-hendrik

From hs at tagtraum.com  Mon Nov 25 07:43:12 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 25 Nov 2013 16:43:12 +0100
Subject: Swing on Retina displays... ahem... on Windows
In-Reply-To: <52933A59.5050401@oracle.com>
References: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>	<772967C1-F2A4-4CF0-B463-72A6694A3417@tagtraum.com>
	<79735574-3040-4C88-9A51-8E798FBDD6A5@tagtraum.com>
	<52933A59.5050401@oracle.com>
Message-ID: <E22C85A0-2510-4F71-8ABD-99DA0B0FE2D7@tagtraum.com>

On Nov 25, 2013, at 12:54, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Hendrik.
> Your issue now in the accepted state:
> https://bugs.openjdk.java.net/browse/JDK-8029087
> Thanks!

Thanks, Sergey. Also for attaching my comments.

What exactly does the tag "8-defer-request" mean?
No work on this until.... when?

Cheers,

-hendrik

From Sergey.Bylokhov at oracle.com  Tue Nov 26 08:52:58 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 Nov 2013 20:52:58 +0400
Subject: Swing on Retina displays... ahem... on Windows
In-Reply-To: <E22C85A0-2510-4F71-8ABD-99DA0B0FE2D7@tagtraum.com>
References: <2ED64E23-B41E-49E0-9718-94DAD67C3E2B@tagtraum.com>	<772967C1-F2A4-4CF0-B463-72A6694A3417@tagtraum.com>	<79735574-3040-4C88-9A51-8E798FBDD6A5@tagtraum.com>	<52933A59.5050401@oracle.com>
	<E22C85A0-2510-4F71-8ABD-99DA0B0FE2D7@tagtraum.com>
Message-ID: <5294D1EA.1010205@oracle.com>

Hi, Hendrik.
This means that it will not be fixed in the 8 GA. Because we are in 
stage when only the tests or really critical issues are fixed.

On 25.11.2013 19:43, Hendrik Schreiber wrote:
> On Nov 25, 2013, at 12:54, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Hendrik.
>> Your issue now in the accepted state:
>> https://bugs.openjdk.java.net/browse/JDK-8029087
>> Thanks!
> Thanks, Sergey. Also for attaching my comments.
>
> What exactly does the tag "8-defer-request" mean?
> No work on this until.... when?
>
> Cheers,
>
> -hendrik


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Nov 27 03:12:25 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Nov 2013 15:12:25 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <5293CFBA.6010209@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>
Message-ID: <5295D399.8050905@oracle.com>

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.

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


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Nov 27 06:28:38 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Nov 2013 18:28:38 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <5295D399.8050905@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>
Message-ID: <52960196.4090805@oracle.com>

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
>
>


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Thu Nov 28 06:45:45 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 28 Nov 2013 18:45:45 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx]
	Make JDK demos look perfect on retina displays
In-Reply-To: <52967E74.4030205@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>
Message-ID: <52975719.4050502@oracle.com>


  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 hs at tagtraum.com  Fri Nov 29 04:36:14 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 29 Nov 2013 13:36:14 +0100
Subject: How to know, whether HiDPI is supported?
Message-ID: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>

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.contentScaleFactor");

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  Fri Nov 29 14:26:18 2013
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Fri, 29 Nov 2013 22:26:18 +0000
Subject: How to know, whether HiDPI is supported?
In-Reply-To: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>
References: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>
Message-ID: <52CAC6A8CE5503408F3482C89035832809C57BC4@OC11EXPO27.exchange.mit.edu>

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.getScaleInst
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.contentScaleFact
>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 krueger at lesspain.de  Sat Nov 30 04:04:38 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sat, 30 Nov 2013 13:04:38 +0100
Subject: How to know, whether HiDPI is supported?
In-Reply-To: <52CAC6A8CE5503408F3482C89035832809C57BC4@OC11EXPO27.exchange.mit.edu>
References: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>
	<52CAC6A8CE5503408F3482C89035832809C57BC4@OC11EXPO27.exchange.mit.edu>
Message-ID: <CAEnqZEW8ck9-PRfUebPHgddEwibEEpZPT5i2uUdvLNvoBmfwDw@mail.gmail.com>

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.getScaleInst
> 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.contentScaleFact
>>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  Sat Nov 30 11:09:56 2013
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Sat, 30 Nov 2013 19:09:56 +0000
Subject: How to know, whether HiDPI is supported?
In-Reply-To: <CAEnqZEW8ck9-PRfUebPHgddEwibEEpZPT5i2uUdvLNvoBmfwDw@mail.gmail.com>
References: <DE2BB440-EEE0-4A39-819E-E70E04EFE364@tagtraum.com>
	<52CAC6A8CE5503408F3482C89035832809C57BC4@OC11EXPO27.exchange.mit.edu>
	<CAEnqZEW8ck9-PRfUebPHgddEwibEEpZPT5i2uUdvLNvoBmfwDw@mail.gmail.com>
Message-ID: <52CAC6A8CE5503408F3482C89035832809C5F772@OC11EXPO27.exchange.mit.edu>

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
>>