Re: [12] Review Request: 8170937 Swing apps are slow if displaying from a remote source to many local displays

[Phil Race]

Looks good. Maybe update this comment before you push ?

 921  * This method is unused because of two reasons:

".. unused by default ..." ?

-phil.

On 9/10/2018 3:13 PM, Sergey Bylokhov wrote:

Hi, Phil.
On 10/09/2018 13:20, Phil Race wrote:
But should we consider a switch that allows people to still get the 
long, slow, ideal answer ?


Yes it is possible to add a non-public/unsupported property(only as a 
workaround for possible bugs):

http://cr.openjdk.java.net/~serb/8170937/webrev.02
But at some point(jdk12/13?) we can drop it.

Re: [12] Review Request: 8170937 Swing apps are slow if displaying from a remote source to many local displays

[Sergey Bylokhov]

Hi, Phil.
On 10/09/2018 13:20, Phil Race wrote:
But should we consider a switch that allows people to still get the 
long, slow, ideal answer ?


Yes it is possible to add a non-public/unsupported property(only as a 
workaround for possible bugs):

http://cr.openjdk.java.net/~serb/8170937/webrev.02
But at some point(jdk12/13?) we can drop it.


--
Best regards, Sergey.

Re: [12] Review Request: 8170937 Swing apps are slow if displaying from a remote source to many local displays

[Phil Race]

Looks good to me.
But should we consider a switch that allows people to still get the 
long, slow, ideal answer ?


-phil.

On 9/9/2018 5:53 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk 12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8170937
Webrev: http://cr.openjdk.java.net/~serb/8170937/webrev.00

The logic to calculate the screen insets is changed in the 
XToolkit.java. Please take a look to the comments of the bug for more 
information.


 - Additional sanity checks are added to the "ScreenInsetsTest" test.
 - "FrameBorderCounter.java" is updated because it is used by a few 
tests which starts to fail after the fix in the multi-screen config(it 
fail in single screen config before), the reason is that it opens the 
windows to fast.

Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

[Dmitry Markov]

Hi Manajit,

No problem, I will sponsor your commit to JDK 8u once it is ready and approved.

Thanks,
Dmitry 

> On 10 Sep 2018, at 13:19, Manajit Halder  wrote:
> 
> Hi Dmitry,
> 
> Sure, I can port it to JDK 8u, but would require your help in check-in, as I 
> don't have permission to check-in JDK 8u.
> Thanks,
> 
> Manajit
> 
> 
> On 09/09/18 3:35 PM, Dmitry Markov wrote:
>> Hi Manajit,
>> 
>> The fix looks good to me. Can you port it to JDK 8u too, please?
>> 
>> Thanks,
>> Dmitry
>> 
>>> On 7 Sep 2018, at 12:22, Manajit Halder >> > wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> Thanks for the test scenarios. I have run all the AWT, Swing and JCK 
>>> automatic (open and closed) test cases along with manual test cases related 
>>> to Modal Dialog and ordering to ensure that fix doesn't cause any 
>>> regression. These JCK interactive test were run 
>>> "api/java_awt/interactive/ModalDialogTests.html", 
>>> "api/java_awt/interactive/FileDialogTests.html", 
>>> "api/java_awt/interactive/PageDialogTest.html" and 
>>> "api/java_awt/interactive/WindowTest.html" (tests toFront and toBack 
>>> between a window and a Frame). 
>>> For example, manual test 
>>> "open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java"
>>>  tests the scenario specified by you. Also there are many automatic test 
>>> cases in "open/test/jdk/java/awt/Modal/ToBack" and 
>>> "open/test/jdk/java/awt/Modal/ToFront" which tests different scenarios 
>>> related to Modal Dialog and Frame/Window ordering.
>>> 
>>> Please let me know if you have any other test scenarios to be tested.
>>> 
>>> Thanks,
>>> Manajit
>>> On 05/09/18 4:47 PM, Dmitry Markov wrote:
 Hi Manajit,
 
 Thank you for the clarification.
 
 Actually I worry about the case when a window is blocked by another window 
 or a modal dialog. We call orderAboveSiblings() for the blocker
  window in several places, (e.g. inside setVisible(), 
 checkBlockingAndOrder(), etc.) and I guess some of these call might fail 
 with the new implementation of orderAboveSiblings(), (i.e. the modal 
 dialog might be placed behind the blocked window).
 
 For example, let’s say we have the window which is blocked by the modal 
 dialog. What will be the position of the dialog (above or behind the 
 blocked window) once the window is activated? Please note: there are 
 several ways to activate the window: mouse click, toFront() call, etc. Can 
 you verify that these scenarios still work properly on the build with your 
 fix, please?
 
 Also it would be good to execute related AWT/Swing jtreg tests to ensure 
 that nothing is broken.
 
 Thanks,
 Dmitry 
 
