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/
<http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.01/>
On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
<semyon.sadet...@oracle.com <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>https://bugs.openjdk.java.net/browse/JDK-8160438
*Webrev:
*<http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.00/>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
