Re: [9] Review request for 8147440 HiDPI (Windows): Swing components have incorrect sizes after changing display resolution

[Alexander Stepanov]

Hello Alexandr,

WRT WindowResizingOnDPIChangingTest - I have quite similar manual test 
on review:

http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html
(but it requires two-display configuration).

Could these tests coexist later on? I hope they are not full duplicates.

(and now we come here, could please anyone review it?)

Thanks,
Alexander



On 2/5/2016 10:52 AM, Alexandr Scherbatiy wrote:


 Hello,

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

  When Display DPI is changed the Windows OS rescales a native window 
size but leaves a native window location the same.

  Java frame size and location are calculated as
nativeWindow.location = scale * javaWindow.location
nativeWindow.size = scale * javaWindow.size

  The first approach is to rescale only frame size on native level so
newNativeWindow.size = newScale *  javaWindow.size
  This allows to leave the nativeWindow.location unchanged but the rule
nativeWindow.location = newScale * javaWindow.location
  will be broken in this case.

  The proposed fix explicitly rescales javaWindow.location in 
WWindowPeer so
  nativeWindow.location = prevScale * prevJavaWindow.location = 
newScale * newJavaWindow.location


 Thanks,
 Alexandr.

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display

[Alexandr Scherbatiy]

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

  - The awt_DesktopProperties.cpp file is updated to use scaleX for 
width rescaling and scaleY for height rescaling


  Thanks,
  Alexandr.

On 2/1/2016 5:51 PM, Jim Graham wrote:

Hi Alexandr,

In awt_DesktopProperties.cpp you are using the Y scaling factor to 
scale widths still - see lines 287 (and others in that same function) 
and then 322 in another function.  It looks like you'll need 
getInvScaleX() and getInvScaleY().


I'll leave it to Phil to comment on the unit test...

...jim

On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote:


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

  - both LOGPIXELSX and Y are used for the theme size scaling.
  - LOGPIXELSY is used for text metrics height rescaling

   Thanks,
   Alexandr.

On 1/29/2016 1:16 PM, Jim Graham wrote:

Hi Alexandr,

Thanks for investigating the behaviors.

With respect to using LOGPIXELSX or Y, these methods are used to scale
both horizontal and vertical measurements so we really should have 2
scale values and rescale methods, one for horizontal use and one for
vertical...

...jim

On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote:

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

  - LOGPIXELSX is changed to  LOGPIXELSY

On 11/16/2015 1:43 PM, Jim Graham wrote:

Note that LOGPIXELSY is global and static between reboots so it
doesn't really matter which monitor is used to get the value.

Also, the issue is that the measurements are in pixels, so if we
convert them into a resolution independent measurement then the rest
of the scaling in the AWT/2D will be correct regardless of any given
monitor's resolution.  We just have to make sure the 
"de-pixelization"

of the measurement is an apples-to-apples calculation.

The question in my mind is whether the values they get from
GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to 
LOGPIXELSY, or

the more recent Per-Monitor aware DPI APIs, or ...?  It would be
interesting to see what happens to those values when you change the
DPI settings on Windows 8.1 and not reboot. If they stay constant
until you reboot then LOGPIXELSY on the main screen would be the 
value

to use to de-scale them...


I tried to use the "Change the size of all items" slider on 
Windows

8.1 without rebooting.
GetDpiForMonitor() returns the updated DPI values: 192, 144, 96
LOGPIXELSY returns unchanged values:  192, 192, 192
SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns 
unchanged

NONCLIENTMETRICS
GetThemePartSize() returns unchanged theme part sizes

It seems that theme part sizes behave in the same way as the
LOGPIXELSY in this case.

Thanks,
Alexandr.



...jim

On 11/16/2015 12:51 PM, Phil Race wrote:

That seems better. But one more question to get a point clarified.
You are using getDesktopWindow() which is for the primary monitor.
I assume that the 'inversion' results in the value being used to be
independent
of the monitor in a multi-mon situation and so when we move to a 2nd
monitor
that inverted size remains valid ?

If so looks good to me.

-phil.

On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote:


  Hello,

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

  - round is used instead of ceil
  - inverted scales are used

  Thanks,
  Alexandr.


On 10/30/2015 10:40 PM, Jim Graham wrote:
In this case round may be better. ceil() is more for cases 
where you
needed "at least X amount of room", but I don't think a font 
size is

an "at least this much" kind of case.

Also, I've been toying with the idea that use of ceil() and 
floor()