> On 4 Sep 2018, at 18:54, Manajit Halder  > wrote:
> 
> Hi Dmitry,
> 
> Thanks for your reply. Please see my reply inline.
> 
> Thanks,
> Manajit
> 
> On 01/09/18 12:02 AM, Dmitry Markov wrote:
>> Hi Manajit,
>> 
>> The current implementation assumes that orderAboveSiblings() places the 
>> window in front of other windows located at the same level. The proposed 
>> fix introduces new behaviour: if the window does not have an owner and 
>> child windows it won’t be ordered, (i.e. in certain conditions the 
>> window may be obscured by other windows even after orderAboveSibling() 
>> execution). Most likely such approach will break existed functionality - 
>> some windows will be incorrectly placed behind other windows.
> If I am not wrong windows (other than Window.Type.POPUP) are already 
> ordered in setVisible method at line no 632 while creation. While 
> debugging I observed that orderFront is called twice when the window is 
> displayed for the first time (in method setVisible and in method 
> orderAboveSiblings). Now when Key press COMMAND + ` is pressed the 
> current window receives windowDidBecomeMain notification and which calls 
> orderFront and also COMMAND + ` tries to order the window above. Two time 
> ordering the window when COMMAND + ` is pressed is causing problem in 
> case of multiple windows.
>> 
>> I am sorry, but the relationship between the original problem described 
>> in the bug, (i.e. cycling through windows issue) and implementation of 
>> orderAboveSiblings() is NOT clear. Can you explain this?
> This issue is a regression of JDK-8169589 introduced in JDK release 
> 8u131. 8169589 introduced new window ordering model and which has 
> introduced the cycling through window issue.
>> 
>> Thanks,
>> Dmitry  
>> 
>>> On 31 Aug 2018, at 07:55, Manajit Halder >> > wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review the fix for JDK12.
>>> 
>>> 
>>> 
>>> Bug: 
>>>  https://bugs.openjdk.java.net/b

Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

[Manajit Halder]

Hi Dmitry,

Sure, I can port it to JDK 8u, but would require your help in check-in, 
as I don't have permission to check-in JDK 8u.


Thanks,

Manajit


On 09/09/18 3:35 PM, Dmitry Markov wrote:

Hi Manajit,

The fix looks good to me. Can you port it to JDK 8u too, please?

Thanks,
Dmitry

On 7 Sep 2018, at 12:22, Manajit Halder > wrote:


Hi Dmitry,

Thanks for the test scenarios. I have run all the AWT, Swing and JCK 
automatic (open and closed) test cases along with manual test cases 
related to Modal Dialog and ordering to ensure that fix doesn't cause 
any regression. These JCK interactive test were run 
"api/java_awt/interactive/ModalDialogTests.html", 
"api/java_awt/interactive/FileDialogTests.html", 
"api/java_awt/interactive/PageDialogTest.html" and 
"api/java_awt/interactive/WindowTest.html" (tests toFront and toBack 
between a window and a Frame).


For example, manual test 
"open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java" 
tests the scenario specified by you. Also there are many automatic 
test cases in "open/test/jdk/java/awt/Modal/ToBack" and 
"open/test/jdk/java/awt/Modal/ToFront" which tests different 
scenarios related to Modal Dialog and Frame/Window ordering.


Please let me know if you have any other test scenarios to be tested.

Thanks,
Manajit

On 05/09/18 4:47 PM, Dmitry Markov wrote:

Hi Manajit,

Thank you for the clarification.

Actually I worry about the case when a window is blocked by another 
window or a modal dialog. We call orderAboveSiblings() for the 
blocker window in several places, (e.g. inside setVisible(), 
checkBlockingAndOrder(), etc.) and I guess some of these call might 
fail with the new implementation of orderAboveSiblings(), (i.e. the 
modal dialog might be placed behind the blocked window).


For example, let’s say we have the window which is blocked by the 
modal dialog. What will be the position of the dialog (above or 
behind the blocked window) once the window is activated? Please 
note: there are several ways to activate the window: mouse click, 
toFront() call, etc. Can you verify that these scenarios still work 
properly on the build with your fix, please?


Also it would be good to execute related AWT/Swing jtreg tests to 
ensure that nothing is broken.


Thanks,
Dmitry

On 4 Sep 2018, at 18:54, Manajit Halder > wrote:


Hi Dmitry,

Thanks for your reply. Please see my reply inline.

Thanks,
Manajit


On 01/09/18 12:02 AM, Dmitry Markov wrote:

Hi Manajit,

The current implementation assumes that orderAboveSiblings() 
places the window in front of other windows located at the same 
level. The proposed fix introduces new behaviour: if the window 
does not have an owner and child windows it won’t be ordered, 
(i.e. in certain conditions the window may be obscured by other 
windows even after orderAboveSibling() execution). Most likely 
such approach will break existed functionality - some windows will 
be incorrectly placed behind other windows.
    If I am not wrong windows (other than Window.Type.POPUP) are 
already ordered in setVisible method at line no 632 while creation. 
While debugging I observed that orderFront is called twice when the 
window is displayed for the first time (in method setVisible and in 
method orderAboveSiblings). Now when Key press COMMAND + ` is 
pressed the current window receives windowDidBecomeMain 
notification and which calls orderFront and also COMMAND + ` tries 
to order the window above. Two time ordering the window when 
COMMAND + ` is pressed is causing problem in case of multiple windows.


I am sorry, but the relationship between the original problem 
described in the bug, (i.e. cycling through windows issue) and 
implementation of orderAboveSiblings() is NOT clear. Can you 
explain this?
    This issue is a regression of JDK-8169589 introduced in JDK 
release 8u131. 8169589 introduced new window ordering model and 
which has introduced the cycling through window issue.


Thanks,
Dmitry

On 31 Aug 2018, at 07:55, Manajit Halder 
mailto:manajit.hal...@oracle.com>> wrote:


Hi All,

Please review the fix for JDK12.



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


Webrev: 

http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ 



Fix: 

    Window ordering is not required if the window doesn't own any 
other windows.


Regards,
Manajit