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

[Semyon Sadetsky]

On 22.08.2016 18:52, Sergey Bylokhov wrote:

On 22.08.16 16:43, Semyon Sadetsky wrote:



On 8/22/2016 2:14 PM, Sergey Bylokhov wrote:

On 22.08.16 10:56, Semyon Sadetsky wrote:

But I don't suggest to use it as a global scale, use it only if other
scales were not set(default transform is 1).
That also means that it will go to the global UI scale on Linuxes 
which

are not gnome/unity based. And the only difference with the current
solution that on such Linux DEs Java apps will receive some 
uncontrolled

scale because testing of unsupported OSes is out of the scope. If this
topic bothers you I suggest to create a separate bug to investigate 
how

the native scale may be supported on different Linux flavors using the
Xft.dpi env var.  Without that we may get complains that the scale
becomes wrong on unsupported Linuxes and DEs even when hidpi is not 
used

in the native desktop at all.


I do not get it how it can affect the non-dpi systems,

we are talking about the method that receive the desktop scale, right?


Am talking about GraphicsConfiguration.getDefaultTransform() which 
returns non-identity value only on HiDPI screens.
It simply returns a transform to the detected scale. The transform is 
wrong if the native scale is incorrectly detected.


===

since only in jdk9 on HiDPI screens default scale can have some
transform. The difference from the current solution is that the shared
code will used the public/shared java2d api, instead of platform
specific.

 - Take debug scale into account if it was set and skip all 
others.

 - Check J2D_UISCALE
 - Check scale-factor, text-scale-factor, text-scaling-factor.
 - Check Xft.dpi.
 - If non of them was set then scale=1 should be used.

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

[Sergey Bylokhov]

On 22.08.16 16:43, Semyon Sadetsky wrote:



On 8/22/2016 2:14 PM, Sergey Bylokhov wrote:

On 22.08.16 10:56, Semyon Sadetsky wrote:

But I don't suggest to use it as a global scale, use it only if other
scales were not set(default transform is 1).

That also means that it will go to the global UI scale on Linuxes which
are not gnome/unity based. And the only difference with the current
solution that on such Linux DEs Java apps will receive some uncontrolled
scale because testing of unsupported OSes is out of the scope. If this
topic bothers you I suggest to create a separate bug to investigate how
the native scale may be supported on different Linux flavors using the
Xft.dpi env var.  Without that we may get complains that the scale
becomes wrong on unsupported Linuxes and DEs even when hidpi is not used
in the native desktop at all.


I do not get it how it can affect the non-dpi systems,

we are talking about the method that receive the desktop scale, right?


Am talking about GraphicsConfiguration.getDefaultTransform() which 
returns non-identity value only on HiDPI screens.


===

since only in jdk9 on HiDPI screens default scale can have some
transform. The difference from the current solution is that the shared
code will used the public/shared java2d api, instead of platform
specific.


 - Take debug scale into account if it was set and skip all others.
 - Check J2D_UISCALE
 - Check scale-factor, text-scale-factor, text-scaling-factor.
 - Check Xft.dpi.
 - If non of them was set then scale=1 should be used.

















--
Best regards, Sergey.

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

[Semyon Sadetsky]

On 8/22/2016 2:14 PM, Sergey Bylokhov wrote:

On 22.08.16 10:56, Semyon Sadetsky wrote:

But I don't suggest to use it as a global scale, use it only if other
scales were not set(default transform is 1).

That also means that it will go to the global UI scale on Linuxes which
are not gnome/unity based. And the only difference with the current
solution that on such Linux DEs Java apps will receive some uncontrolled
scale because testing of unsupported OSes is out of the scope. If this
topic bothers you I suggest to create a separate bug to investigate how
the native scale may be supported on different Linux flavors using the
Xft.dpi env var.  Without that we may get complains that the scale
becomes wrong on unsupported Linuxes and DEs even when hidpi is not used
in the native desktop at all.


I do not get it how it can affect the non-dpi systems, 
we are talking about the method that receive the desktop scale, right? 
That is how it affects the global device transform.
since only in jdk9 on HiDPI screens default scale can have some 
transform. The difference from the current solution is that the shared 
code will used the public/shared java2d api, instead of platform 
specific.



 - Take debug scale into account if it was set and skip all others.
 - Check J2D_UISCALE
 - Check scale-factor, text-scale-factor, text-scaling-factor.
 - Check Xft.dpi.
 - If non of them was set then scale=1 should be used.

Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java

[Alexander Scherbatiy]

On 17/08/16 15:49, Alexandr Scherbatiy wrote:

On 8/15/2016 12:43 PM, Ambarish Rapte wrote:


Hi,

Please review fix for JDK9,

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

Webrev: 
http://cr.openjdk.java.net/~arapte/8163261/webrev.00/ 



Issue:

Reference to JButton was not getting collected by GC.

Cause:

A strong reference to objects was held by 
PainterMultiResolutionCachedImage.


And the image reference was held by HashMap.

Fix:

Changing the HashMap to WeakHashMap. Entry to 
WeakHashMap gets removed after the object has no other strong reference.


May be using the soft reference would be better in this case. It 
could be expensive to recreate a cache with images every time GC 
removed them.


There is the code which sets a component to the 
PainterMultiResolutionCachedImage:

CachedPainter.paint0(...)
---
if (image instanceof PainterMultiResolutionCachedImage) {
((PainterMultiResolutionCachedImage) image).setParams(c, args);
}

// Render to the passed in Graphics
paintImage(c, g, x, y, w, h, image, args);
---

May be it is possible to clean up the component and args from the 
PainterMultiResolutionCachedImage after the image is drawn?




  Thanks,
  Alexandr.


Regards,

Ambarish

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

[Sergey Bylokhov]

On 22.08.16 10:56, Semyon Sadetsky wrote:

But I don't suggest to use it as a global scale, use it only if other
scales were not set(default transform is 1).

That also means that it will go to the global UI scale on Linuxes which
are not gnome/unity based. And the only difference with the current
solution that on such Linux DEs Java apps will receive some uncontrolled
scale because testing of unsupported OSes is out of the scope. If this
topic bothers you I suggest to create a separate bug to investigate how
the native scale may be supported on different Linux flavors using the
Xft.dpi env var.  Without that we may get complains that the scale
becomes wrong on unsupported Linuxes and DEs even when hidpi is not used
in the native desktop at all.


I do not get it how it can affect the non-dpi systems, since only in 
jdk9 on HiDPI screens default scale can have some transform. The 
difference from the current solution is that the shared code will used 
the public/shared java2d api, instead of platform specific.



 - Take debug scale into account if it was set and skip all others.
 - Check J2D_UISCALE
 - Check scale-factor, text-scale-factor, text-scaling-factor.
 - Check Xft.dpi.
 - If non of them was set then scale=1 should be used.












--
Best regards, Sergey.

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

[Semyon Sadetsky]

On 8/2/2016 6:25 PM, Sergey Bylokhov wrote:

On 29.07.16 19:06, Semyon Sadetsky wrote:

On 29.07.2016 14:30, Sergey Bylokhov wrote:

On 26.07.16 22:05, Semyon Sadetsky wrote:

It is actually directly related to the global scale, since support of
Xft/ was added in JDK-4830281 as a way to scale java UI. And now the
new solution and the old one conflicts. Can we skip the usage of
gnome.Xft if default device scale is not identity (which means that
some other scale factor is used)?

Do you mean if native scale > 1 then to use scale=1 for GTK font size?
That will give the same result I guess.


Did you try to implement it? In this case the gnome.Xft will be used
only if no other scale was set, it should work like described below:

Once again Xft.dpi cannot be used as global scale directly. This bug is
not about global scale.


But I don't suggest to use it as a global scale, use it only if other 
scales were not set(default transform is 1).
That also means that it will go to the global UI scale on Linuxes which 
are not gnome/unity based. And the only difference with the current 
solution that on such Linux DEs Java apps will receive some uncontrolled 
scale because testing of unsupported OSes is out of the scope. If this 
topic bothers you I suggest to create a separate bug to investigate how 
the native scale may be supported on different Linux flavors using the 
Xft.dpi env var.  Without that we may get complains that the scale 
becomes wrong on unsupported Linuxes and DEs even when hidpi is not used 
in the native desktop at all.


--Semyon



 - Take debug scale into account if it was set and skip all others.
 - Check J2D_UISCALE
 - Check scale-factor, text-scale-factor, text-scaling-factor.
 - Check Xft.dpi.
 - If non of them was set then scale=1 should be used.

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

[Semyon Sadetsky]

On 8/1/2016 3:21 PM, Alexandr Scherbatiy wrote:

On 7/29/2016 9:03 PM, Semyon Sadetsky wrote:

Alexander,

the slider thumb is not scaled at all.
  This is a regression from the fix: JDK-8143064 Icons are not 
properly rendered with Windows L on HiDPI display
  The problem is that the 