in any DPI-adjustment equations should really be "ceil(val -
epsilon)" or "floor(ceil + epsilon)" for some small value of 
epsilon

chosen just large enough to prevent various round-off errors from
affecting the outcome.  One idea is for 1/256 as the value of
epsilon
since that could equate to the smallest measurable difference in
terms of alpha or interpolation results (or 1/512 for "half the
smallest quantum")...

...jim

On 10/29/15 1:36 PM, Phil Race wrote:

size->cx = (int)ceil(size->cx / scale);


So if size->cx / scale works out to be 12.0001 you will round 
it up

to 13?

Can you check what pixel size windows gives you in such a case ?
I'd be a little surprised if they did that rather than round.

Is the SetFontProperty that does not accept a scale parameter 
still

used
somewhere ?

-phil.

On 10/29/2015 04:53 AM, Sergey Bylokhov wrote:

On 17.07.15 16:27, Alexander Scherbatiy wrote:


- Sergey's point about multi-mon should be checked out.
 Windows 8.1 has option "Let me choose one scaling level 
for

all my
displays".
 If I unset it I am able to change the size of all items.
However,
the DPI which returns GetDPIForMonitor is still 2 on HiDPI
displays.

Re: Review Request for 8062946 : Transparent JDialog will lose transparency upon iconify/deiconify sequence.

[Alexander Scherbatiy]

 The fix looks good to me.

 Thanks,
 Alexandr.

On 04/02/16 07:46, Prem Balakrishnan wrote:


Hi ,

Sorry my mistake.

Bug id in subject corrected 8062946.

Regards,
Prem

*From:*Alexandr Scherbatiy
*Sent:* Wednesday, February 03, 2016 8:44 PM
*To:* Prem Balakrishnan; Ambarish Rapte; Semyon Sadetsky; Sergey 
Bylokhov; Rajeev Chamyal; swing-...@openjdk.java.net; 
awt-dev@openjdk.java.net
*Subject:* Re: Review Request for 8062846 : Transparent JDialog will 
lose transparency upon iconify/deiconify sequence.



I just notice that the bug number in the subject 8062846 points to the 
different issue.


Could you resend the same fix the the correct bug id in the subject?

Thanks,
Alexandr.

On 2/2/2016 3:00 AM, Prem Balakrishnan wrote:

Hi Ambarish,

Updated test .

Webrev: http://cr.openjdk.java.net/~arapte/prem/8062946/webrev.01/


Regards,
Prem

*From:*Ambarish Rapte
*Sent:* Tuesday, February 02, 2016 2:47 PM
*To:* Alexander Scherbatiy; Prem Balakrishnan; Semyon Sadetsky;
Sergey Bylokhov; Rajeev Chamyal; swing-...@openjdk.java.net
; awt-dev@openjdk.java.net

*Subject:* RE: Review Request for 8062846 : Transparent JDialog
will lose transparency upon iconify/deiconify sequence.

Hi Prem,

The test passes without including the fix.

The test should fail without fix, and should pass with fix.

Thanks,

Ambarish

*From:*Alexandr Scherbatiy
*Sent:* Monday, February 01, 2016 5:15 PM
*To:* Prem Balakrishnan; Semyon Sadetsky; Sergey Bylokhov;
Ambarish Rapte; Rajeev Chamyal; swing-...@openjdk.java.net
; awt-dev@openjdk.java.net

*Subject:* Re: Review Request for 8062846 : Transparent JDialog
will lose transparency upon iconify/deiconify sequence.


  The fix looks good to me.

  Thanks,
  Alexandr.

On 1/28/2016 9:45 PM, Prem Balakrishnan wrote:

Hi*,*

Please review fix for JDK9,

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

*Webrev:
*http://cr.openjdk.java.net/~arapte/prem/8062946/webrev.00/


Issue:

Transparent JDialog will lose transparency upon
iconify/deiconify sequence.

*Cause:*

Regression: due to 6780496: Javaw process taking up 80-90
percent of CPU time!

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

Intentionally when JDialog is iconified transparency is disabled,

And transparency is not enabled when JDialog is deiconified.

*Fix:*

Transparency is enabled when JDialog is deiconified.

Regards,
Prem

Re: Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

[Alexander Scherbatiy]

 There are just small comments about lines:
 119 Graphics2D g = (Graphics2D) gr;
 120 if (g != null) { g.drawImage(IMG, 0, 0, this); }

  Is it necessary to cast the Graphics to Graphics2D because Graphics 
also has drawImage(...) method?
  Is it necessary to check the graphics to null? It looks like passed 
null graphics should be considered as a bug.


 Thanks,
 Alexandr.


On 20/01/16 20:32, Alexander Stepanov wrote:

Sorry, just a reminder...

Thanks,
Alexander

On 1/14/2016 6:00 PM, Alexander Stepanov wrote:

Hello Sergey,

> Note that MultiRes image can be created at runtime
Indeed, this case should be used for testing, as we have different 
naming conventions for OS X and Windows, so the write-read logic is 
thrown away (as we have such tests already), and now the 
multiresolution image is created at runtime.


Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8142861/webrev.03/

Regards,
Alexander

On 11/16/2015 4:23 PM, Alexander Stepanov wrote:
P.S.: The behavior with Mac OS X mission control should also be 
checked which is definitely a manual job (it seems to be strange 
sometimes; not sure if buggy). So the test instructions should be 
appended a bit...


On 11/16/2015 3:24 PM, Alexander Stepanov wrote:

Hello Sergey,

Thank you for the notes.

> Do you have some thoughts why this test cannot be converted to 
auto test?


The following parts of the test scenario:

- "Please try to drag both parent and child, do it fast several 
times and check if no artifacts occur." (not very valuable part of 
the test, but I've seen these artifacts (only once) after fast and 
long dragging from one display to another, so probably it is better 
to save it, just in case).
- "For Mac OS X please check also the behavior for translucent 
windows appearing on the 2nd (non-active) display"


