Re: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea

[Philip Race]

I see the fix was just pushed. But my comments are clearly not addressed.

-phil.

On 3/15/17, 10:11 AM, Philip Race wrote:

Does this actually try to address everything they complained about here

http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts 


which points to an image : https://i.stack.imgur.com/fgpBu.png

Check boxes are some of it but not all of it.

There is what appears to be a custom icon there - the black outlined
yellow zig-zg shape - and I don't see how we can draw that ourselves.

Which is why I asked in the bug report if we had looked at how we are 
doing image scaling.
It may be that we are already doing the best we can but I don't know 
that ..


-phil.

On 3/15/17, 8:35 AM, Sergey Bylokhov wrote:

On 3/14/2017 7:31 PM, Sergey Bylokhov wrote:
The initial image at [1] also show some issues in the submenu 
pointer and the menu corners, did we solve them already?
  The submenu icon is updated in the current fix and the issue with 
a menu corner is covered by the fix
JDK-8162350 RepaintManager shifts repainted region when the 
floating point UI scale is used

Thanks, Looks fine.


  Thanks,
  Alexandr.
[1] 
http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts



Hello,

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


Metal JCheckBox and JMenuItem icons are updated to be drawn by 
ovals, arcs and polygons.


The [1] folder contains screenshots how icons are drawn before the 
fix (on the left side) and after the fix (on the right side) with 
Default and Ocean Metal themes.


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


Thanks,
Alexandr.

Re: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea

[Philip Race]

Does this actually try to address everything they complained about here

http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts
which points to an image : https://i.stack.imgur.com/fgpBu.png

Check boxes are some of it but not all of it.

There is what appears to be a custom icon there - the black outlined
yellow zig-zg shape - and I don't see how we can draw that ourselves.

Which is why I asked in the bug report if we had looked at how we are 
doing image scaling.

It may be that we are already doing the best we can but I don't know that ..

-phil.

On 3/15/17, 8:35 AM, Sergey Bylokhov wrote:

On 3/14/2017 7:31 PM, Sergey Bylokhov wrote:

The initial image at [1] also show some issues in the submenu pointer and the 
menu corners, did we solve them already?

  The submenu icon is updated in the current fix and the issue with a menu 
corner is covered by the fix
JDK-8162350 RepaintManager shifts repainted region when the floating point 
UI scale is used

Thanks, Looks fine.


  Thanks,
  Alexandr.

[1] 
http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts


Hello,

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

Metal JCheckBox and JMenuItem icons are updated to be drawn by ovals, arcs and 
polygons.

The [1] folder contains screenshots how icons are drawn before the fix (on the 
left side) and after the fix (on the right side) with Default and Ocean Metal 
themes.

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

Thanks,
Alexandr.

Re: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea

[Sergey Bylokhov]

> On 3/14/2017 7:31 PM, Sergey Bylokhov wrote:
>> The initial image at [1] also show some issues in the submenu pointer and 
>> the menu corners, did we solve them already?
>  The submenu icon is updated in the current fix and the issue with a menu 
> corner is covered by the fix
>JDK-8162350 RepaintManager shifts repainted region when the floating point 
> UI scale is used

Thanks, Looks fine.