MetalIconFactory.OceanVerticalSliderThumbIcon/OceanHorizontalSliderThumbIcon.paintToImage(...) 
methods do not take provided image size into account.


  I have filled an issue on it: JDK-8162856 JSlider thumb is twice 
smaller on HiDPI display.

Ok, thanks.
The fix looks good to me.

--Semyon


  Thanks,
  Alexandr.


--Semyon


On 7/28/2016 7:45 PM, Alexandr Scherbatiy wrote:


Hello,

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

- html part of the test is removed

On 7/27/2016 8:11 PM, Phil Race wrote:

> D3D on: 20468 [1] -> 21486 [2] performance increasing: 5%
If I recall correctly, the SwingMark summary score is actually
the run time .. so an increasing number is actually a decrease in 
peformance.

  Sorry. The performance is definitely is decreased after the fix.

  Thanks,
  Alexandr.


Still, the improvement in the visual results is worth it to me.

The test is still odd and I am not sure what the intent is.
If its an applet test then the @test tag should be on the .html file.
The @bug tag in the Java file is 8040279 which is unrelated to this 
issue.
But it looks like its just a way to display some instructions to 
run SwingSet2.
I am not sure that it is at all worth adding something like that as 
a test.


-phil



On 07/27/2016 09:49 AM, Alexandr Scherbatiy wrote:

Hello,

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

- horizontal scroll bars are updated
- the test name is updated
- the instruction to test both vertical and horizontal scroll bars 
are added to the test


I run the SwingMark for the JRadioButton which is painted with 
selected/deselected and enabled states
and JScrollPane which shows vertical and horizontal scroll bars in 
turn.
Each component was repainted 2002 times and the test was repeated 
20 times.


The results below show the SwingMark tests score for D3D on/off in 
format:
test score for the component before the fix [link to the results] 
-> test score for the component after the fix (using ovals or 
polygons) [link to the results] performance increasing in percents.


JRadioButton
D3D on: 20468 [1] -> 21486 [2] performance increasing: 5%
D3D off: 20299 [3] -> 21075 [4] performance increasing: 4%

JScrollPane
D3D  on: 56184 [5] -> 57742 [6] performance increasing: 3%
D3D off: 51758 [7] -> 52987 [8] performance increasing: 3%

If it is necessary, polygons which draw triangles can be replaced 
by Line2D.Float().


Thanks,
Alexandr.

[1] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-base.txt
[2] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-oval.txt
[3] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-base.txt
[4] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-oval.txt


[5] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-base.txt
[6] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-polygon.txt
[7] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-base.txt
[8] 
http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-polygon.txt


On 7/27/2016 3:33 PM, Philip Race wrote:

BTW I meant to point out (but forgot) that I want us
to stop using bug ids as test names. When you stare
at a list of tests in a directory I'd like to see meaningful names.

I don't know what the intention was with the tests here but
any new test should be so named ..

-phil.

On 7/26/16, 11:57 PM, Yuri Nesterenko wrote:

You mean probably that the first test would not compile since
it is "public class bug8160986 " in bug8031573.java ?:-)

-yan

On 07/27/2016 12:08 AM, Phil Race wrote:
Since I noticed it right away, I am sure lots of others will 
soon enough.


-phil.

On 07/25/2016 02:19 PM, Sergey Bylokhov wrote:

On 07.07.16 22:00, Phil Race wrote:
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 





Since it was missed by the author, I am not sure that it will 
be found

by the tester who will run the test.


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

  The screenshots [1] give a hint how UI controls look 
before and

after the fix.

  [1] 

8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

+ awt-dev


> On 22-Aug-2016, at 12:28 pm, Avik Niyogi  wrote:
> 
> Hi All,
> 
> Kindly review the proposed specifications for JDK9. 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8138771 
> 
> 
> Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ 
> 
> 
> Issue: The customised specifications necessitated for getGraphics method did 
> not exist.
>  So test cases created according to derived specifications would lead to test 
> cases failures.
> 
> Cause:  No congruous specifications could elicit failure in circumstances not 
> encompassed 
> in test cases generated without the knowledge of the same.
> 
> Fix: Appropriate comprehensive specifications required were added.
> 
> With Regards,
> Avik Niyogi

8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

Hi All,

Kindly review the proposed specifications for JDK9. 

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


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


Issue: The customised specifications necessitated for getGraphics method did 
not exist.
 So test cases created according to derived specifications would lead to test 
cases failures.

Cause:  No congruous specifications could elicit failure in circumstances not 
encompassed 
in test cases generated without the knowledge of the same.

Fix: Appropriate comprehensive specifications required were added.

With Regards,
Avik Niyogi