are hardly automated; especially for Mac OS X because the 
translucent window on the 2nd "inactive" display sometimes occurs 
but sometimes not, and I doubt if it could be predicted exactly 
where and when it should occur when dragging and when stopping 
dragging (and even change color; - e.g. we can see part  of the 
"1x" image on "2x" display, if its other part is still on the "1x" 
display together with cursor).  Please note also that the drag 
behavior for Mac OS X differs, from e.g., Ubuntu Linux: while 
dragging the parent dialog we also drag its child (whereas for 
Ubuntu this is not the case).


Moreover, the test requires not very trivial hardware configuration 
(HiDPI + non-HiDPI displays, ) which, probably, occurs rarely.


So I believe that the manual test has more chances to be run than 
automated (and is less prone to false negative); and attempts to 
automate it will bring more headache than gain.


> Note that MultiRes image can be created at runtime, it will be 
good to cover this also.

Will look at this, thanks.

Regards,
Alexander

P.S.: probably some simpler test cases could be automated: e.g., 
switching display resolution and checking correctness of the 
multires. image displayed, but I'd like to make that separately.


On 11/16/2015 11:35 AM, Sergey Bylokhov wrote:

Hi, Alexander.
 - Note that MultiRes image can be created at runtime, it will be 
good to cover this also.
- Do you have some thoughts why this test cannot be converted to 
auto test? Probably some api can be added to jdk to simplify 
creation of such tests? like already added 
"-Dsun.java2d.uiScale"(JDK-8073320).


On 13.11.15 14:34, Alexander Stepanov wrote:

webrev updated:
http://cr.openjdk.java.net/~anazarov/8142861/webrev.02/

Thanks,
Alexander

On 11/12/2015 7:51 PM, Alexander Stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~anazarov/8142861-3/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8142861

Just a single manual test added.
(sorry, I'll remove these unnecessary 'static' modifiers for
'parentName', 'childName')

Checked on Mac OS X 10.10 (2-display configuration + Quartz) 
with JDK9

b91

Thanks,
Alexander

Re: [9] Review request for 8147440 HiDPI (Windows): Swing components have incorrect sizes after changing display resolution

[Alexander Scherbatiy]

On 05/02/16 12:59, Alexander Stepanov wrote:

Hello Alexandr,

WRT WindowResizingOnDPIChangingTest - I have quite similar manual test 
on review:

http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html
(but it requires two-display configuration).

Could these tests coexist later on? I hope they are not full duplicates.
  Yes, the MultiDisplayTest always requires at least 2 display but 
WindowResizingOnDPIChangingTest can be used for display DPI changing 
only on one monitor. I think they both can coexist.


  Thanks,
  Alexandr.


(and now we come here, could please anyone review it?)

Thanks,
Alexander



On 2/5/2016 10:52 AM, Alexandr Scherbatiy wrote:


 Hello,

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

  When Display DPI is changed the Windows OS rescales a native window 
size but leaves a native window location the same.

  Java frame size and location are calculated as
