Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Ajit Ghaisas 
Hi Andrej,

 Thanks for your suggestion.

  I have made the 'updateInProgress' member of these classes transient. 
  This is out of the fact that - 'updateInProgress' member is just an 
internal field of the class that need not be preserved during serialization.

   Here is the updated webrev. Request you to review.
   http://cr.openjdk.java.net/~aghaisas/6567433/webrev.03/
  
Regards,
Ajit
  
 

-Original Message-
From: Andrej Golovnin [mailto:andrej.golov...@gmail.com] 
Sent: Thursday, July 07, 2016 4:44 PM
To: Ajit Ghaisas
Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

Hi Ajit,

one more thing that I have just noticed:

 /**
  * Flag to indicate UI update is in progress
  */
 private boolean updateInProgress;

I think the field must be transient. In Swing every component is serializable. 
When updateInProgress is set to true and you serialize/deserialize the 
component, then the call of the #updateUI()-method on the deserialized instance 
would never update the UI of the deserialized component because the flag 
updateInProgress will never change from true to false.

Best regards,
Andrej Golovnin

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Avik Niyogi 
The test does not pass if mac specific check is not done for backgroundcolor.
The check is required to get the same values from BufferedImage as they are the 
same as found with Digital Color Meter.
This test case fixes that.
Please provide inputs if this fix will get a +1 or if not any positive inputs 
to modify the test case will be welcome.

With Regards,
Avik Niyogi
> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky  
> wrote:
> 
> 
> 
> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
>>> 
>>> 
>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
 On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
>> 
>> 
>> On 07.07.2016 16:35, Avik Niyogi wrote:
>>> Hi Semyon,
>>> 
>>> Thank you for the review comment.
>>> 
>>> In Mac OS X, *System Preferences > Displays > Colors > Display
>>> Profile*  section, the default value is *Color LCD*.
>>> This causes a failure in some test cases which uses robot.The colour
>>> configuration it expects to use is the *Generic RGB Profile*.
>>> That is what “Non-generic display settings” means.
>> AFAIK there are instruction that tests should be executed using color
>> profile with no color corrections on OS X. I guess there are many other
>> tests that fail with color correction.
>> If this is a root cause than the bug doesn't need to be fixed.
> 
> Well, I filed this bug and I used Generic RGB on all my
> test machines. There may be additional precautions in the tests
> about that but misconfiguration is not the root case here.
> That said, I feel vary about attempts to guess Apple colors
wary I mean
> in non-generic profiles.
>>> Yuri. Do you mean that the non-generic is not a root case?
>> No: I had Generic RGB everywhere, and it failed for me.
>> I should say that the new version of the test properly
>> fails with b120 and pass with current PIT. And colors
>> are visibly different in the two builds: so the test works OK now.
> That contradicts with the description of the fix.
> Probably the test does unnecessary care about the non-Generic profiles.
> 
> 159 if (!foundMatch && isMac()) {
> 160 //One more chance for Mac due to non-Generic display 
> setting
> 161 detectedColor = new Color(img.getRGB(x, y), true);
> 162 if (detectedColor.equals(colorCheck)) {
> 163 foundMatch = true;
> 164 break checkLoops;
> 165 }
> 166 }
> 
> Does it mean that the code above, which is necessary to serve non-Generic 
> profiles on OS X, may be removed and the test still passes?
> 
> --Semyon
>> 
>> -yan
>> 
>>> 
>>> --Semyon
> 
> -yan
> 
> 
>> 
>> --Semyon
>>> 
>>> Regarding “Negative scenarios”, these include cases where colours are
>>> different from the expected background or foreground colors
>>> is checked with the robot and BufferedImage respectively to *eliminate
>>> false positives due to coincidentally finding a match* by using robot
>>> or BufferedImage.
>>> 
>>> Please find my changes appropriating the inputs provided.
>>> I removed the variable foundMatch as I found that it is not required
>>> at all and incorporated the suggestion to use return instead of a
>>> labelled break.
>>> 
>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/
>>> 
>>> 
>>> 
 On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
 mailto:semyon.sadet...@oracle.com>>
 wrote:
 
 Hi Avik,
 
 could you clarify what is "Non-generic display settings"? Is it known
 bug on OS X?
 And also please be more specific on "negative scenarios" why they are
 necessary ?
 
 Also could you replace labeled break with "return foundMatch; "
 
 --Semyon
 
 
 On 07.07.2016 15:11, Avik Niyogi wrote:
> Hi All,
> 
> Kindly review the fix for JDK9.
> 
> *Bug:
> *https://bugs.openjdk.java.net/browse/JDK-8160438
>  
> 
> 
> 
> *Webrev:
> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/
>  
> 
> 
> 
> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java
> consistently fails on OS X 10.10
> 
> *Cause: * Due to bug in detecting color for Non-generic display
> settings for Mac hardware, test case failed
> 
> *Fix: *Positive and negative scenarios was added to check the colour
> for the Nimbus LAF fore

Re: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display

2016-07-07 Thread Phil Race 

I imagine this was all done to maximise performance.
Is there any impact on SwingMark - try D3D both on & off ..

The change here :
http://cr.openjdk.java.net/~alexsch/8160986/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollButton.java.sdiff.html

appears to handle only NORTH/SOUTH (ie up/down) and

the screenshot here bears that out .. ie left/right do not look to be 
any better.


http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png


-phil.

On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote:


Hello,

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

  The proposed fix changes icon shapes drawn by lines to ovals and 
polygons for JRadioButton, JComboBox and JScrollBar components for the 
Metal L&F.


  The screenshots [1] give a hint how UI controls look before and 
after the fix.


  [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots

 Thanks,
 Alexandr.

[9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display

2016-07-07 Thread Alexandr Scherbatiy 


Hello,

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

  The proposed fix changes icon shapes drawn by lines to ovals and 
polygons for JRadioButton, JComboBox and JScrollBar components for the 
Metal L&F.


  The screenshots [1] give a hint how UI controls look before and after 
the fix.


  [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots

 Thanks,
 Alexandr.

Re: [9] Review request for JDK-8158325: [macosx]Memory leak in com.apple.laf.ScreenMenu

2016-07-07 Thread Robin Stevens 
Hello,

I got approval for the backport to JDK8 from Rob McKenna (see
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005686.html).
The backport can just be applied after reshuffling the patch. Test succeeds
after applying the patch.

Note that for the reshuffling, you need to add the following line

jdk/src/java.desktop/macosx/classes/com/apple/laf :
jdk/src/macosx/classes/com/apple/laf

to common/bin/unshuffle_list.txt .


As I have no commit rights, I am looking for someone willing to do the
backport to JDK8.

Link to the JDK9 webrev:
http://cr.openjdk.java.net/~alexsch/robin.stevens/8158325/webrev.01


Thanks,

Robin



On Thu, Jun 30, 2016 at 7:18 PM, Alexander Scherbatiy <
alexandr.scherba...@oracle.com> wrote:

> On 30/06/16 20:58, Robin Stevens wrote:
>
> Thanks for reviewing, and pushing this fix.
>
> My application which bumped into this memory leak is however still running
> on JDK8.
> Is this a kind of fix that can still be backported ? If so, do I just need
> to send a new webrev to the mailinglist for the JDK8 repository and have it
> reviewed ?
>
>
>   Try to backport the fix using the unshuffle_patch scrpt [1].
>   If no more changes are required just send the request for approval to
> the jdk8u-...@openjdk.java.net alias using the template [2] and example
> [3].
>
> [1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html
> [2] http://openjdk.java.net/projects/jdk8u/approval-template.html
> [3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-June/005652.html
>
> Thanks,
> Alexandr.
>
>
>
>
> On Thu, Jun 30, 2016 at 6:06 PM, Alexander Scherbatiy <
> alexandr.scherba...@oracle.com> wrote:
>
>> The fix looks good to me.
>>
>> Thanks,
>> Alexandr.
>>
>>
>> On 30/06/16 11:34, Alexander Zvegintsev wrote:
>>
>> The fix looks good to me.
>>
>> On 6/30/16 9:07 AM, Alexandr Scherbatiy wrote:
>>
>> On 6/29/2016 10:08 PM, Robin Stevens wrote:
>>
>> Hello,
>>
>> attached you find an updated webrev which addresses the comments:
>>
>> - no custom remove implementation, but instead call fItems.clear() after
>> calling removeAll()
>> - Attached the container listener to the popupmenu
>> - Used the key instead of the value to remove items from the hashmap
>> - The test is now marked to run only on OS X
>>
>>   The uploaded webrev:
>> http://cr.openjdk.java.net/~alexsch/robin.stevens/8158325/webrev.01
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> Robin
>>
>> On Wed, Jun 29, 2016 at 2:01 PM, Alexander Zvegintsev <
>> alexander.zvegint...@oracle.com> wrote:
>>
>>> You should create the diff against the repository. This will allow to
>>> test your fix without applying a bunch of patches.
>>>
>>> --
>>> Thanks,
>>> Alexander.
>>>
>>> On 06/29/2016 02:49 PM, Robin Stevens wrote:
>>>
>>> Hello Alexander,
>>>
>>> just one last question. I assume I need to send a new webrev . But do I
>>> have to create one which contains the diff compared to the current tip of
>>> the repository, or do I need to create one which contains the diff compared
>>> to my previous patch ?
>>>
>>> Robin
>>>
>>> On Wed, Jun 29, 2016 at 12:03 PM, Alexander Zvegintsev <
>>> alexander.zvegint...@oracle.com> wrote:
>>>
 Hello Robin,

 Actually I missed your review, when I've posted mine.

 I think that we should proceed with your review as it was the first
 one. So please disregard my review request.

 On 6/29/16 12:40 PM, Robin Stevens wrote:

 Hello Alexandr, Semyon,

 2 reviews of this proposed path have happened.

 One from Alexandr Scherbatiy who stated that the fix looked good.
 One from Alexander Zvegintsev who had some comments, and immediately
 mailed his own review with a modified version of my proposed patch (see
 
 http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006196.html).
 His patch is based on my patch, but implements the comments he had.

 I am not sure what I need to do now.
 I can address his comments, but then I would end up with the same patch
 as he proposed in
 
 http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006196.html
 .
 Please let me know how to proceed with this.

 Thanks,

 Robin

 On Wed, Jun 29, 2016 at 11:16 AM, Alexandr Scherbatiy <
 alexandr.scherba...@oracle.com> wrote:

> On 6/29/2016 11:43 AM, Semyon Sadetsky wrote:
>
> It looks like that fix is posted twice for the same issue...
>
> Which one is the correct one?
>
>   It should be the first contributed fix. We are just waiting fro the
> response from the fix contributor:
>
> 
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006200.html
>
>   Thanks,
>   Alexandr.
>
> --Semyon
>
>

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Semyon Sadetsky 



On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:

On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:



On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:



On 07.07.2016 16:35, Avik Niyogi wrote:

Hi Semyon,

Thank you for the review comment.

In Mac OS X, *System Preferences > Displays > Colors > Display
Profile*  section, the default value is *Color LCD*.
This causes a failure in some test cases which uses robot.The colour
configuration it expects to use is the *Generic RGB Profile*.
That is what “Non-generic display settings” means.

AFAIK there are instruction that tests should be executed using color
profile with no color corrections on OS X. I guess there are many 
other

tests that fail with color correction.
If this is a root cause than the bug doesn't need to be fixed.


Well, I filed this bug and I used Generic RGB on all my
test machines. There may be additional precautions in the tests
about that but misconfiguration is not the root case here.
That said, I feel vary about attempts to guess Apple colors

wary I mean

in non-generic profiles.

Yuri. Do you mean that the non-generic is not a root case?

No: I had Generic RGB everywhere, and it failed for me.
I should say that the new version of the test properly
fails with b120 and pass with current PIT. And colors
are visibly different in the two builds: so the test works OK now.

That contradicts with the description of the fix.
Probably the test does unnecessary care about the non-Generic profiles.

 159 if (!foundMatch && isMac()) {
 160 //One more chance for Mac due to non-Generic 
display setting

 161 detectedColor = new Color(img.getRGB(x, y), true);
 162 if (detectedColor.equals(colorCheck)) {
 163 foundMatch = true;
 164 break checkLoops;
 165 }
 166 }

Does it mean that the code above, which is necessary to serve 
non-Generic profiles on OS X, may be removed and the test still passes?


--Semyon


-yan



--Semyon


-yan




--Semyon


Regarding “Negative scenarios”, these include cases where colours 
are

different from the expected background or foreground colors
is checked with the robot and BufferedImage respectively to 
*eliminate
false positives due to coincidentally finding a match* by using 
robot

or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required
at all and incorporated the suggestion to use return instead of a
labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/




On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
mailto:semyon.sadet...@oracle.com>>
wrote:

Hi Avik,

could you clarify what is "Non-generic display settings"? Is it 
known

bug on OS X?
And also please be more specific on "negative scenarios" why 
they are

necessary ?

Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug:
*https://bugs.openjdk.java.net/browse/JDK-8160438 





*Webrev:
*http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 





*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java
consistently fails on OS X 10.10

*Cause: * Due to bug in detecting color for Non-generic display
settings for Mac hardware, test case failed

*Fix: *Positive and negative scenarios was added to check the 
colour

for the Nimbus LAF foreground and background colours.

With Regards,
Avik Niyogi

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Yuri Nesterenko 

On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:



On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:



On 07.07.2016 16:35, Avik Niyogi wrote:

Hi Semyon,

Thank you for the review comment.

In Mac OS X, *System Preferences > Displays > Colors > Display
Profile*  section, the default value is *Color LCD*.
This causes a failure in some test cases which uses robot.The colour
configuration it expects to use is the *Generic RGB Profile*.
That is what “Non-generic display settings” means.

AFAIK there are instruction that tests should be executed using color
profile with no color corrections on OS X. I guess there are many other
tests that fail with color correction.
If this is a root cause than the bug doesn't need to be fixed.


Well, I filed this bug and I used Generic RGB on all my
test machines. There may be additional precautions in the tests
about that but misconfiguration is not the root case here.
That said, I feel vary about attempts to guess Apple colors

wary I mean

in non-generic profiles.

Yuri. Do you mean that the non-generic is not a root case?

No: I had Generic RGB everywhere, and it failed for me.
I should say that the new version of the test properly
fails with b120 and pass with current PIT. And colors
are visibly different in the two builds: so the test works OK now.

-yan



--Semyon


-yan




--Semyon


Regarding “Negative scenarios”, these include cases where colours are
different from the expected background or foreground colors
is checked with the robot and BufferedImage respectively to *eliminate
false positives due to coincidentally finding a match* by using robot
or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required
at all and incorporated the suggestion to use return instead of a
labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/




On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
mailto:semyon.sadet...@oracle.com>>
wrote:

Hi Avik,

could you clarify what is "Non-generic display settings"? Is it known
bug on OS X?
And also please be more specific on "negative scenarios" why they are
necessary ?

Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug:
*https://bugs.openjdk.java.net/browse/JDK-8160438



*Webrev:
*http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/



*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java
consistently fails on OS X 10.10

*Cause: * Due to bug in detecting color for Non-generic display
settings for Mac hardware, test case failed

*Fix: *Positive and negative scenarios was added to check the colour
for the Nimbus LAF foreground and background colours.

With Regards,
Avik Niyogi

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Semyon Sadetsky 



On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:



On 07.07.2016 16:35, Avik Niyogi wrote:

Hi Semyon,

Thank you for the review comment.

In Mac OS X, *System Preferences > Displays > Colors > Display
Profile*  section, the default value is *Color LCD*.
This causes a failure in some test cases which uses robot.The colour
configuration it expects to use is the *Generic RGB Profile*.
That is what “Non-generic display settings” means.

AFAIK there are instruction that tests should be executed using color
profile with no color corrections on OS X. I guess there are many other
tests that fail with color correction.
If this is a root cause than the bug doesn't need to be fixed.


Well, I filed this bug and I used Generic RGB on all my
test machines. There may be additional precautions in the tests
about that but misconfiguration is not the root case here.
That said, I feel vary about attempts to guess Apple colors

wary I mean

in non-generic profiles.

Yuri. Do you mean that the non-generic is not a root case?

--Semyon


-yan




--Semyon


Regarding “Negative scenarios”, these include cases where colours are
different from the expected background or foreground colors
is checked with the robot and BufferedImage respectively to *eliminate
false positives due to coincidentally finding a match* by using robot
or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required
at all and incorporated the suggestion to use return instead of a
labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/




On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
mailto:semyon.sadet...@oracle.com>> 
wrote:


Hi Avik,

could you clarify what is "Non-generic display settings"? Is it known
bug on OS X?
And also please be more specific on "negative scenarios" why they are
necessary ?

Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug:
*https://bugs.openjdk.java.net/browse/JDK-8160438 




*Webrev:
*http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 




*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java
consistently fails on OS X 10.10

*Cause: * Due to bug in detecting color for Non-generic display
settings for Mac hardware, test case failed

*Fix: *Positive and negative scenarios was added to check the colour
for the Nimbus LAF foreground and background colours.

With Regards,
Avik Niyogi

RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful.

2016-07-07 Thread Lindenmaier, Goetz 
Hi,

This change is 'L' because there are changes to a lot of files, but the changes
are all similar, so it's rather easy to review.
Similar to 8159690 I added @key headful to another around 600 tests.
I used different patterns to grep for the headful exceptions.

These are now all I could find with grepping and the like. I have around
80 failing tests remaining, where a row will probably also depend on
a display, but I want to look at them more closely, so I don't want
to include them here.

Please review this change:
http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/

Best regards,
  Goetz.

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Yuri Nesterenko 

On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:

On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:



On 07.07.2016 16:35, Avik Niyogi wrote:

Hi Semyon,

Thank you for the review comment.

In Mac OS X, *System Preferences > Displays > Colors > Display
Profile*  section, the default value is *Color LCD*.
This causes a failure in some test cases which uses robot.The colour
configuration it expects to use is the *Generic RGB Profile*.
That is what “Non-generic display settings” means.

AFAIK there are instruction that tests should be executed using color
profile with no color corrections on OS X. I guess there are many other
tests that fail with color correction.
If this is a root cause than the bug doesn't need to be fixed.


Well, I filed this bug and I used Generic RGB on all my
test machines. There may be additional precautions in the tests
about that but misconfiguration is not the root case here.
That said, I feel vary about attempts to guess Apple colors

wary I mean

in non-generic profiles.

-yan




--Semyon


Regarding “Negative scenarios”, these include cases where colours are
different from the expected background or foreground colors
is checked with the robot and BufferedImage respectively to *eliminate
false positives due to coincidentally finding a match* by using robot
or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required
at all and incorporated the suggestion to use return instead of a
labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/




On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
mailto:semyon.sadet...@oracle.com>> wrote:

Hi Avik,

could you clarify what is "Non-generic display settings"? Is it known
bug on OS X?
And also please be more specific on "negative scenarios" why they are
necessary ?

Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug:
*https://bugs.openjdk.java.net/browse/JDK-8160438


*Webrev:
*http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/


*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java
consistently fails on OS X 10.10

*Cause: * Due to bug in detecting color for Non-generic display
settings for Mac hardware, test case failed

*Fix: *Positive and negative scenarios was added to check the colour
for the Nimbus LAF foreground and background colours.

With Regards,
Avik Niyogi

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Yuri Nesterenko 

On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:



On 07.07.2016 16:35, Avik Niyogi wrote:

Hi Semyon,

Thank you for the review comment.

In Mac OS X, *System Preferences > Displays > Colors > Display
Profile*  section, the default value is *Color LCD*.
This causes a failure in some test cases which uses robot.The colour
configuration it expects to use is the *Generic RGB Profile*.
That is what “Non-generic display settings” means.

AFAIK there are instruction that tests should be executed using color
profile with no color corrections on OS X. I guess there are many other
tests that fail with color correction.
If this is a root cause than the bug doesn't need to be fixed.


Well, I filed this bug and I used Generic RGB on all my
test machines. There may be additional precautions in the tests
about that but misconfiguration is not the root case here.
That said, I feel vary about attempts to guess Apple colors
in non-generic profiles.

-yan




--Semyon


Regarding “Negative scenarios”, these include cases where colours are
different from the expected background or foreground colors
is checked with the robot and BufferedImage respectively to *eliminate
false positives due to coincidentally finding a match* by using robot
or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required
at all and incorporated the suggestion to use return instead of a
labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/




On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
mailto:semyon.sadet...@oracle.com>> wrote:

Hi Avik,

could you clarify what is "Non-generic display settings"? Is it known
bug on OS X?
And also please be more specific on "negative scenarios" why they are
necessary ?

Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug:
*https://bugs.openjdk.java.net/browse/JDK-8160438

*Webrev:
*http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/

*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java
consistently fails on OS X 10.10

*Cause: * Due to bug in detecting color for Non-generic display
settings for Mac hardware, test case failed

*Fix: *Positive and negative scenarios was added to check the colour
for the Nimbus LAF foreground and background colours.

With Regards,
Avik Niyogi

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Semyon Sadetsky 



On 07.07.2016 16:35, Avik Niyogi wrote:

Hi Semyon,

Thank you for the review comment.

In Mac OS X, *System Preferences > Displays > Colors > Display 
Profile*  section, the default value is *Color LCD*.
This causes a failure in some test cases which uses robot.The colour 
configuration it expects to use is the *Generic RGB Profile*.

That is what “Non-generic display settings” means.
AFAIK there are instruction that tests should be executed using color 
profile with no color corrections on OS X. I guess there are many other 
tests that fail with color correction.

If this is a root cause than the bug doesn't need to be fixed.

--Semyon


Regarding “Negative scenarios”, these include cases where colours are 
different from the expected background or foreground colors
is checked with the robot and BufferedImage respectively to *eliminate 
false positives due to coincidentally finding a match* by using robot 
or BufferedImage.


Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required 
at all and incorporated the suggestion to use return instead of a 
labelled break.


http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ 




On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky 
mailto:semyon.sadet...@oracle.com>> wrote:


Hi Avik,

could you clarify what is "Non-generic display settings"? Is it known 
bug on OS X?
And also please be more specific on "negative scenarios" why they are 
necessary ?


Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug: *https://bugs.openjdk.java.net/browse/JDK-8160438

*Webrev: *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 



*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java 
consistently fails on OS X 10.10


*Cause: * Due to bug in detecting color for Non-generic display 
settings for Mac hardware, test case failed


*Fix: *Positive and negative scenarios was added to check the colour 
for the Nimbus LAF foreground and background colours.


With Regards,
Avik Niyogi

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Avik Niyogi 
Hi Semyon,

Thank you for the review comment.

In Mac OS X, System Preferences > Displays > Colors > Display Profile  section, 
the default value is Color LCD.
This causes a failure in some test cases which uses robot.The colour 
configuration it expects to use is the Generic RGB Profile.
That is what “Non-generic display settings” means.

Regarding “Negative scenarios”, these include cases where colours are different 
from the expected background or foreground colors 
is checked with the robot and BufferedImage respectively to eliminate false 
positives due to coincidentally finding a match by using robot or BufferedImage.

Please find my changes appropriating the inputs provided.
I removed the variable foundMatch as I found that it is not required at all and 
incorporated the suggestion to use return instead of a labelled break.

http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ 



> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky  
> wrote:
> 
> Hi Avik,
> 
> could you clarify what is "Non-generic display settings"? Is it known bug on 
> OS X?
> And also please be more specific on "negative scenarios" why they are 
> necessary ?
> 
> Also could you replace labeled break with "return foundMatch; "
> 
> --Semyon 
> 
> 
> On 07.07.2016 15:11, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160438 
>> 
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 
>> 
>> 
>> Issue: test javax/swing/plaf/nimbus/8057791/bug8057791.java consistently 
>> fails on OS X 10.10
>> 
>> Cause:  Due to bug in detecting color for Non-generic display settings for 
>> Mac hardware, test case failed
>> 
>> Fix: Positive and negative scenarios was added to check the colour for the 
>> Nimbus LAF foreground and background colours.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>> 
>> 
>

Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Semyon Sadetsky 

Hi Avik,

could you clarify what is "Non-generic display settings"? Is it known 
bug on OS X?
And also please be more specific on "negative scenarios" why they are 
necessary ?


Also could you replace labeled break with "return foundMatch; "

--Semyon


On 07.07.2016 15:11, Avik Niyogi wrote:

Hi All,

Kindly review the fix for JDK9.

*Bug: *https://bugs.openjdk.java.net/browse/JDK-8160438

*Webrev: *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 



*Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java 
consistently fails on OS X 10.10


*Cause: * Due to bug in detecting color for Non-generic display 
settings for Mac hardware, test case failed


*Fix: *Positive and negative scenarios was added to check the colour 
for the Nimbus LAF foreground and background colours.


With Regards,
Avik Niyogi

8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-07 Thread Avik Niyogi 
Hi All,

Kindly review the fix for JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160438 


Webrev: http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ 


Issue: test javax/swing/plaf/nimbus/8057791/bug8057791.java consistently fails 
on OS X 10.10

Cause:  Due to bug in detecting color for Non-generic display settings for Mac 
hardware, test case failed

Fix: Positive and negative scenarios was added to check the colour for the 
Nimbus LAF foreground and background colours.

With Regards,
Avik Niyogi

Re: [9] Review request for 8160879 [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased rendering mode exception

2016-07-07 Thread Alexander Zvegintsev 

+1

--
Thanks,
Alexander.

On 07/07/2016 12:51 PM, Semyon Sadetsky wrote:

Looks good to me.

--Semyon

On 07.07.2016 12:33, Alexandr Scherbatiy wrote:


Hello,

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

  VALUE_TEXT_ANTIALIAS_OFF should be used for the null antialiased 
hint instead of VALUE_ANTIALIAS_OFF.


 Thanks,
 Alexandr.

Re: CFV: New Swing Group Member: Sergey Bylokhov

2016-07-07 Thread Alexander Zvegintsev 

Vote: yes

--
Thanks,
Alexander.

On 06/23/2016 09:21 AM, Alexandr Scherbatiy wrote:


I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to 
Membership in the Swing Group.


Sergey is active member of Swing group and contributed a lot of fixes 
which include Aqua L&F, Retina support on Mac OS X and others (see 
Sergey’s list OpenJDK changesets [1]).

Sergey also regularly reviews fixes suggested by other members.

Votes are due by July 08, 2016.

Only current Members of the Swing  Group [2] are eligible
to vote on this nomination.

For Lazy Consensus voting instructions, see [3].

Thanks,
Alexandr.

[1] 
http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author(serb)

[2] http://openjdk.java.net/census#swing
[3] http://openjdk.java.net/groups/#member-vote

Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Andrej Golovnin 
Hi Ajit,

one more thing that I have just noticed:

 /**
  * Flag to indicate UI update is in progress
  */
 private boolean updateInProgress;

I think the field must be transient. In Swing every component is
serializable. When updateInProgress is set to true and you
serialize/deserialize the component, then the call of the
#updateUI()-method on the deserialized instance would never update the
UI of the deserialized component because the flag updateInProgress
will never change from true to false.

Best regards,
Andrej Golovnin

Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Ajit Ghaisas 
Hi,

 

Thanks Rajeev and Andrej for the suggestions.

I have incorporated them in following webrev.

 

http://cr.openjdk.java.net/~aghaisas/6567433/webrev.02/

 

Regards,

Ajit

 

From: Rajeev Chamyal 
Sent: Thursday, July 07, 2016 3:30 PM
To: Alexander Scherbatiy; Ajit Ghaisas; swing-dev@openjdk.java.net
Subject: RE: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

 

Hello Ajit,

 

The fix looks fine to me.

Regarding test: JTable and JTree tests exceed 80 char limit.

 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 07 July 2016 15:17
To: Ajit Ghaisas; Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

 

The fix looks good to me.

Thanks,
Alexandr.

On 7/7/2016 12:44 PM, Ajit Ghaisas wrote:

Hi,

  

Thanks Alex for pointing out there might be more components showing similar 
behavior.

 

Two more components are identified which may cause this recursion in 
UpdateUI() method - JTree and JTable.

 

Now, total 5 components ( JComboBox, JList, JTree, JTable and JTableHeader) 
are fixed.

 

Please review the updated webrev :

HYPERLINK 
"http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.01/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/

 

Regards,

Ajit

 

From: Alexandr Scherbatiy 
Sent: Tuesday, July 05, 2016 5:55 PM
To: Ajit Ghaisas; Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

 

On 7/5/2016 2:51 PM, Ajit Ghaisas wrote:



Hi,

 

Bug :

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

 

Calling updateUI() on JList, JComboBox and JTableHeader can create 
StackOverflowErrors.
For example -

JList.updateUI() invokes updateUI() on its Cellrenderer via 
SwingUtilities.updateComponentTreeUI().
If the cellrenderer is a parent of this JList the method recurses endless 
causing StackOverflowError.

 

 

Fix :

 Added a recursion guard to JComboBox, JList and JTableHeader classes.

 With this fix, UpdateUI() method in these classes does not result in 
recursion.

 

Webrev :

HYPERLINK 
"http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/

 
   Could the same issue affect another Swing components which allow to set a 
cell renderer, like JTree?

  Thanks,
  Alexandr.



 

Request you to review.

 

Regards,

Ajit

Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Andrej Golovnin 
Hi Ajit,

src/java.desktop/share/classes/javax/swing/JList.java

In the line 545 there are unnecessary brackets:

545 if ((renderer instanceof Component)) {

It should look like this:

545 if (renderer instanceof Component) {

Best regards,
Andrej Golovnin

Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Rajeev Chamyal 
Hello Ajit,

 

The fix looks fine to me.

Regarding test: JTable and JTree tests exceed 80 char limit.

 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 07 July 2016 15:17
To: Ajit Ghaisas; Rajeev Chamyal; swing-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

 

The fix looks good to me.

Thanks,
Alexandr.

On 7/7/2016 12:44 PM, Ajit Ghaisas wrote:

Hi,

  

Thanks Alex for pointing out there might be more components showing similar 
behavior.

 

Two more components are identified which may cause this recursion in 
UpdateUI() method - JTree and JTable.

 

Now, total 5 components ( JComboBox, JList, JTree, JTable and JTableHeader) 
are fixed.

 

Please review the updated webrev :

HYPERLINK 
"http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.01/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/

 

Regards,

Ajit

 

From: Alexandr Scherbatiy 
Sent: Tuesday, July 05, 2016 5:55 PM
To: Ajit Ghaisas; Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

 

On 7/5/2016 2:51 PM, Ajit Ghaisas wrote:




Hi,

 

Bug :

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

 

Calling updateUI() on JList, JComboBox and JTableHeader can create 
StackOverflowErrors.
For example -

JList.updateUI() invokes updateUI() on its Cellrenderer via 
SwingUtilities.updateComponentTreeUI().
If the cellrenderer is a parent of this JList the method recurses endless 
causing StackOverflowError.

 

 

Fix :

 Added a recursion guard to JComboBox, JList and JTableHeader classes.

 With this fix, UpdateUI() method in these classes does not result in 
recursion.

 

Webrev :

HYPERLINK 
"http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/

 
   Could the same issue affect another Swing components which allow to set a 
cell renderer, like JTree?

  Thanks,
  Alexandr.




 

Request you to review.

 

Regards,

Ajit

Re: [9] Review request for 8160879 [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased rendering mode exception

2016-07-07 Thread Semyon Sadetsky 

Looks good to me.

--Semyon

On 07.07.2016 12:33, Alexandr Scherbatiy wrote:


Hello,

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

  VALUE_TEXT_ANTIALIAS_OFF should be used for the null antialiased 
hint instead of VALUE_ANTIALIAS_OFF.


 Thanks,
 Alexandr.

Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Alexandr Scherbatiy 

The fix looks good to me.

Thanks,
Alexandr.

On 7/7/2016 12:44 PM, Ajit Ghaisas wrote:


Hi,

Thanks Alex for pointing out there might be more components 
showing similar behavior.


Two more components are identified which may cause this recursion 
in UpdateUI() method – JTree and JTable.


Now, total 5 components ( JComboBox, JList, JTree, JTable and 
JTableHeader) are fixed.


Please review the updated webrev :

http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/ 



Regards,

Ajit

*From:*Alexandr Scherbatiy
*Sent:* Tuesday, July 05, 2016 5:55 PM
*To:* Ajit Ghaisas; Rajeev Chamyal; swing-dev@openjdk.java.net
*Subject:* Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may 
create StackOverflowError


On 7/5/2016 2:51 PM, Ajit Ghaisas wrote:

Hi,

Bug :

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

Calling updateUI() on JList, JComboBox and JTableHeader can
create StackOverflowErrors.
For example -

JList.updateUI() invokes updateUI() on its Cellrenderer via
SwingUtilities.updateComponentTreeUI().
If the cellrenderer is a parent of this JList the method
recurses endless causing StackOverflowError.

Fix :

 Added a recursion guard to JComboBox, JList and JTableHeader
classes.

 With this fix, UpdateUI() method in these classes does not
result in recursion.

Webrev :

http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/



   Could the same issue affect another Swing components which allow to 
set a cell renderer, like JTree?


  Thanks,
  Alexandr.

Request you to review.

Regards,

Ajit

Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError

2016-07-07 Thread Ajit Ghaisas 
Hi,

  

Thanks Alex for pointing out there might be more components showing similar 
behavior.

 

Two more components are identified which may cause this recursion in 
UpdateUI() method - JTree and JTable.

 

Now, total 5 components ( JComboBox, JList, JTree, JTable and JTableHeader) 
are fixed.

 

Please review the updated webrev :

http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/

 

Regards,

Ajit

 

From: Alexandr Scherbatiy 
Sent: Tuesday, July 05, 2016 5:55 PM
To: Ajit Ghaisas; Rajeev Chamyal; swing-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create 
StackOverflowError

 

On 7/5/2016 2:51 PM, Ajit Ghaisas wrote:



Hi,

 

Bug :

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

 

Calling updateUI() on JList, JComboBox and JTableHeader can create 
StackOverflowErrors.
For example -

JList.updateUI() invokes updateUI() on its Cellrenderer via 
SwingUtilities.updateComponentTreeUI().
If the cellrenderer is a parent of this JList the method recurses endless 
causing StackOverflowError.

 

 

Fix :

 Added a recursion guard to JComboBox, JList and JTableHeader classes.

 With this fix, UpdateUI() method in these classes does not result in 
recursion.

 

Webrev :

HYPERLINK 
"http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/

 
   Could the same issue affect another Swing components which allow to set a 
cell renderer, like JTree?

  Thanks,
  Alexandr.



 

Request you to review.

 

Regards,

Ajit

[9] Review request for 8160879 [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased rendering mode exception

2016-07-07 Thread Alexandr Scherbatiy 


Hello,

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

  VALUE_TEXT_ANTIALIAS_OFF should be used for the null antialiased hint 
instead of VALUE_ANTIALIAS_OFF.


 Thanks,
 Alexandr.

Re: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled

2016-07-07 Thread Alexandr Scherbatiy 


The fix looks good to me.

Thanks,
Alexandr.

On 7/6/2016 10:03 PM, Semyon Sadetsky wrote:

On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote:


On 7/6/2016 4:13 PM, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8058742

webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/


   - PangoFonts class is placed in the shared space and it uses the 
X11GraphicsDevice from the unix space. Could there be problems with 
build compilation on platforms differ from Unix?
no it doesn't cause compilations problems. PangoFonts is used on Linux 
platform only.
  - It is better to rename the scale field to nativeScale just to not 
mix it with other scale types
ok.  webrev is updated: 
http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/
  - Does the test 
test/java/awt/font/FontScaling/FontScalingTest.java  fails without 
the proposed fix on Linux?

Yes it fails before and passes after the fix.

--Semyon


  Thanks,
  Alexandr.



After adding hdpi support to JDK the GTK LnF fonts are scaled twice 
using the JDK UI scale factor and the native scale factor derived 
from the screen dpi setting.  The fix removes the native scale if it 
is already taken into account in the JDK UI scale.


--Semyon