> 
>  Thanks,
>  Alexandr.
>> 
>> [1] 
>> http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts
>> 
>>> 
>>> Hello,
>>> 
>>> Could you review the fix:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8174845
>>> webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 
>>> 
>>> 
>>> Metal JCheckBox and JMenuItem icons are updated to be drawn by ovals, arcs 
>>> and polygons.
>>> 
>>> The [1] folder contains screenshots how icons are drawn before the fix (on 
>>> the left side) and after the fix (on the right side) with Default and Ocean 
>>> Metal themes.
>>> 
>>> [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 
>>> 
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>> 
> 

Re: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea

[Alexander Zvegintsev]

Looks good to me;

Thanks,
Alexander.

On 14/03/2017 13:54, Alexandr Scherbatiy wrote:


Hello,

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

  Metal JCheckBox and JMenuItem icons are updated to be drawn by 
ovals, arcs and polygons.


  The [1] folder contains screenshots how icons are drawn before the 
fix (on the left side) and after the fix (on the right side) with 
Default and Ocean Metal themes.


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

Thanks,
Alexandr.

Re: [9] Review Request: 8176448 [macos] Popups in JCombobox and Choice have incorrect location in multiscreen systems

[Alexander Zvegintsev]

+1

Thanks,
Alexander.

On 15/03/2017 15:33, Alexandr Scherbatiy wrote:


The fix looks good to me.

Thanks,
Alexandr.

On 3/14/2017 6:12 PM, Sergey Bylokhov wrote:

Hello,
Please review the fix for jdk9.
In the fixes for JDK-7072653 [1] and JDK-8129838 [2] and JDK-8144161[3]

[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7606d0af7b80

Notes about JDK-7072653
 - AquaComboBoxPopup.java the code "if (py + ph > scrBounds.y + 
scrBounds.height)» compares the vars in a different coordinate 
spaces(combobox vs screen). It is ok in BasicComboPopup.java because 
we translate scrBounds properly.
 - In Aqua the code was changed for the case when 
"JComboBox.isPopDown» property is false, I will create a separate CR 
to fix it when the property is true.


[2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ea7cbf6a7bd

Notes about JDK-8129838
 - AquaComboBoxPopup.java the second loop was changed to use 
"intersects" and "contains" at the same time, but if the point is 
located on the screen it will be found in the first loop, but if it 
was not found the second loop will be noop.
 - Some code was extracted to the new method 
getAvailableScreenArea(), but it was copied from the place where the 
only one screen was available, so it uses «0» as a left point and 
does not take into account that the screen can have non-zero offset.


[3] hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e8e9c65def6d 



Notes about JDK-8144161:
 - After JDK-7072653 [1] and JDK-8129838 were pushed the test which 
was pushed started to fail on OS X, and this was considered as a 
testbug, even if the code in Aqua l was changed to support this 
functionality.
 - The test was changed to use a different look and feels, but since 
it run the test code a few times it start to work incorrectly, 
because  JFrame.getWindows() can return popup window from the 
different L(dispose was called on it but it was not garbage 
collected).


Fix description:
  - An additional check in the second loop in AquaComboBoxPopup.java 
was removed.
  - AquaComboBoxPopup.getAvailableScreenArea now takes into account 
that we can have a few screens.
  - AquaComboBoxPopup.computePopupBounds() was changed to take into 
account that scrBounds is in the screen coordinates space.

  - The test bug7072653.java now check all screen in the system.
  - Note that the new test ChoicePopupLocation.java will fail on 
linux in multiscreen because of JDK-8160270. I will fix it after this 
one.



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

Re: [9] Review Request: 8176448 [macos] Popups in JCombobox and Choice have incorrect location in multiscreen systems

[Alexandr Scherbatiy]

The fix looks good to me.

Thanks,
Alexandr.

On 3/14/2017 6:12 PM, Sergey Bylokhov wrote:

Hello,
Please review the fix for jdk9.
In the fixes for JDK-7072653 [1] and JDK-8129838 [2] and JDK-8144161[3]

[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7606d0af7b80

Notes about JDK-7072653
 - AquaComboBoxPopup.java the code "if (py + ph > scrBounds.y + 
scrBounds.height)» compares the vars in a different coordinate 
spaces(combobox vs screen). It is ok in BasicComboPopup.java because 
we translate scrBounds properly.
 - In Aqua the code was changed for the case when 
"JComboBox.isPopDown» property is false, I will create a separate CR 
to fix it when the property is true.


[2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ea7cbf6a7bd

Notes about JDK-8129838
 - AquaComboBoxPopup.java the second loop was changed to use 
"intersects" and "contains" at the same time, but if the point is 
located on the screen it will be found in the first loop, but if it 
was not found the second loop will be noop.
 - Some code was extracted to the new method getAvailableScreenArea(), 
but it was copied from the place where the only one screen was 
available, so it uses «0» as a left point and does not take into 
account that the screen can have non-zero offset.


[3] hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e8e9c65def6d 



Notes about JDK-8144161:
 - After JDK-7072653 [1] and JDK-8129838 were pushed the test which 
was pushed started to fail on OS X, and this was considered as a 
testbug, even if the code in Aqua l was changed to support this 
functionality.
 - The test was changed to use a different look and feels, but since 
it run the test code a few times it start to work incorrectly, because 
 JFrame.getWindows() can return popup window from the different 
L(dispose was called on it but it was not garbage collected).


Fix description:
  - An additional check in the second loop in AquaComboBoxPopup.java 
was removed.
  - AquaComboBoxPopup.getAvailableScreenArea now takes into account 
that we can have a few screens.
  - AquaComboBoxPopup.computePopupBounds() was changed to take into 
account that scrBounds is in the screen coordinates space.

  - The test bug7072653.java now check all screen in the system.
  - Note that the new test ChoicePopupLocation.java will fail on linux 
in multiscreen because of JDK-8160270. I will fix it after this one.



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

Re: [9] JDK-8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails

[Prasanta Sadhukhan]

On 3/14/2017 6:48 PM, Alexandr Scherbatiy wrote:

On 3/14/2017 3:37 PM, Philip Race wrote:

I am not sure why the test went to the trouble of looking for Arial.
If there was a good reason (Alexander ??) an alternative is to 
initialise
  The test tries to calculate number of intersection with letter O and 
its underline. It is sensitive to the position of the letter.



If I use "SansSerif", it passes in windows,linux but
fails in mac and screenshot of the letter O in mac is different compared 
to windows,linux [1]

For Serif, the screenshot are same in all platforms.

Alex, can you tell me how do you arrive at this hardcoded intersection 
number?

if (backgroundChangesCount != intersections * 2) {
throw new RuntimeException("String is not properly drawn!");
}

[1] screenshot windows: 
http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-windows.png
  linux: 
http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-ubuntu.png

  mac: http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-mac.png

Regards
Prasanta

  Thanks,
  Alexandr.

String fontName = "Serif".

although swapping out Arial for Serif is a very odd choice.
Arial is a Sans Serif font and Serif fonts are not usually used in UIs.

So "SansSerif" would be better
-phil.

On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review a testbug fix where the testcase is failing in linux 
because it is not able to find "Arial" font and tries to use the 
font found in 0th index of getAvailableFontFamilyNames()

which is "Abyssinica SIL".

Bug: https://bugs.openjdk.java.net/browse/JDK-8169897
webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/

Modified the testcode to use "Serif" which is present in all 
platforms. Tested in windows,linux,mac.


Regards
Prasanta