nativeWindow.location = scale * javaWindow.location
nativeWindow.size = scale * javaWindow.size

  The first approach is to rescale only frame size on native level so
newNativeWindow.size = newScale *  javaWindow.size
  This allows to leave the nativeWindow.location unchanged but the rule
nativeWindow.location = newScale * javaWindow.location
  will be broken in this case.

  The proposed fix explicitly rescales javaWindow.location in 
WWindowPeer so
  nativeWindow.location = prevScale * prevJavaWindow.location = 
newScale * newJavaWindow.location


 Thanks,
 Alexandr.

Re: [9] Review Request for 8139218: Dialog that opens and closes quickly changes focus in original focusowner

[Alexander Scherbatiy]

The fix looks good to me.

Thanks,
Alexandr.

On 22/12/15 14:20, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

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

The root cause: when window gain focus come for window that is hidden 
already focus rollback to another window cannot be done synchronously. 
So number of consequent attempts to set focus to the previous 
component are usually failed and the focus target is shifted to the 
next in the focus traversal cycle.
Solution: try to wait a small time until the parent HW component gain 
the asynchronous focus from native platform.


--Semyon

Re: [9] Review request for 8147440 HiDPI (Windows): Swing components have incorrect sizes after changing display resolution

[Alexander Stepanov]

Thanks!

On 2/5/2016 1:55 PM, Alexander Scherbatiy wrote:

On 05/02/16 12:59, Alexander Stepanov wrote:

Hello Alexandr,

WRT WindowResizingOnDPIChangingTest - I have quite similar manual 
test on review:

http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html
(but it requires two-display configuration).

Could these tests coexist later on? I hope they are not full duplicates.
  Yes, the MultiDisplayTest always requires at least 2 display but 
WindowResizingOnDPIChangingTest can be used for display DPI changing 
only on one monitor. I think they both can coexist.


  Thanks,
  Alexandr.


(and now we come here, could please anyone review it?)

Thanks,
Alexander



On 2/5/2016 10:52 AM, Alexandr Scherbatiy wrote:


 Hello,

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

  When Display DPI is changed the Windows OS rescales a native 
window size but leaves a native window location the same.

  Java frame size and location are calculated as
nativeWindow.location = scale * javaWindow.location
nativeWindow.size = scale * javaWindow.size

  The first approach is to rescale only frame size on native level so
newNativeWindow.size = newScale *  javaWindow.size
  This allows to leave the nativeWindow.location unchanged but the rule
nativeWindow.location = newScale * javaWindow.location
  will be broken in this case.

  The proposed fix explicitly rescales javaWindow.location in 
WWindowPeer so
  nativeWindow.location = prevScale * prevJavaWindow.location = 
newScale * newJavaWindow.location


 Thanks,
 Alexandr.

Re: Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

[Alexander Stepanov]

Hello Alexandr,

Thank you for the notes; yes, these lines are unnecessary. Please see 
the updated patch:

http://cr.openjdk.java.net/~avstepan/8142861/webrev.04/

It should be also mentioned that for now the test is still failing 
because of JDK-8143062. Should it be added to any exclude list?


Thanks,
Alexander


On 2/5/2016 1:51 PM, Alexander Scherbatiy wrote:



 There are just small comments about lines:
 119 Graphics2D g = (Graphics2D) gr;
 120 if (g != null) { g.drawImage(IMG, 0, 0, this); }

  Is it necessary to cast the Graphics to Graphics2D because Graphics 
also has drawImage(...) method?
  Is it necessary to check the graphics to null? It looks like passed 
null graphics should be considered as a bug.


 Thanks,
 Alexandr.


On 20/01/16 20:32, Alexander Stepanov wrote:

Sorry, just a reminder...

Thanks,
Alexander

On 1/14/2016 6:00 PM, Alexander Stepanov wrote:

Hello Sergey,

> Note that MultiRes image can be created at runtime
Indeed, this case should be used for testing, as we have different 
naming conventions for OS X and Windows, so the write-read logic is 
thrown away (as we have such tests already), and now the 
multiresolution image is created at runtime.


Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8142861/webrev.03/

Regards,
Alexander

On 11/16/2015 4:23 PM, Alexander Stepanov wrote:
P.S.: The behavior with Mac OS X mission control should also be 
checked which is definitely a manual job (it seems to be strange 
sometimes; not sure if buggy). So the test instructions should be 
appended a bit...


On 11/16/2015 3:24 PM, Alexander Stepanov wrote:

Hello Sergey,

Thank you for the notes.

> Do you have some thoughts why this test cannot be converted to 
auto test?


The following parts of the test scenario:

- "Please try to drag both parent and child, do it fast several 
times and check if no artifacts occur." (not very valuable part of 
the test, but I've seen these artifacts (only once) after fast and 
long dragging from one display to another, so probably it is 
better to save it, just in case).
- "For Mac OS X please check also the behavior for translucent 
windows appearing on the 2nd (non-active) display"


are hardly automated; especially for Mac OS X because the 
translucent window on the 2nd "inactive" display sometimes occurs 
but sometimes not, and I doubt if it could be predicted exactly 
where and when it should occur when dragging and when stopping 
dragging (and even change color; - e.g. we can see part  of the 
"1x" image on "2x" display, if its other part is still on the "1x" 
display together with cursor).  Please note also that the drag 
behavior for Mac OS X differs, from e.g., Ubuntu Linux: while 
dragging the parent dialog we also drag its child (whereas for 
Ubuntu this is not the case).


Moreover, the test requires not very trivial hardware 
configuration (HiDPI + non-HiDPI displays, ) which, probably, 
occurs rarely.


So I believe that the manual test has more chances to be run than 
automated (and is less prone to false negative); and attempts to 
automate it will bring more headache than gain.


> Note that MultiRes image can be created at runtime, it will be 
good to cover this also.

Will look at this, thanks.

Regards,
Alexander

P.S.: probably some simpler test cases could be automated: e.g., 
switching display resolution and checking correctness of the 
multires. image displayed, but I'd like to make that separately.


On 11/16/2015 11:35 AM, Sergey Bylokhov wrote:

Hi, Alexander.
 - Note that MultiRes image can be created at runtime, it will be 
good to cover this also.
- Do you have some thoughts why this test cannot be converted to 
auto test? Probably some api can be added to jdk to simplify 
creation of such tests? like already added 
"-Dsun.java2d.uiScale"(JDK-8073320).


On 13.11.15 14:34, Alexander Stepanov wrote:

webrev updated:
http://cr.openjdk.java.net/~anazarov/8142861/webrev.02/

Thanks,
Alexander

On 11/12/2015 7:51 PM, Alexander Stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~anazarov/8142861-3/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8142861

Just a single manual test added.
(sorry, I'll remove these unnecessary 'static' modifiers for
'parentName', 'childName')

Checked on Mac OS X 10.10 (2-display configuration + Quartz) 
with JDK9

b91

Thanks,
Alexander

Re: Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

[Alexander Scherbatiy]

 The fix looks good to me.

On 05/02/16 15:59, Alexander Stepanov wrote:

Hello Alexandr,

Thank you for the notes; yes, these lines are unnecessary. Please see 
the updated patch:

http://cr.openjdk.java.net/~avstepan/8142861/webrev.04/

It should be also mentioned that for now the test is still failing 
because of JDK-8143062. Should it be added to any exclude list?


  It is mentioned in the test @bug list. It should be enough because it 
means that the test should pass when the bug 8143062 is fixed.


  Thanks,
  Alexandr.



Thanks,
Alexander


On 2/5/2016 1:51 PM, Alexander Scherbatiy wrote:



 There are just small comments about lines:
 119 Graphics2D g = (Graphics2D) gr;
 120 if (g != null) { g.drawImage(IMG, 0, 0, this); }

  Is it necessary to cast the Graphics to Graphics2D because Graphics 
also has drawImage(...) method?
  Is it necessary to check the graphics to null? It looks like passed 
null graphics should be considered as a bug.


 Thanks,
 Alexandr.


On 20/01/16 20:32, Alexander Stepanov wrote:

Sorry, just a reminder...

Thanks,
Alexander

On 1/14/2016 6:00 PM, Alexander Stepanov wrote:

Hello Sergey,

> Note that MultiRes image can be created at runtime
Indeed, this case should be used for testing, as we have different 
naming conventions for OS X and Windows, so the write-read logic is 
thrown away (as we have such tests already), and now the 
multiresolution image is created at runtime.


Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8142861/webrev.03/

Regards,
Alexander

On 11/16/2015 4:23 PM, Alexander Stepanov wrote:
P.S.: The behavior with Mac OS X mission control should also be 
checked which is definitely a manual job (it seems to be strange 
sometimes; not sure if buggy). So the test instructions should be 
appended a bit...


On 11/16/2015 3:24 PM, Alexander Stepanov wrote:

Hello Sergey,

Thank you for the notes.

> Do you have some thoughts why this test cannot be converted to 
auto test?


The following parts of the test scenario:

- "Please try to drag both parent and child, do it fast several 
times and check if no artifacts occur." (not very valuable part 
of the test, but I've seen these artifacts (only once) after fast 
and long dragging from one display to another, so probably it is 
better to save it, just in case).
- "For Mac OS X please check also the behavior for translucent 
windows appearing on the 2nd (non-active) display"


are hardly automated; especially for Mac OS X because the 
translucent window on the 2nd "inactive" display sometimes occurs 
but sometimes not, and I doubt if it could be predicted exactly 
where and when it should occur when dragging and when stopping 
dragging (and even change color; - e.g. we can see part  of the 
"1x" image on "2x" display, if its other part is still on the 
"1x" display together with cursor).  Please note also that the 
drag behavior for Mac OS X differs, from e.g., Ubuntu Linux: 
while dragging the parent dialog we also drag its child (whereas 
for Ubuntu this is not the case).


Moreover, the test requires not very trivial hardware 
configuration (HiDPI + non-HiDPI displays, ) which, probably, 
occurs rarely.


So I believe that the manual test has more chances to be run than 
automated (and is less prone to false negative); and attempts to 
automate it will bring more headache than gain.


> Note that MultiRes image can be created at runtime, it will be 
good to cover this also.

Will look at this, thanks.

Regards,
Alexander

P.S.: probably some simpler test cases could be automated: e.g., 
switching display resolution and checking correctness of the 
multires. image displayed, but I'd like to make that separately.


On 11/16/2015 11:35 AM, Sergey Bylokhov wrote:

Hi, Alexander.
 - Note that MultiRes image can be created at runtime, it will 
be good to cover this also.
- Do you have some thoughts why this test cannot be converted to 
auto test? Probably some api can be added to jdk to simplify 
creation of such tests? like already added 
"-Dsun.java2d.uiScale"(JDK-8073320).


On 13.11.15 14:34, Alexander Stepanov wrote:

webrev updated:
http://cr.openjdk.java.net/~anazarov/8142861/webrev.02/

Thanks,
Alexander

On 11/12/2015 7:51 PM, Alexander Stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~anazarov/8142861-3/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8142861

Just a single manual test added.
(sorry, I'll remove these unnecessary 'static' modifiers for
'parentName', 'childName')

Checked on Mac OS X 10.10 (2-display configuration + Quartz) 
with JDK9

b91

Thanks,
Alexander

Re: Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

[Alexander Stepanov]

Thank you!

On 2/5/2016 7:58 PM, Alexander Scherbatiy wrote:


 The fix looks good to me.

On 05/02/16 15:59, Alexander Stepanov wrote:

Hello Alexandr,

Thank you for the notes; yes, these lines are unnecessary. Please see 
the updated patch:

http://cr.openjdk.java.net/~avstepan/8142861/webrev.04/

It should be also mentioned that for now the test is still failing 
because of JDK-8143062. Should it be added to any exclude list?


  It is mentioned in the test @bug list. It should be enough because 
it means that the test should pass when the bug 8143062 is fixed.


  Thanks,
  Alexandr.



Thanks,
Alexander


On 2/5/2016 1:51 PM, Alexander Scherbatiy wrote:



 There are just small comments about lines:
 119 Graphics2D g = (Graphics2D) gr;
 120 if (g != null) { g.drawImage(IMG, 0, 0, this); }

  Is it necessary to cast the Graphics to Graphics2D because 
Graphics also has drawImage(...) method?
  Is it necessary to check the graphics to null? It looks like 
passed null graphics should be considered as a bug.


 Thanks,
 Alexandr.


On 20/01/16 20:32, Alexander Stepanov wrote:

Sorry, just a reminder...

Thanks,
Alexander

On 1/14/2016 6:00 PM, Alexander Stepanov wrote:

Hello Sergey,

> Note that MultiRes image can be created at runtime
Indeed, this case should be used for testing, as we have different 
naming conventions for OS X and Windows, so the write-read logic 
is thrown away (as we have such tests already), and now the 
multiresolution image is created at runtime.


Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8142861/webrev.03/

Regards,
Alexander

On 11/16/2015 4:23 PM, Alexander Stepanov wrote:
P.S.: The behavior with Mac OS X mission control should also be 
checked which is definitely a manual job (it seems to be strange 
sometimes; not sure if buggy). So the test instructions should be 
appended a bit...


On 11/16/2015 3:24 PM, Alexander Stepanov wrote:

Hello Sergey,

Thank you for the notes.

> Do you have some thoughts why this test cannot be converted to 
auto test?


The following parts of the test scenario:

- "Please try to drag both parent and child, do it fast several 
times and check if no artifacts occur." (not very valuable part 
of the test, but I've seen these artifacts (only once) after 
fast and long dragging from one display to another, so probably 
it is better to save it, just in case).
- "For Mac OS X please check also the behavior for translucent 
windows appearing on the 2nd (non-active) display"


are hardly automated; especially for Mac OS X because the 
translucent window on the 2nd "inactive" display sometimes 
occurs but sometimes not, and I doubt if it could be predicted 
exactly where and when it should occur when dragging and when 
stopping dragging (and even change color; - e.g. we can see 
part  of the "1x" image on "2x" display, if its other part is 
still on the "1x" display together with cursor).  Please note 
also that the drag behavior for Mac OS X differs, from e.g., 
Ubuntu Linux: while dragging the parent dialog we also drag its 
child (whereas for Ubuntu this is not the case).


Moreover, the test requires not very trivial hardware 
configuration (HiDPI + non-HiDPI displays, ) which, probably, 
occurs rarely.


So I believe that the manual test has more chances to be run 
than automated (and is less prone to false negative); and 
attempts to automate it will bring more headache than gain.


> Note that MultiRes image can be created at runtime, it will be 
good to cover this also.

Will look at this, thanks.

Regards,
Alexander

P.S.: probably some simpler test cases could be automated: e.g., 
switching display resolution and checking correctness of the 
multires. image displayed, but I'd like to make that separately.


On 11/16/2015 11:35 AM, Sergey Bylokhov wrote:

Hi, Alexander.
 - Note that MultiRes image can be created at runtime, it will 
be good to cover this also.
- Do you have some thoughts why this test cannot be converted 
to auto test? Probably some api can be added to jdk to simplify 
creation of such tests? like already added 
"-Dsun.java2d.uiScale"(JDK-8073320).


On 13.11.15 14:34, Alexander Stepanov wrote:

webrev updated:
http://cr.openjdk.java.net/~anazarov/8142861/webrev.02/

Thanks,
Alexander

On 11/12/2015 7:51 PM, Alexander Stepanov wrote:

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~anazarov/8142861-3/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8142861

Just a single manual test added.
(sorry, I'll remove these unnecessary 'static' modifiers for
'parentName', 'childName')

Checked on Mac OS X 10.10 (2-display configuration + Quartz) 
with JDK9

b91

Thanks,
Alexander

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display

[Jim Graham]

Hi Alexandr,

awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo?

Also, is there a still a need for the setFontProperty() variants that 
don't have a scale as the last parameter?


...jim

On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote:


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

   - The awt_DesktopProperties.cpp file is updated to use scaleX for
width rescaling and scaleY for height rescaling

   Thanks,
   Alexandr.

On 2/1/2016 5:51 PM, Jim Graham wrote:

Hi Alexandr,

In awt_DesktopProperties.cpp you are using the Y scaling factor to
scale widths still - see lines 287 (and others in that same function)
and then 322 in another function.  It looks like you'll need
getInvScaleX() and getInvScaleY().

I'll leave it to Phil to comment on the unit test...

...jim

On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote:


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

  - both LOGPIXELSX and Y are used for the theme size scaling.
  - LOGPIXELSY is used for text metrics height rescaling

   Thanks,
   Alexandr.

On 1/29/2016 1:16 PM, Jim Graham wrote:

Hi Alexandr,

Thanks for investigating the behaviors.

With respect to using LOGPIXELSX or Y, these methods are used to scale
both horizontal and vertical measurements so we really should have 2
scale values and rescale methods, one for horizontal use and one for
vertical...

...jim

On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote:

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

  - LOGPIXELSX is changed to  LOGPIXELSY

On 11/16/2015 1:43 PM, Jim Graham wrote:

Note that LOGPIXELSY is global and static between reboots so it
doesn't really matter which monitor is used to get the value.

Also, the issue is that the measurements are in pixels, so if we
convert them into a resolution independent measurement then the rest
of the scaling in the AWT/2D will be correct regardless of any given
monitor's resolution.  We just have to make sure the
"de-pixelization"
of the measurement is an apples-to-apples calculation.

The question in my mind is whether the values they get from
GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to
LOGPIXELSY, or
the more recent Per-Monitor aware DPI APIs, or ...?  It would be
interesting to see what happens to those values when you change the
DPI settings on Windows 8.1 and not reboot. If they stay constant
until you reboot then LOGPIXELSY on the main screen would be the
value
to use to de-scale them...


I tried to use the "Change the size of all items" slider on
Windows
8.1 without rebooting.
GetDpiForMonitor() returns the updated DPI values: 192, 144, 96
LOGPIXELSY returns unchanged values:  192, 192, 192
SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns
unchanged
NONCLIENTMETRICS
GetThemePartSize() returns unchanged theme part sizes

It seems that theme part sizes behave in the same way as the
LOGPIXELSY in this case.

Thanks,
Alexandr.



...jim

On 11/16/2015 12:51 PM, Phil Race wrote:

That seems better. But one more question to get a point clarified.
You are using getDesktopWindow() which is for the primary monitor.
I assume that the 'inversion' results in the value being used to be
independent
of the monitor in a multi-mon situation and so when we move to a 2nd
monitor
that inverted size remains valid ?

If so looks good to me.

-phil.

On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote:


  Hello,

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

  - round is used instead of ceil
  - inverted scales are used

  Thanks,
  Alexandr.


On 10/30/2015 10:40 PM, Jim Graham wrote:

In this case round may be better. ceil() is more for cases
where you
needed "at least X amount of room", but I don't think a font
size is
an "at least this much" kind of case.

Also, I've been toying with the idea that use of ceil() and
floor()
in any DPI-adjustment equations should really be "ceil(val -
epsilon)" or "floor(ceil + epsilon)" for some small value of
epsilon
chosen just large enough to prevent various round-off errors from
affecting the outcome.  One idea is for 1/256 as the value of
epsilon
since that could equate to the smallest measurable difference in
terms of alpha or interpolation results (or 1/512 for "half the
smallest quantum")...

...jim

On 10/29/15 1:36 PM, Phil Race wrote:

size->cx = (int)ceil(size->cx / scale);


So if size->cx / scale works out to be 12.0001 you will round
it up
to 13?

Can you check what pixel size windows gives you in such a case ?
I'd be a little surprised if they did that rather than round.

Is the SetFontProperty that does not accept a scale parameter
still
used
somewhere ?

-phil.

On 10/29/2015 04:53 AM, Sergey Bylokhov wrote:

On 17.07.15 16:27, Alexander Scherbatiy wrote:


- Sergey's point about multi-mon

[9] Review request for 8149151 Use local GraphicsEnvironment to get screen size in WToolkit

[Alexandr Scherbatiy]

Hello,

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

  This is just an enhancement to use local GraphicsEnvironment instead 
of nativec alls to get screen size in WToolkit.
  It also allows to get rid of the calling Devices and checking its 
initialization in native getScreenWidth/height methods

  which can leads to some problems, see the discussion:
http://mail.openjdk.java.net/pipermail/awt-dev/2015-November/010388.html

 Thanks,
 Alexandr.

Re: [9] Review request for 8149151 Use local GraphicsEnvironment to get screen size in WToolkit

[Phil Race]

Looks OK to me.

-phil.

On 02/05/2016 11:52 AM, Alexandr Scherbatiy wrote:


Hello,

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

  This is just an enhancement to use local GraphicsEnvironment instead 
of nativec alls to get screen size in WToolkit.
  It also allows to get rid of the calling Devices and checking its 
initialization in native getScreenWidth/height methods

  which can leads to some problems, see the discussion:
http://mail.openjdk.java.net/pipermail/awt-dev/2015-November/010388.html

 Thanks,
 Alexandr.

Re: [9] Review request for 8149151 Use local GraphicsEnvironment to get screen size in WToolkit

[Sergey Bylokhov]

+1

ps: the correct link is:
http://cr.openjdk.java.net/~alexsch/8149151/webrev.00

On 05.02.16 23:00, Phil Race wrote:

Looks OK to me.

-phil.

On 02/05/2016 11:52 AM, Alexandr Scherbatiy wrote:


Hello,

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

  This is just an enhancement to use local GraphicsEnvironment instead
of nativec alls to get screen size in WToolkit.
  It also allows to get rid of the calling Devices and checking its
initialization in native getScreenWidth/height methods
  which can leads to some problems, see the discussion:
http://mail.openjdk.java.net/pipermail/awt-dev/2015-November/010388.html

 Thanks,
 Alexandr.






--
Best regards, Sergey.