From ambarish.rapte at oracle.com Mon Aug 1 07:24:50 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 1 Aug 2016 00:24:50 -0700 (PDT) Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: <56657C6C.8040008@oracle.com> References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> Message-ID: <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> Hi, This is an older issue fix which was paused. Here is an updated webrev: http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ Issue & Fix: There were platforms wise different issues: Linux: Issue: Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. Fix: Released reference to TrayIcon by setting these variables to NULL. With this change, reference gets collected mostly with the first OOM. Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. Mac: Issue: The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) Fix: Correction in Test: Corrected the OOM causing code in test. Windows: Issue: The test fails to run on windows, as the popup should have a container parent. Fix: Correction in Test: The test is not required for windows. TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. Hence discarding execution of test on windows. Verification: No other test of TrayIcon fails due to this change on Win, Mac, Linux. Regards, Ambarish -----Original Message----- From: Sergey Bylokhov Sent: Monday, December 07, 2015 6:03 PM To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; awt-dev at openjdk.java.net Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails Hi, Ambarish. It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. On 03.12.15 11:45, Ambarish Rapte wrote: > Hi Semyon, > > I had verified the patch fix with > > Windows 7 64-bit, > > Ubuntu 14.04 32 & 64 bit & > > Mac platform. > > Where the test executes & passes. > > Are you using Ubuntu 15.10 ? > > I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. > > However, solution to this failure would require a small wait for gc to > finish. > > Regards, > > Ambarish > > *From:*Semyon Sadetsky > *Sent:* Wednesday, December 02, 2015 1:54 PM > *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net > *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test > java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > Hi Ambarish, > > Now it fails on Linux: > > ACTION: main -- Failed. Execution failed: `main' threw exception: > java.lang.OutOfMemoryError: Java heap space > REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest > TIME: 1.445 seconds > messages: > command: main -Xmx50m PopupMenuLeakTest > reason: User specified action: run main/othervm -Xmx50m > PopupMenuLeakTest elapsed time (seconds): 1.445 > STDOUT: > STDERR: > java.lang.OutOfMemoryError: Java heap space > at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) > at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:520) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) > at java.lang.Thread.run(Thread.java:747) > > JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: > Java heap space JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: Java > heap space > > --Semyon > > On 11/30/2015 6:44 PM, Ambarish Rapte wrote: > > Hi Semyon, > > I have updated the fix patch with below changes, > > 1.Code formatting. > > 2.Reduced the number of OOMs. > > 3.Removed un-required delays. > > Please review the update patch, which causes OOM > early than previous change. > > http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ > > > Thanks, > Ambarish > > *From:*Semyon Sadetsky > *Sent:* Monday, November 30, 2015 1:54 PM > *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net > > *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test > java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > Hi Ambarish, > > On my Windows 7 64bit the test fails because of timeout. > > --Semyon > > On 11/20/2015 1:30 PM, Ambarish Rapte wrote: > > Hi All, > > Please review the fix for JDK9, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8039081 > > Webrev: > http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ > > *Issue*: > > ?The test fails on windows with below exception, > > Caused by: java.lang.IllegalArgumentException: illegal popup > menu container class > at > sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) > at > sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) > at java.awt.PopupMenu.addNotify(PopupMenu.java:124) > at > PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) > > ?With below exception on mac, ubuntu, > > java.lang.OutOfMemoryError: Java heap space > > at > PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) > > at > PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) > > at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > ava:62) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > orImpl.java:43) > > at > java.lang.reflect.Method.invoke(Method.java:520) > > at > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. > java:92) > > at java.lang.Thread.run(Thread.java:747) > > *Cause*: > > This is a test code issue. > > On Windows Popup menu should have a valid > parent container. > > Is there is no parent container , then above > exception is thrown. > > And also, after throwing OOM exception, program > tried to allocate new memory in catch. > > Which results in failure again. > > *Fix*: > > Updated the test code to add popup menu as a > child of Frame. > > Verifiew on : Ubuntu, Windows & Mac > > Many Thanks, > > Ambarish > -- Best regards, Sergey. From manajit.halder at oracle.com Mon Aug 1 09:35:14 2016 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 1 Aug 2016 15:05:14 +0530 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null Message-ID: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8156099 Webrev: http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ Issue: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null Cause: This issue is a regression of issue https://bugs.openjdk.java.net/browse/JDK-8136763 . While adding fix to 8136763 code was modified to handle coping of multiple files but proper distinction was not added between bytes containing files and urls. Fix: Fixed by comparing format of the bytes received for dataflavor "mimetype=text/uri-list". Fixed by distinguishing between bytes containing files and urls. In both cases the dataflavor contains same ?mimetype=text/uri-list?, but the format is different. Format CF_FILE is only used in case of bytes containing files. Regards, Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Aug 1 12:39:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 1 Aug 2016 15:39:43 +0300 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame Message-ID: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> Hello. Please review the fix for jdk9. In the fix the part of our internal api is opened via jawt library which is a jdk api, so the important part of the fix is in the jawt.h file. This api can be used by other toolkits to implement embedding of awt/swing components into some other native windows. There are no tests in the fix since I plan to implement a number of tests via separate CR.(but I am not sure what is the best way to create a native dll, which will reuse jawt api -> manual/precompiled dll/ compilation on the fly?). jprt job is passed, the ccc will be filed after the technical review. - JAWT_VERSION_9 is used intentionally instead of JAWT_VERSION_1_9. - On OSX validateWithBounds() intentionally was changed to setBoundsPrivate() as on other platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8148109 Webrev can be found at: http://cr.openjdk.java.net/~serb/8148109/webrev.00 -- Best regards, Sergey. From Alan.Bateman at oracle.com Mon Aug 1 12:54:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 05:54:59 -0700 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> Message-ID: <5cd73c3c-46fe-aeb0-9151-61015b652afa@oracle.com> On 01/08/2016 05:39, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix the part of our internal api is opened via jawt library > which is a jdk api, so the important part of the fix is in the jawt.h > file. This api can be used by other toolkits to implement embedding of > awt/swing components into some other native windows. > > There are no tests in the fix since I plan to implement a number of > tests via separate CR.(but I am not sure what is the best way to > create a native dll, which will reuse jawt api -> manual/precompiled > dll/ compilation on the fly?). > > jprt job is passed, the ccc will be filed after the technical review. > > - JAWT_VERSION_9 is used intentionally instead of JAWT_VERSION_1_9. > - On OSX validateWithBounds() intentionally was changed to > setBoundsPrivate() as on other platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148109 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8148109/webrev.00 > At a high-level then this looks the right approach to me. I hope that Eclipse/SWT will be able to move to this easily and maybe there should be an updated comment added to their issue [1]. I see JAWT_VERSION_9 is proposed to have the value 0x00010009. Shouldn't this be0x00090000? In jni.h then JNI_VERSION_9 is defined as 0x00090000. JVM TI is similar (although it has an additional value encoded into its version). -Alan [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318 From philip.race at oracle.com Mon Aug 1 13:19:05 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Aug 2016 06:19:05 -0700 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> Message-ID: <579F4C49.1000408@oracle.com> Hi, Are you sure this is all the files ? Seems like I should be seeing some implementation of this on the Java side. General question: What is the coordinate system for x/y/w/h on a 'hi-dpi' configuration ? Can we add a note somewhere about this. The alignment looks off in mapfile-mawt-vers and mapfile-vers-linux 290 * creates with matching platform information. creates -> created 296 * Moves and resize the embedded frame. Either moves -> move or resize -> resizes ie it should be either "move and resize", or "moves and resizes" * setLocation() and setBounds() for EmbeddedFrame really don't move it could we spell out java.awt.Component.setLocation() and java.awt.Component.setBounds() so it is clear what methods are meant. 304 * within the native parent. These methods always put embedded frame to put embedded frame to -> locate the embedded frame at 305 * (0, 0) for backward compatibility. To allow moving embedded frames 306 * this method was introduced, and it work just the same way as work -> works 307 * setLocation() and setBounds() for usual, non-embedded components. I presume a typical usage of this method will be to resize the embedded frame if the native container is re-sized ? Should there be an additional note here about who's responsibility it is to track resize on the native container and then call this method ? Synthesize native message to activate or deactivate EmbeddedFrame ^ ^ a an -phil. On 8/1/16, 5:39 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > In the fix the part of our internal api is opened via jawt library > which is a jdk api, so the important part of the fix is in the jawt.h > file. This api can be used by other toolkits to implement embedding of > awt/swing components into some other native windows. > > There are no tests in the fix since I plan to implement a number of > tests via separate CR.(but I am not sure what is the best way to > create a native dll, which will reuse jawt api -> manual/precompiled > dll/ compilation on the fly?). > > jprt job is passed, the ccc will be filed after the technical review. > > - JAWT_VERSION_9 is used intentionally instead of JAWT_VERSION_1_9. > - On OSX validateWithBounds() intentionally was changed to > setBoundsPrivate() as on other platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148109 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8148109/webrev.00 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.rapte at oracle.com Tue Aug 2 10:21:28 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 2 Aug 2016 03:21:28 -0700 (PDT) Subject: Review request for JDK-8160936: [TEST_BUG] closed/java/awt/Component/ResourceExhaustionTest/ResourceExhaustionTest fails Message-ID: Hi, Please review the fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8160936 Webrev: http://cr.openjdk.java.net/~arapte/8160936/webrev.00/ Issue: The original test was an applet based test, which failed with java.lang.StackOverflowError. Fix: As applets are deprecated, removing the applet. The test does not fail after this change. This is was a closed test, moving to open repo. The original test was only for windows hence making this test windows only. Regards, Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Aug 2 10:53:01 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 2 Aug 2016 16:23:01 +0530 Subject: Review request for JDK-8160936: [TEST_BUG] closed/java/awt/Component/ResourceExhaustionTest/ResourceExhaustionTest fails In-Reply-To: References: Message-ID: <57A07B8D.5080700@oracle.com> looks good to me. Regards Prasanta On 8/2/2016 3:51 PM, Ambarish Rapte wrote: > > Hi, > > Please review the fix for JDK9, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160936 > > Webrev: > http://cr.openjdk.java.net/~arapte/8160936/webrev.00/ > > > Issue: > > The original test was an applet based test, which > failed with java.lang.StackOverflowError. > > Fix: > > As applets are deprecated, removing the applet. > > The test does not fail after this change. > > This is was a closed test, moving to open repo. > > The original test was only for windows hence making > this test windows only. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Aug 2 13:49:19 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 16:49:19 +0300 Subject: Review request for 8143064 Icons are not properly rendered with Windows L&F on HiDPI display In-Reply-To: References: <5649EBAF.2040308@oracle.com> <5649FF2B.2080607@oracle.com> <0d0e61e6-6f80-5caf-5330-10e6ed0be7cf@oracle.com> <7e2fec3e-28c7-03c0-0771-7539df02c38a@oracle.com> Message-ID: Hi, Alex. I have a few questions about the fix: - I am not sure that tx.getScaleX/tx.getScaleY can be used in this context, because this is not a default transform of GDevice(which can be scaled only), but transform of graphics which can have translate/scale/rotate. Probably we should not take care about scale here, but it should be used in SG2D? (SG2D.drawImage->getResolutionVariant->getImage) or something like that? - It seems that MultiResolutionCachedImage looks similar to PainterMultiResolutionCachedImage?(note that MultiResolutionCachedImage does not save the scalefactor). On 05.07.16 16:53, Alexandr Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8143064/webrev.02 > > - the PainterMultiResolutionCachedImage.getWidth()/getHeight() methods > are overridden to not call the base resolution variant > - scale factors are added to the multi-resolution image > - component and args are set to the PainterMultiResolutionCachedImage > before painting > > On 6/30/2016 11:38 AM, Semyon Sadetsky wrote: >> Hi Alexander, >> >> I have added printout after the line 679 of the XPStyle.java: >> >> 676 ThemeReader.paintBackground(SunWritableRaster.stealData(dbi, 0), >> 677 part.getControlName(c), >> part.getValue(), >> 678 State.getValue(part, state), >> 679 0, 0, w, h, w); >> >> -->> System.out.println(w + " " + h + " " + part.getControlName(c) + " >> " + part.getValue() + " " + State.getValue(part, state)); >> >> And it prints the same lines constantly when I repeatedly focus the >> test window without resizing it. >> >> It seems to me that the image caching doesn't work and the image is >> reconstructed each time from the native theme. > SunGraphics2D requests the multi-resolution image size which leads > that the base resolution image is recreated each time. > I fixed it overridden the getWidth()/getHeight() methods. > > Thanks, > Alexandr. >> >> Yet another question: why not use the actual scaling factor for the >> resolution variant instead of fixed 2X? >> >> --Semyon >> >> >> On 6/29/2016 6:50 PM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8143064/webrev.01 >>> >>> The MultiResolutionImage image is used for the icons painting. >>> >>> Thanks, >>> Alexandr. >>> >>> On 11/16/2015 7:07 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> 109 AffineTransform tx = ((Graphics2D) g).getTransform(); >>>> 110 int sw = tx.isIdentity() ? w : (int) Math.round(w * >>>> tx.getScaleX()); >>>> 111 int sh = tx.isIdentity() ? h : (int) Math.round(h * >>>> tx.getScaleY()); >>>> >>>> I think that it is not necessary that !isIdentity transform return >>>> non-zero value from the getScaleX/Y method. I recall that exactly >>>> the same bug on OSX was fixed via MultiResolutionCachedImage, why we >>>> cannot do the same here? >>>> >>>> On 16.11.15 17:43, Alexander Scherbatiy wrote: >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8143064 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8143064/webrev.00 >>>>> >>>>> Icon image sizes are scaled in sun.swing.CachedPainter. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 2 14:29:41 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 17:29:41 +0300 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: <579F4C49.1000408@oracle.com> References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> <579F4C49.1000408@oracle.com> Message-ID: <6f89d1d8-4f5f-f1e6-7c76-d1ea8be4c923@oracle.com> Hello, Here is the new version http://cr.openjdk.java.net/~serb/8148109/webrev.01 The spec is updated, JAWT_VERSION_9 was changed to 0x00090000. Some notes inline: On 01.08.16 16:19, Philip Race wrote: > Hi, Are you sure this is all the files ? Everything which should be changed to provide an access to our existed API, current fix is just a proxy. If some bugs will be found after that then the java side should be changed. > Seems like I should be seeing some implementation of this on the Java side. General question: What is > the coordinate system for x/y/w/h on a 'hi-dpi' configuration ? Can we > add a note somewhere about this. This is a good question, I'll investigate this since the same notes should be done for old jawt api as well. > The alignment looks off in mapfile-mawt-vers and mapfile-vers-linux Our mapfiles mix tabs and spaces for alignment. I guess we should change this to use one style only. > I presume a typical usage of this method will be to resize the embedded > frame if the native container is re-sized? Yes, typically an EmbeddedFrame is located at 0.0 in the container and changes only the sizes. > > Should there be an additional note here about who's responsibility it is > to track resize on the native container and then call this method ? I am not sure that it is necessary to add a notes about the native container of the EmbeddedFrame, the assumption is that this method should be called then necessary to change the size of our frame, like existed setBounds/setSize/setLocation. > On 8/1/16, 5:39 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> In the fix the part of our internal api is opened via jawt library >> which is a jdk api, so the important part of the fix is in the jawt.h >> file. This api can be used by other toolkits to implement embedding of >> awt/swing components into some other native windows. >> >> There are no tests in the fix since I plan to implement a number of >> tests via separate CR.(but I am not sure what is the best way to >> create a native dll, which will reuse jawt api -> manual/precompiled >> dll/ compilation on the fly?). >> >> jprt job is passed, the ccc will be filed after the technical review. >> >> - JAWT_VERSION_9 is used intentionally instead of JAWT_VERSION_1_9. >> - On OSX validateWithBounds() intentionally was changed to >> setBoundsPrivate() as on other platforms. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148109 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8148109/webrev.00 >> -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 2 15:28:44 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 08:28:44 -0700 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: <6f89d1d8-4f5f-f1e6-7c76-d1ea8be4c923@oracle.com> References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> <579F4C49.1000408@oracle.com> <6f89d1d8-4f5f-f1e6-7c76-d1ea8be4c923@oracle.com> Message-ID: <57A0BC2C.4010009@oracle.com> >> Hi, Are you sure this is all the files ? > > Everything which should be changed to provide an access to our existed > API, current fix is just a proxy. If some bugs will be found after > that then the java side should be changed. Ok, so when you wrote : - On OSX validateWithBounds() intentionally was changed to setBoundsPrivate() as on other platforms. where should I see that change ? -phil. From Sergey.Bylokhov at oracle.com Tue Aug 2 15:30:12 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 18:30:12 +0300 Subject: Review request for JDK-8160936: [TEST_BUG] closed/java/awt/Component/ResourceExhaustionTest/ResourceExhaustionTest fails In-Reply-To: <57A07B8D.5080700@oracle.com> References: <57A07B8D.5080700@oracle.com> Message-ID: Hi, Ambarish. What was the reason of StackOverflowError? On 02.08.16 13:53, Prasanta Sadhukhan wrote: > looks good to me. > > Regards > Prasanta > On 8/2/2016 3:51 PM, Ambarish Rapte wrote: >> >> Hi, >> >> Please review the fix for JDK9, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8160936 >> >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/8160936/webrev.00/ >> >> >> >> >> >> Issue: >> >> The original test was an applet based test, which >> failed with java.lang.StackOverflowError. >> >> >> >> Fix: >> >> As applets are deprecated, removing the applet. >> >> The test does not fail after this change. >> >> >> >> This is was a closed test, moving to open repo. >> >> The original test was only for windows hence making >> this test windows only. >> >> >> >> >> >> Regards, >> >> Ambarish >> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 2 15:36:29 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 18:36:29 +0300 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: <57A0BC2C.4010009@oracle.com> References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> <579F4C49.1000408@oracle.com> <6f89d1d8-4f5f-f1e6-7c76-d1ea8be4c923@oracle.com> <57A0BC2C.4010009@oracle.com> Message-ID: On 02.08.16 18:28, Philip Race wrote: > Ok, so when you wrote : > - On OSX validateWithBounds() intentionally was changed to > setBoundsPrivate() as on other platforms. > > where should I see that change ? In the CViewEmbeddedFrame we have two methods setBoundsPrivate() and validateWithBounds(). Currently on OSX the SWT library use CViewEmbeddedFrame.validateWithBounds() (this method also validate the frame and make it visible). In the jawt api I use setBoundsPrivate() and skip validateWithBounds, so validate+setVisible should be called by the client of jawt API. (like on other platforms win/lin). I am actually not sure that it is necessary to call validate here. -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 2 15:43:33 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 08:43:33 -0700 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> <579F4C49.1000408@oracle.com> <6f89d1d8-4f5f-f1e6-7c76-d1ea8be4c923@oracle.com> <57A0BC2C.4010009@oracle.com> Message-ID: <57A0BFA5.6070309@oracle.com> OK .. I think somewhere we saw SWT code doing this on windows, although I may be confusing it with something else. It seemed like it was a workaround for a JDK bug. So overall this seems fine now. Up to you whether you deal with a note on hi-dpi in this change or separately since as you point out it applies to extant methods too .. -phil. On 8/2/16, 8:36 AM, Sergey Bylokhov wrote: > On 02.08.16 18:28, Philip Race wrote: >> Ok, so when you wrote : >> - On OSX validateWithBounds() intentionally was changed to >> setBoundsPrivate() as on other platforms. >> >> where should I see that change ? > > In the CViewEmbeddedFrame we have two methods setBoundsPrivate() and > validateWithBounds(). Currently on OSX the SWT library use > CViewEmbeddedFrame.validateWithBounds() (this method also validate the > frame and make it visible). In the jawt api I use setBoundsPrivate() > and skip validateWithBounds, so validate+setVisible should be called > by the client of jawt API. (like on other platforms win/lin). I am > actually not sure that it is necessary to call validate here. > From Sergey.Bylokhov at oracle.com Tue Aug 2 15:51:35 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 18:51:35 +0300 Subject: [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame In-Reply-To: <57A0BFA5.6070309@oracle.com> References: <91e0a1a6-6f87-bcc3-8f06-2d2be330885a@oracle.com> <579F4C49.1000408@oracle.com> <6f89d1d8-4f5f-f1e6-7c76-d1ea8be4c923@oracle.com> <57A0BC2C.4010009@oracle.com> <57A0BFA5.6070309@oracle.com> Message-ID: <172279d3-e0fe-2c10-301a-9447295cd479@oracle.com> On 02.08.16 18:43, Philip Race wrote: > OK .. I think somewhere we saw SWT code doing this on windows, > although I may be confusing it with something else. It seemed like > it was a workaround for a JDK bug. It seems in the new version of SWT_AWT.java on windows it will be removed: https://git.eclipse.org/r/#/c/75211/2/bundles/org.eclipse.swt/Eclipse+SWT+AWT/win32/org/eclipse/swt/awt/SWT_AWT.java I will track the changed in swt to handle any possible bugs. > > So overall this seems fine now. > > Up to you whether you deal with a note on hi-dpi in this change > or separately since as you point out it applies to extant methods too .. > > -phil. > > On 8/2/16, 8:36 AM, Sergey Bylokhov wrote: >> On 02.08.16 18:28, Philip Race wrote: >>> Ok, so when you wrote : >>> - On OSX validateWithBounds() intentionally was changed to >>> setBoundsPrivate() as on other platforms. >>> >>> where should I see that change ? >> >> In the CViewEmbeddedFrame we have two methods setBoundsPrivate() and >> validateWithBounds(). Currently on OSX the SWT library use >> CViewEmbeddedFrame.validateWithBounds() (this method also validate the >> frame and make it visible). In the jawt api I use setBoundsPrivate() >> and skip validateWithBounds, so validate+setVisible should be called >> by the client of jawt API. (like on other platforms win/lin). I am >> actually not sure that it is necessary to call validate here. >> -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Wed Aug 3 12:00:10 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Wed, 3 Aug 2016 15:00:10 +0300 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> Message-ID: <067d9ec7-6f74-18ae-6f2b-4846344c23fc@oracle.com> Hi Manajit, The fix looks good. Thanks, Mikhail. On 01.08.2016 12:35, Manajit Halder wrote: > Hi All, > > Kindly review the fix for JDK9. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156099 > > Webrev: > http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ > > > Issue: > [macosx] Drag and drop of link from web browser, DataFlavor types > application/x-java-url and text/uri-list, getTransferData returns null > > Cause: > This issue is a regression of issue > https://bugs.openjdk.java.net/browse/JDK-8136763. > While adding fix to 8136763 code was modified to handle coping of > multiple files but proper distinction was not added between bytes > containing files and urls. > > Fix: > Fixed by comparing format of the bytes received for dataflavor > "mimetype=text/uri-list". > Fixed by distinguishing between bytes containing files and urls. In > both cases the dataflavor contains same ?mimetype=text/uri-list?, but > the format is different. > Format CF_FILE is only used in case of bytes containing files. > > Regards, > Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Aug 4 09:49:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 4 Aug 2016 12:49:24 +0300 Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> Message-ID: Looks fine. On 01.08.16 10:24, Ambarish Rapte wrote: > Hi, > > This is an older issue fix which was paused. > Here is an updated webrev: > http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ > > > Issue & Fix: > There were platforms wise different issues: > > Linux: > Issue: > Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. > PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. > This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. > However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. > Fix: > Released reference to TrayIcon by setting these variables to NULL. > With this change, reference gets collected mostly with the first OOM. > Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. > > Mac: > Issue: > The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) > Fix: > Correction in Test: Corrected the OOM causing code in test. > > Windows: > Issue: > The test fails to run on windows, as the popup should have a container parent. > Fix: > Correction in Test: > The test is not required for windows. > TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. > Hence discarding execution of test on windows. > > > > Verification: > No other test of TrayIcon fails due to this change on Win, Mac, Linux. > > > > Regards, > Ambarish > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, December 07, 2015 6:03 PM > To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > Hi, Ambarish. > > It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. > > On 03.12.15 11:45, Ambarish Rapte wrote: >> Hi Semyon, >> >> I had verified the patch fix with >> >> Windows 7 64-bit, >> >> Ubuntu 14.04 32 & 64 bit & >> >> Mac platform. >> >> Where the test executes & passes. >> >> Are you using Ubuntu 15.10 ? >> >> I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. >> >> However, solution to this failure would require a small wait for gc to >> finish. >> >> Regards, >> >> Ambarish >> >> *From:*Semyon Sadetsky >> *Sent:* Wednesday, December 02, 2015 1:54 PM >> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi Ambarish, >> >> Now it fails on Linux: >> >> ACTION: main -- Failed. Execution failed: `main' threw exception: >> java.lang.OutOfMemoryError: Java heap space >> REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest >> TIME: 1.445 seconds >> messages: >> command: main -Xmx50m PopupMenuLeakTest >> reason: User specified action: run main/othervm -Xmx50m >> PopupMenuLeakTest elapsed time (seconds): 1.445 >> STDOUT: >> STDERR: >> java.lang.OutOfMemoryError: Java heap space >> at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >> at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) >> at java.lang.Thread.run(Thread.java:747) >> >> JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: >> Java heap space JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: Java >> heap space >> >> --Semyon >> >> On 11/30/2015 6:44 PM, Ambarish Rapte wrote: >> >> Hi Semyon, >> >> I have updated the fix patch with below changes, >> >> 1.Code formatting. >> >> 2.Reduced the number of OOMs. >> >> 3.Removed un-required delays. >> >> Please review the update patch, which causes OOM >> early than previous change. >> >> http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ >> >> >> Thanks, >> Ambarish >> >> *From:*Semyon Sadetsky >> *Sent:* Monday, November 30, 2015 1:54 PM >> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >> >> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi Ambarish, >> >> On my Windows 7 64bit the test fails because of timeout. >> >> --Semyon >> >> On 11/20/2015 1:30 PM, Ambarish Rapte wrote: >> >> Hi All, >> >> Please review the fix for JDK9, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8039081 >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ >> >> *Issue*: >> >> ?The test fails on windows with below exception, >> >> Caused by: java.lang.IllegalArgumentException: illegal popup >> menu container class >> at >> sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) >> at >> sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) >> at java.awt.PopupMenu.addNotify(PopupMenu.java:124) >> at >> PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) >> >> ?With below exception on mac, ubuntu, >> >> java.lang.OutOfMemoryError: Java heap space >> >> at >> PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >> >> at >> PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j >> ava:62) >> >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess >> orImpl.java:43) >> >> at >> java.lang.reflect.Method.invoke(Method.java:520) >> >> at >> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. >> java:92) >> >> at java.lang.Thread.run(Thread.java:747) >> >> *Cause*: >> >> This is a test code issue. >> >> On Windows Popup menu should have a valid >> parent container. >> >> Is there is no parent container , then above >> exception is thrown. >> >> And also, after throwing OOM exception, program >> tried to allocate new memory in catch. >> >> Which results in failure again. >> >> *Fix*: >> >> Updated the test code to add popup menu as a >> child of Frame. >> >> Verifiew on : Ubuntu, Windows & Mac >> >> Many Thanks, >> >> Ambarish >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Aug 4 12:53:01 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 4 Aug 2016 15:53:01 +0300 Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: Message-ID: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was NOT > hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Aug 4 13:22:15 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 4 Aug 2016 16:22:15 +0300 Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> Message-ID: On 04.08.16 15:53, Alexandr Scherbatiy wrote: >> While creating Transparent VolatileImage, width and height was NOT >> hidpi scaled. It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary. >> >> >> >> *Fix: *VolatileImage width and height are scaled. >> > > I believe this is an issue in AWT and needs to be discussed on > awt-dev alias. > > Should the backbuffer width and height be also scaled for the > BIWindowPainter? > > Thanks, > Alexandr. > >> >> >> >> Thanks, >> >> Prem >> >> >> >> >> >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Aug 5 06:18:19 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 5 Aug 2016 11:48:19 +0530 Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> Message-ID: <57A42FAB.1050804@oracle.com> On 8/1/2016 12:54 PM, Ambarish Rapte wrote: > Hi, > > This is an older issue fix which was paused. > Here is an updated webrev: > http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ > > > Issue & Fix: > There were platforms wise different issues: > > Linux: > Issue: > Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. > PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. > This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. > However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. > Fix: > Released reference to TrayIcon by setting these variables to NULL. Don't we need to dispose popup and tooltip before setting to NULL? Also, in the test there is a "," missing after copyright year. Regards Prasanta > With this change, reference gets collected mostly with the first OOM. > Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. > > Mac: > Issue: > The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) > Fix: > Correction in Test: Corrected the OOM causing code in test. > > Windows: > Issue: > The test fails to run on windows, as the popup should have a container parent. > Fix: > Correction in Test: > The test is not required for windows. > TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. > Hence discarding execution of test on windows. > > > > Verification: > No other test of TrayIcon fails due to this change on Win, Mac, Linux. > > > > Regards, > Ambarish > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, December 07, 2015 6:03 PM > To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > Hi, Ambarish. > > It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. > > On 03.12.15 11:45, Ambarish Rapte wrote: >> Hi Semyon, >> >> I had verified the patch fix with >> >> Windows 7 64-bit, >> >> Ubuntu 14.04 32 & 64 bit & >> >> Mac platform. >> >> Where the test executes & passes. >> >> Are you using Ubuntu 15.10 ? >> >> I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. >> >> However, solution to this failure would require a small wait for gc to >> finish. >> >> Regards, >> >> Ambarish >> >> *From:*Semyon Sadetsky >> *Sent:* Wednesday, December 02, 2015 1:54 PM >> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi Ambarish, >> >> Now it fails on Linux: >> >> ACTION: main -- Failed. Execution failed: `main' threw exception: >> java.lang.OutOfMemoryError: Java heap space >> REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest >> TIME: 1.445 seconds >> messages: >> command: main -Xmx50m PopupMenuLeakTest >> reason: User specified action: run main/othervm -Xmx50m >> PopupMenuLeakTest elapsed time (seconds): 1.445 >> STDOUT: >> STDERR: >> java.lang.OutOfMemoryError: Java heap space >> at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >> at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) >> at java.lang.Thread.run(Thread.java:747) >> >> JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: >> Java heap space JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: Java >> heap space >> >> --Semyon >> >> On 11/30/2015 6:44 PM, Ambarish Rapte wrote: >> >> Hi Semyon, >> >> I have updated the fix patch with below changes, >> >> 1.Code formatting. >> >> 2.Reduced the number of OOMs. >> >> 3.Removed un-required delays. >> >> Please review the update patch, which causes OOM >> early than previous change. >> >> http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ >> >> >> Thanks, >> Ambarish >> >> *From:*Semyon Sadetsky >> *Sent:* Monday, November 30, 2015 1:54 PM >> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >> >> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi Ambarish, >> >> On my Windows 7 64bit the test fails because of timeout. >> >> --Semyon >> >> On 11/20/2015 1:30 PM, Ambarish Rapte wrote: >> >> Hi All, >> >> Please review the fix for JDK9, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8039081 >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ >> >> *Issue*: >> >> ?The test fails on windows with below exception, >> >> Caused by: java.lang.IllegalArgumentException: illegal popup >> menu container class >> at >> sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) >> at >> sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) >> at java.awt.PopupMenu.addNotify(PopupMenu.java:124) >> at >> PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) >> >> ?With below exception on mac, ubuntu, >> >> java.lang.OutOfMemoryError: Java heap space >> >> at >> PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >> >> at >> PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j >> ava:62) >> >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess >> orImpl.java:43) >> >> at >> java.lang.reflect.Method.invoke(Method.java:520) >> >> at >> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. >> java:92) >> >> at java.lang.Thread.run(Thread.java:747) >> >> *Cause*: >> >> This is a test code issue. >> >> On Windows Popup menu should have a valid >> parent container. >> >> Is there is no parent container , then above >> exception is thrown. >> >> And also, after throwing OOM exception, program >> tried to allocate new memory in catch. >> >> Which results in failure again. >> >> *Fix*: >> >> Updated the test code to add popup menu as a >> child of Frame. >> >> Verifiew on : Ubuntu, Windows & Mac >> >> Many Thanks, >> >> Ambarish >> > > -- > Best regards, Sergey. From ambarish.rapte at oracle.com Fri Aug 5 07:09:47 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 5 Aug 2016 00:09:47 -0700 (PDT) Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: <57A42FAB.1050804@oracle.com> References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> <57A42FAB.1050804@oracle.com> Message-ID: <2b3a1664-7007-41d7-bd2d-128d247436fc@default> Hi Prasanta, The popup peer is removed from TrayIcon.removeNotify(). popup in XTrayIconPeer is reference to same object, hence not required to be disposed in XTrayIconPeer. The TrayIcon object was not getting Garbage collected because of few members of XTrayIconPeer. Hence this change cleans only these blocking references. Tooltip does not block from GC and gets garbage collected as the TrayIcon gets collected. The test is updated, http://cr.openjdk.java.net/~arapte/8039081/webrev.03/ Regards, Ambarish -----Original Message----- From: Prasanta Sadhukhan Sent: Friday, August 05, 2016 11:48 AM To: Ambarish Rapte; awt-dev at openjdk.java.net Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails On 8/1/2016 12:54 PM, Ambarish Rapte wrote: > Hi, > > This is an older issue fix which was paused. > Here is an updated webrev: > http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ > > > Issue & Fix: > There were platforms wise different issues: > > Linux: > Issue: > Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. > PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. > This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. > However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. > Fix: > Released reference to TrayIcon by setting these variables to NULL. Don't we need to dispose popup and tooltip before setting to NULL? Also, in the test there is a "," missing after copyright year. Regards Prasanta > With this change, reference gets collected mostly with the first OOM. > Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. > > Mac: > Issue: > The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) > Fix: > Correction in Test: Corrected the OOM causing code in test. > > Windows: > Issue: > The test fails to run on windows, as the popup should have a container parent. > Fix: > Correction in Test: > The test is not required for windows. > TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. > Hence discarding execution of test on windows. > > > > Verification: > No other test of TrayIcon fails due to this change on Win, Mac, Linux. > > > > Regards, > Ambarish > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, December 07, 2015 6:03 PM > To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; > awt-dev at openjdk.java.net > Subject: Re: Review Request for 8039081: [TEST_BUG] Test > java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > Hi, Ambarish. > > It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. > > On 03.12.15 11:45, Ambarish Rapte wrote: >> Hi Semyon, >> >> I had verified the patch fix with >> >> Windows 7 64-bit, >> >> Ubuntu 14.04 32 & 64 bit & >> >> Mac platform. >> >> Where the test executes & passes. >> >> Are you using Ubuntu 15.10 ? >> >> I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. >> >> However, solution to this failure would require a small wait for gc >> to finish. >> >> Regards, >> >> Ambarish >> >> *From:*Semyon Sadetsky >> *Sent:* Wednesday, December 02, 2015 1:54 PM >> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi Ambarish, >> >> Now it fails on Linux: >> >> ACTION: main -- Failed. Execution failed: `main' threw exception: >> java.lang.OutOfMemoryError: Java heap space >> REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest >> TIME: 1.445 seconds >> messages: >> command: main -Xmx50m PopupMenuLeakTest >> reason: User specified action: run main/othervm -Xmx50m >> PopupMenuLeakTest elapsed time (seconds): 1.445 >> STDOUT: >> STDERR: >> java.lang.OutOfMemoryError: Java heap space >> at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >> at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:520) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) >> at java.lang.Thread.run(Thread.java:747) >> >> JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: >> Java heap space JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: >> Java heap space >> >> --Semyon >> >> On 11/30/2015 6:44 PM, Ambarish Rapte wrote: >> >> Hi Semyon, >> >> I have updated the fix patch with below >> changes, >> >> 1.Code formatting. >> >> 2.Reduced the number of OOMs. >> >> 3.Removed un-required delays. >> >> Please review the update patch, which causes OOM >> early than previous change. >> >> http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ >> >> >> Thanks, >> Ambarish >> >> *From:*Semyon Sadetsky >> *Sent:* Monday, November 30, 2015 1:54 PM >> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >> >> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi Ambarish, >> >> On my Windows 7 64bit the test fails because of timeout. >> >> --Semyon >> >> On 11/20/2015 1:30 PM, Ambarish Rapte wrote: >> >> Hi All, >> >> Please review the fix for JDK9, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8039081 >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ >> >> *Issue*: >> >> ?The test fails on windows with below exception, >> >> Caused by: java.lang.IllegalArgumentException: illegal popup >> menu container class >> at >> sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) >> at >> sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) >> at java.awt.PopupMenu.addNotify(PopupMenu.java:124) >> at >> PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) >> >> ?With below exception on mac, ubuntu, >> >> java.lang.OutOfMemoryError: Java heap space >> >> at >> PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >> >> at >> PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >> j >> ava:62) >> >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >> s >> orImpl.java:43) >> >> at >> java.lang.reflect.Method.invoke(Method.java:520) >> >> at >> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. >> java:92) >> >> at java.lang.Thread.run(Thread.java:747) >> >> *Cause*: >> >> This is a test code issue. >> >> On Windows Popup menu should have a valid >> parent container. >> >> Is there is no parent container , then above >> exception is thrown. >> >> And also, after throwing OOM exception, program >> tried to allocate new memory in catch. >> >> Which results in failure again. >> >> *Fix*: >> >> Updated the test code to add popup menu as a >> child of Frame. >> >> Verifiew on : Ubuntu, Windows & Mac >> >> Many Thanks, >> >> Ambarish >> > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Aug 5 07:19:37 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 5 Aug 2016 12:49:37 +0530 Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: <2b3a1664-7007-41d7-bd2d-128d247436fc@default> References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> <57A42FAB.1050804@oracle.com> <2b3a1664-7007-41d7-bd2d-128d247436fc@default> Message-ID: <57A43E09.8010904@oracle.com> On 8/5/2016 12:39 PM, Ambarish Rapte wrote: > Hi Prasanta, > > The popup peer is removed from TrayIcon.removeNotify(). > popup in XTrayIconPeer is reference to same object, hence not required to be disposed in XTrayIconPeer. > > The TrayIcon object was not getting Garbage collected because of few members of XTrayIconPeer. Hence this change cleans only these blocking references. > Tooltip does not block from GC and gets garbage collected as the TrayIcon gets collected. But we call tooltip = new InfoWindow.Tooltip(eframe, target, this); just like balloon = new InfoWindow.Balloon(eframe, target, this); so should it not get disposed like balloon? Regards Prasanta > The test is updated, > http://cr.openjdk.java.net/~arapte/8039081/webrev.03/ > > > Regards, > Ambarish > > > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Friday, August 05, 2016 11:48 AM > To: Ambarish Rapte; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > > > On 8/1/2016 12:54 PM, Ambarish Rapte wrote: >> Hi, >> >> This is an older issue fix which was paused. >> Here is an updated webrev: >> http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ >> >> >> Issue & Fix: >> There were platforms wise different issues: >> >> Linux: >> Issue: >> Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. >> PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. >> This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. >> However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. >> Fix: >> Released reference to TrayIcon by setting these variables to NULL. > Don't we need to dispose popup and tooltip before setting to NULL? > Also, in the test there is a "," missing after copyright year. > > Regards > Prasanta >> With this change, reference gets collected mostly with the first OOM. >> Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. >> >> Mac: >> Issue: >> The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) >> Fix: >> Correction in Test: Corrected the OOM causing code in test. >> >> Windows: >> Issue: >> The test fails to run on windows, as the popup should have a container parent. >> Fix: >> Correction in Test: >> The test is not required for windows. >> TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. >> Hence discarding execution of test on windows. >> >> >> >> Verification: >> No other test of TrayIcon fails due to this change on Win, Mac, Linux. >> >> >> >> Regards, >> Ambarish >> >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, December 07, 2015 6:03 PM >> To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; >> awt-dev at openjdk.java.net >> Subject: Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi, Ambarish. >> >> It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. >> >> On 03.12.15 11:45, Ambarish Rapte wrote: >>> Hi Semyon, >>> >>> I had verified the patch fix with >>> >>> Windows 7 64-bit, >>> >>> Ubuntu 14.04 32 & 64 bit & >>> >>> Mac platform. >>> >>> Where the test executes & passes. >>> >>> Are you using Ubuntu 15.10 ? >>> >>> I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. >>> >>> However, solution to this failure would require a small wait for gc >>> to finish. >>> >>> Regards, >>> >>> Ambarish >>> >>> *From:*Semyon Sadetsky >>> *Sent:* Wednesday, December 02, 2015 1:54 PM >>> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >>> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >>> >>> Hi Ambarish, >>> >>> Now it fails on Linux: >>> >>> ACTION: main -- Failed. Execution failed: `main' threw exception: >>> java.lang.OutOfMemoryError: Java heap space >>> REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest >>> TIME: 1.445 seconds >>> messages: >>> command: main -Xmx50m PopupMenuLeakTest >>> reason: User specified action: run main/othervm -Xmx50m >>> PopupMenuLeakTest elapsed time (seconds): 1.445 >>> STDOUT: >>> STDERR: >>> java.lang.OutOfMemoryError: Java heap space >>> at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >>> at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:520) >>> at >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) >>> at java.lang.Thread.run(Thread.java:747) >>> >>> JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: >>> Java heap space JavaTest Message: shutting down test >>> >>> STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: >>> Java heap space >>> >>> --Semyon >>> >>> On 11/30/2015 6:44 PM, Ambarish Rapte wrote: >>> >>> Hi Semyon, >>> >>> I have updated the fix patch with below >>> changes, >>> >>> 1.Code formatting. >>> >>> 2.Reduced the number of OOMs. >>> >>> 3.Removed un-required delays. >>> >>> Please review the update patch, which causes OOM >>> early than previous change. >>> >>> http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ >>> >>> >>> Thanks, >>> Ambarish >>> >>> *From:*Semyon Sadetsky >>> *Sent:* Monday, November 30, 2015 1:54 PM >>> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >>> >>> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >>> >>> Hi Ambarish, >>> >>> On my Windows 7 64bit the test fails because of timeout. >>> >>> --Semyon >>> >>> On 11/20/2015 1:30 PM, Ambarish Rapte wrote: >>> >>> Hi All, >>> >>> Please review the fix for JDK9, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8039081 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ >>> >>> *Issue*: >>> >>> ?The test fails on windows with below exception, >>> >>> Caused by: java.lang.IllegalArgumentException: illegal popup >>> menu container class >>> at >>> sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) >>> at >>> sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) >>> at java.awt.PopupMenu.addNotify(PopupMenu.java:124) >>> at >>> PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) >>> >>> ?With below exception on mac, ubuntu, >>> >>> java.lang.OutOfMemoryError: Java heap space >>> >>> at >>> PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >>> >>> at >>> PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >>> >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> at >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >>> j >>> ava:62) >>> >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >>> s >>> orImpl.java:43) >>> >>> at >>> java.lang.reflect.Method.invoke(Method.java:520) >>> >>> at >>> >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. >>> java:92) >>> >>> at java.lang.Thread.run(Thread.java:747) >>> >>> *Cause*: >>> >>> This is a test code issue. >>> >>> On Windows Popup menu should have a valid >>> parent container. >>> >>> Is there is no parent container , then above >>> exception is thrown. >>> >>> And also, after throwing OOM exception, program >>> tried to allocate new memory in catch. >>> >>> Which results in failure again. >>> >>> *Fix*: >>> >>> Updated the test code to add popup menu as a >>> child of Frame. >>> >>> Verifiew on : Ubuntu, Windows & Mac >>> >>> Many Thanks, >>> >>> Ambarish >>> >> -- >> Best regards, Sergey. From ambarish.rapte at oracle.com Fri Aug 5 09:10:43 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 5 Aug 2016 02:10:43 -0700 (PDT) Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: <57A43E09.8010904@oracle.com> References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> <57A42FAB.1050804@oracle.com> <2b3a1664-7007-41d7-bd2d-128d247436fc@default> <57A43E09.8010904@oracle.com> Message-ID: Hi Prasanta, Please review the updated webrev, http://cr.openjdk.java.net/~arapte/8039081/webrev.04/ Updated with call to tooltip.dispose(), as you suggested to dispose it before even GC. Regards, Ambarish -----Original Message----- From: Prasanta Sadhukhan Sent: Friday, August 05, 2016 12:50 PM To: Ambarish Rapte; awt-dev at openjdk.java.net Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails On 8/5/2016 12:39 PM, Ambarish Rapte wrote: > Hi Prasanta, > > The popup peer is removed from TrayIcon.removeNotify(). > popup in XTrayIconPeer is reference to same object, hence not required to be disposed in XTrayIconPeer. > > The TrayIcon object was not getting Garbage collected because of few members of XTrayIconPeer. Hence this change cleans only these blocking references. > Tooltip does not block from GC and gets garbage collected as the TrayIcon gets collected. But we call tooltip = new InfoWindow.Tooltip(eframe, target, this); just like balloon = new InfoWindow.Balloon(eframe, target, this); so should it not get disposed like balloon? Regards Prasanta > The test is updated, > http://cr.openjdk.java.net/~arapte/8039081/webrev.03/ > > > Regards, > Ambarish > > > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Friday, August 05, 2016 11:48 AM > To: Ambarish Rapte; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8039081: [TEST_BUG] Test > java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > > > On 8/1/2016 12:54 PM, Ambarish Rapte wrote: >> Hi, >> >> This is an older issue fix which was paused. >> Here is an updated webrev: >> http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ >> >> >> Issue & Fix: >> There were platforms wise different issues: >> >> Linux: >> Issue: >> Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. >> PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. >> This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. >> However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. >> Fix: >> Released reference to TrayIcon by setting these variables to NULL. > Don't we need to dispose popup and tooltip before setting to NULL? > Also, in the test there is a "," missing after copyright year. > > Regards > Prasanta >> With this change, reference gets collected mostly with the first OOM. >> Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. >> >> Mac: >> Issue: >> The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) >> Fix: >> Correction in Test: Corrected the OOM causing code in test. >> >> Windows: >> Issue: >> The test fails to run on windows, as the popup should have a container parent. >> Fix: >> Correction in Test: >> The test is not required for windows. >> TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. >> Hence discarding execution of test on windows. >> >> >> >> Verification: >> No other test of TrayIcon fails due to this change on Win, Mac, Linux. >> >> >> >> Regards, >> Ambarish >> >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, December 07, 2015 6:03 PM >> To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; >> awt-dev at openjdk.java.net >> Subject: Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> Hi, Ambarish. >> >> It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. >> >> On 03.12.15 11:45, Ambarish Rapte wrote: >>> Hi Semyon, >>> >>> I had verified the patch fix with >>> >>> Windows 7 64-bit, >>> >>> Ubuntu 14.04 32 & 64 bit & >>> >>> Mac platform. >>> >>> Where the test executes & passes. >>> >>> Are you using Ubuntu 15.10 ? >>> >>> I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. >>> >>> However, solution to this failure would require a small wait for gc >>> to finish. >>> >>> Regards, >>> >>> Ambarish >>> >>> *From:*Semyon Sadetsky >>> *Sent:* Wednesday, December 02, 2015 1:54 PM >>> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >>> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >>> >>> Hi Ambarish, >>> >>> Now it fails on Linux: >>> >>> ACTION: main -- Failed. Execution failed: `main' threw exception: >>> java.lang.OutOfMemoryError: Java heap space >>> REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest >>> TIME: 1.445 seconds >>> messages: >>> command: main -Xmx50m PopupMenuLeakTest >>> reason: User specified action: run main/othervm -Xmx50m >>> PopupMenuLeakTest elapsed time (seconds): 1.445 >>> STDOUT: >>> STDERR: >>> java.lang.OutOfMemoryError: Java heap space >>> at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >>> at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:520) >>> at >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) >>> at java.lang.Thread.run(Thread.java:747) >>> >>> JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: >>> Java heap space JavaTest Message: shutting down test >>> >>> STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: >>> Java heap space >>> >>> --Semyon >>> >>> On 11/30/2015 6:44 PM, Ambarish Rapte wrote: >>> >>> Hi Semyon, >>> >>> I have updated the fix patch with below >>> changes, >>> >>> 1.Code formatting. >>> >>> 2.Reduced the number of OOMs. >>> >>> 3.Removed un-required delays. >>> >>> Please review the update patch, which causes OOM >>> early than previous change. >>> >>> http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ >>> >>> >>> Thanks, >>> Ambarish >>> >>> *From:*Semyon Sadetsky >>> *Sent:* Monday, November 30, 2015 1:54 PM >>> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >>> >>> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java >>> fails >>> >>> Hi Ambarish, >>> >>> On my Windows 7 64bit the test fails because of timeout. >>> >>> --Semyon >>> >>> On 11/20/2015 1:30 PM, Ambarish Rapte wrote: >>> >>> Hi All, >>> >>> Please review the fix for JDK9, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8039081 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ >>> >>> *Issue*: >>> >>> ?The test fails on windows with below exception, >>> >>> Caused by: java.lang.IllegalArgumentException: illegal popup >>> menu container class >>> at >>> sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) >>> at >>> sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) >>> at java.awt.PopupMenu.addNotify(PopupMenu.java:124) >>> at >>> >>> PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) >>> >>> ?With below exception on mac, ubuntu, >>> >>> java.lang.OutOfMemoryError: Java heap space >>> >>> at >>> >>> PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >>> >>> at >>> PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >>> >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> >>> at >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >>> j >>> ava:62) >>> >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce >>> s >>> s >>> orImpl.java:43) >>> >>> at >>> java.lang.reflect.Method.invoke(Method.java:520) >>> >>> at >>> >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. >>> java:92) >>> >>> at java.lang.Thread.run(Thread.java:747) >>> >>> *Cause*: >>> >>> This is a test code issue. >>> >>> On Windows Popup menu should have a valid >>> parent container. >>> >>> Is there is no parent container , then above >>> exception is thrown. >>> >>> And also, after throwing OOM exception, program >>> tried to allocate new memory in catch. >>> >>> Which results in failure again. >>> >>> *Fix*: >>> >>> Updated the test code to add popup menu as a >>> child of Frame. >>> >>> Verifiew on : Ubuntu, Windows & Mac >>> >>> Many Thanks, >>> >>> Ambarish >>> >> -- >> Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Aug 5 09:14:13 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 5 Aug 2016 14:44:13 +0530 Subject: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails In-Reply-To: References: <565C07B9.5050806@oracle.com> <565EAA89.9020402@oracle.com> <290d1d5a-f61d-4e49-ba11-fb40f1fb5080@default> <56657C6C.8040008@oracle.com> <0c6598f5-11a5-4b9c-abc4-fa02e56c1fab@default> <57A42FAB.1050804@oracle.com> <2b3a1664-7007-41d7-bd2d-128d247436fc@default> <57A43E09.8010904@oracle.com> Message-ID: <57A458E5.7010900@oracle.com> +1 Regards Prasanta On 8/5/2016 2:40 PM, Ambarish Rapte wrote: > Hi Prasanta, > > Please review the updated webrev, > http://cr.openjdk.java.net/~arapte/8039081/webrev.04/ > > Updated with call to tooltip.dispose(), as you suggested to dispose it before even GC. > > > Regards, > Ambarish > > > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Friday, August 05, 2016 12:50 PM > To: Ambarish Rapte; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8039081: [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails > > > > On 8/5/2016 12:39 PM, Ambarish Rapte wrote: >> Hi Prasanta, >> >> The popup peer is removed from TrayIcon.removeNotify(). >> popup in XTrayIconPeer is reference to same object, hence not required to be disposed in XTrayIconPeer. >> >> The TrayIcon object was not getting Garbage collected because of few members of XTrayIconPeer. Hence this change cleans only these blocking references. >> Tooltip does not block from GC and gets garbage collected as the TrayIcon gets collected. > But we call > > tooltip = new InfoWindow.Tooltip(eframe, target, this); just like balloon = new InfoWindow.Balloon(eframe, target, this); so should it not get disposed like balloon? > > Regards > Prasanta >> The test is updated, >> http://cr.openjdk.java.net/~arapte/8039081/webrev.03/ >> >> >> Regards, >> Ambarish >> >> >> >> -----Original Message----- >> From: Prasanta Sadhukhan >> Sent: Friday, August 05, 2016 11:48 AM >> To: Ambarish Rapte; awt-dev at openjdk.java.net >> Subject: Re: Review Request for 8039081: [TEST_BUG] Test >> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >> >> >> >> On 8/1/2016 12:54 PM, Ambarish Rapte wrote: >>> Hi, >>> >>> This is an older issue fix which was paused. >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~arapte/8039081/webrev.02/ >>> >>> >>> Issue & Fix: >>> There were platforms wise different issues: >>> >>> Linux: >>> Issue: >>> Reference to TrayIcon was not released from member fields of XTrayIconPeer like, TrayIconCanvas, XTrayIconEmbeddedFrame. >>> PopupMenu.removeNotify() was not called for PopupMenu added to TrayIcon. >>> This prevented from TrayIcon & PopupMenu to TrayIcon from getting garbage collected. >>> However the behavior was not uniform: Sometimes the reference gets collected but sometimes it does not even after 100+ OOMs. >>> Fix: >>> Released reference to TrayIcon by setting these variables to NULL. >> Don't we need to dispose popup and tooltip before setting to NULL? >> Also, in the test there is a "," missing after copyright year. >> >> Regards >> Prasanta >>> With this change, reference gets collected mostly with the first OOM. >>> Removed listeners to avoid any events while the TrayIcon/Peer is getting disposed: Had observed a NPE at TrayIconEventProxy::MouseExited(), hence removeListeners() is required. >>> >>> Mac: >>> Issue: >>> The test failed with OOM exception, due to incorrect way of causing OOM in the test. (Line No.85 in existing Test) >>> Fix: >>> Correction in Test: Corrected the OOM causing code in test. >>> >>> Windows: >>> Issue: >>> The test fails to run on windows, as the popup should have a container parent. >>> Fix: >>> Correction in Test: >>> The test is not required for windows. >>> TrayIcon & PopupMenu get collected easily on windows, verified that by changes in test. >>> Hence discarding execution of test on windows. >>> >>> >>> >>> Verification: >>> No other test of TrayIcon fails due to this change on Win, Mac, Linux. >>> >>> >>> >>> Regards, >>> Ambarish >>> >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Monday, December 07, 2015 6:03 PM >>> To: Ambarish Rapte; Semyon Sadetsky; Prasanta Sadhukhan; >>> awt-dev at openjdk.java.net >>> Subject: Re: Review Request for 8039081: [TEST_BUG] Test >>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >>> >>> Hi, Ambarish. >>> >>> It seems this version of the test completes successfully, before related fix was integrated(JDK-8007220) but it should fail(I tested jdk8u05b13), please double check. >>> >>> On 03.12.15 11:45, Ambarish Rapte wrote: >>>> Hi Semyon, >>>> >>>> I had verified the patch fix with >>>> >>>> Windows 7 64-bit, >>>> >>>> Ubuntu 14.04 32 & 64 bit & >>>> >>>> Mac platform. >>>> >>>> Where the test executes & passes. >>>> >>>> Are you using Ubuntu 15.10 ? >>>> >>>> I am setting up Ubuntu 15.10 64 bit to reproduce the same failure. >>>> >>>> However, solution to this failure would require a small wait for gc >>>> to finish. >>>> >>>> Regards, >>>> >>>> Ambarish >>>> >>>> *From:*Semyon Sadetsky >>>> *Sent:* Wednesday, December 02, 2015 1:54 PM >>>> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >>>> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >>>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java fails >>>> >>>> Hi Ambarish, >>>> >>>> Now it fails on Linux: >>>> >>>> ACTION: main -- Failed. Execution failed: `main' threw exception: >>>> java.lang.OutOfMemoryError: Java heap space >>>> REASON: User specified action: run main/othervm -Xmx50m PopupMenuLeakTest >>>> TIME: 1.445 seconds >>>> messages: >>>> command: main -Xmx50m PopupMenuLeakTest >>>> reason: User specified action: run main/othervm -Xmx50m >>>> PopupMenuLeakTest elapsed time (seconds): 1.445 >>>> STDOUT: >>>> STDERR: >>>> java.lang.OutOfMemoryError: Java heap space >>>> at PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >>>> at PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:520) >>>> at >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) >>>> at java.lang.Thread.run(Thread.java:747) >>>> >>>> JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: >>>> Java heap space JavaTest Message: shutting down test >>>> >>>> STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: >>>> Java heap space >>>> >>>> --Semyon >>>> >>>> On 11/30/2015 6:44 PM, Ambarish Rapte wrote: >>>> >>>> Hi Semyon, >>>> >>>> I have updated the fix patch with below >>>> changes, >>>> >>>> 1.Code formatting. >>>> >>>> 2.Reduced the number of OOMs. >>>> >>>> 3.Removed un-required delays. >>>> >>>> Please review the update patch, which causes OOM >>>> early than previous change. >>>> >>>> http://cr.openjdk.java.net/~arapte/8039081/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Ambarish >>>> >>>> *From:*Semyon Sadetsky >>>> *Sent:* Monday, November 30, 2015 1:54 PM >>>> *To:* Ambarish Rapte; Prasanta Sadhukhan; awt-dev at openjdk.java.net >>>> >>>> *Subject:* Re: Review Request for 8039081: [TEST_BUG] Test >>>> java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java >>>> fails >>>> >>>> Hi Ambarish, >>>> >>>> On my Windows 7 64bit the test fails because of timeout. >>>> >>>> --Semyon >>>> >>>> On 11/20/2015 1:30 PM, Ambarish Rapte wrote: >>>> >>>> Hi All, >>>> >>>> Please review the fix for JDK9, >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8039081 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~arapte/8039081/webrev.00/ >>>> >>>> *Issue*: >>>> >>>> ?The test fails on windows with below exception, >>>> >>>> Caused by: java.lang.IllegalArgumentException: illegal popup >>>> menu container class >>>> at >>>> sun.awt.windows.WPopupMenuPeer.(WPopupMenuPeer.java:65) >>>> at >>>> sun.awt.windows.WToolkit.createPopupMenu(WToolkit.java:461) >>>> at java.awt.PopupMenu.addNotify(PopupMenu.java:124) >>>> at >>>> >>>> PopupMenuLeakTest.addNotifyPopup(PopupMenuLeakTest.java:63) >>>> >>>> ?With below exception on mac, ubuntu, >>>> >>>> java.lang.OutOfMemoryError: Java heap space >>>> >>>> at >>>> >>>> PopupMenuLeakTest.assertCollected(PopupMenuLeakTest.java:85) >>>> >>>> at >>>> PopupMenuLeakTest.main(PopupMenuLeakTest.java:57) >>>> >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> >>>> at >>>> >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >>>> j >>>> ava:62) >>>> >>>> at >>>> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce >>>> s >>>> s >>>> orImpl.java:43) >>>> >>>> at >>>> java.lang.reflect.Method.invoke(Method.java:520) >>>> >>>> at >>>> >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper. >>>> java:92) >>>> >>>> at java.lang.Thread.run(Thread.java:747) >>>> >>>> *Cause*: >>>> >>>> This is a test code issue. >>>> >>>> On Windows Popup menu should have a valid >>>> parent container. >>>> >>>> Is there is no parent container , then above >>>> exception is thrown. >>>> >>>> And also, after throwing OOM exception, program >>>> tried to allocate new memory in catch. >>>> >>>> Which results in failure again. >>>> >>>> *Fix*: >>>> >>>> Updated the test code to add popup menu as a >>>> child of Frame. >>>> >>>> Verifiew on : Ubuntu, Windows & Mac >>>> >>>> Many Thanks, >>>> >>>> Ambarish >>>> >>> -- >>> Best regards, Sergey. From mikhail.cherkasov at oracle.com Fri Aug 5 16:19:01 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Fri, 5 Aug 2016 19:19:01 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice Message-ID: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> Hi all, Please review a fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8160696 webrev: http://cr.openjdk.java.net/~mcherkas/8160696/webrev.00/ Java throws exception: "IllegalArgumentException: adding a component to a container on a different GraphicsDevice" if you move a Java application to different monitor and add a Component to a Container on another graphics device, without explicitly removing the Component from its previous parent. Moving components between containers works fine if you remove the component manually before moving it to other container, however this is already done in addImpl method, so I've just put a removing the component from old parent before " checkGD". It works fine now and I'm not sure whether we need "checkGD" at all, however I leave it there just in case. Thanks, Mikhail. From Sergey.Bylokhov at oracle.com Fri Aug 5 18:17:23 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 5 Aug 2016 21:17:23 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> Message-ID: Hi, Mikhail. Please update the header of the test and rename it to some meaningful name. Also note that the frames should be disposed at the end of the test. On 05.08.16 19:19, Mikhail Cherkasov wrote: > Hi all, > > Please review a fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8160696 > webrev: > http://cr.openjdk.java.net/~mcherkas/8160696/webrev.00/ > > Java throws exception: "IllegalArgumentException: adding a component to > a container on a different GraphicsDevice" if you move a Java > application to different monitor and > add a Component to a Container on another graphics device, without > explicitly > removing the Component from its previous parent. > > Moving components between containers works fine if you remove the component > manually before moving it to other container, however this is already > done in addImpl > method, so I've just put a removing the component from old parent before > " checkGD". > It works fine now and I'm not sure whether we need "checkGD" at all, > however I leave it > there just in case. > > Thanks, > Mikhail. -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Mon Aug 8 20:39:59 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 9 Aug 2016 00:39:59 +0400 Subject: RFR(XXS): 8163408: Fix wrong prototype of getNativeScaleFactor() in systemScale.h In-Reply-To: References: Message-ID: The fix should be reviewed on the awt-dev alias. On 08/08/16 22:36, Volker Simonis wrote: > Hi, > > can I please have a review for the following trivial fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8163408/ > https://bugs.openjdk.java.net/browse/JDK-8163408 > > I'd like to push this directly to jdk9/dev if possible because the > problem has already spread across all the other repos and I'd like to > fix it as fast as possible in all repos. > > The fix for "8149115: [hidpi] Linux: display-wise scaling factor > should probably be taken into account" changed the prototype for > getNativeScaleFactor() in systemScale.h from: > > int getNativeScaleFactor(); > > to > > double getNativeScaleFactor(); > > But forgot to add the "char*" parameter to the signature which is > required by the implementation in systemScale.c (and the various call > sites): > > double getNativeScaleFactor(char *output_name) { > > This leads to the following waring/error: > > /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c: > In function ?Ja > va_sun_awt_X11GraphicsDevice_getNativeScaleFactor?: > /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:2185:5: > error: c > all to function ?getNativeScaleFactor? without a real prototype > [-Werror=unprototyped-calls] > double scale = getNativeScaleFactor(name); > ^ > In file included from > /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Graphics > Env.c:46:0: > /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h:29:8: > note: ? > getNativeScaleFactor? was declared here > double getNativeScaleFactor(); > ^ > cc1: all warnings being treated as errors > > If we fix that we will get: > > /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: > In function ?S > plashGetScaledImageName?: > /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:809:5: > error: t > oo few arguments to function ?getNativeScaleFactor? > *scaleFactor = getNativeScaleFactor(); > ^ > > I observed these warnings/errors with 4.8.5 and it is a miracle for me > why newer versions of GCC (apparently 4.9.2 which seems to be Oracles > officially supported compiler according to > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) > or gcc 5.4.0 whiohc I've tried on Ubuntu 16.04 don't detect this > problem? > > Thank you and best regards, > Volker From volker.simonis at gmail.com Tue Aug 9 07:37:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Aug 2016 09:37:23 +0200 Subject: RFR(XXS): 8163408: Fix wrong prototype of getNativeScaleFactor() in systemScale.h In-Reply-To: References: Message-ID: I've just send the RFR to the same list on which the offending change 8149115 has been reviewed. But I'm fine with any list, as long as the change gets reviewed :) Regards, Volker On Mon, Aug 8, 2016 at 10:39 PM, Alexander Scherbatiy wrote: > The fix should be reviewed on the awt-dev alias. > > > On 08/08/16 22:36, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following trivial fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8163408/ >> https://bugs.openjdk.java.net/browse/JDK-8163408 >> >> I'd like to push this directly to jdk9/dev if possible because the >> problem has already spread across all the other repos and I'd like to >> fix it as fast as possible in all repos. >> >> The fix for "8149115: [hidpi] Linux: display-wise scaling factor >> should probably be taken into account" changed the prototype for >> getNativeScaleFactor() in systemScale.h from: >> >> int getNativeScaleFactor(); >> >> to >> >> double getNativeScaleFactor(); >> >> But forgot to add the "char*" parameter to the signature which is >> required by the implementation in systemScale.c (and the various call >> sites): >> >> double getNativeScaleFactor(char *output_name) { >> >> This leads to the following waring/error: >> >> >> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c: >> In function ?Ja >> va_sun_awt_X11GraphicsDevice_getNativeScaleFactor?: >> >> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:2185:5: >> error: c >> all to function ?getNativeScaleFactor? without a real prototype >> [-Werror=unprototyped-calls] >> double scale = getNativeScaleFactor(name); >> ^ >> In file included from >> >> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Graphics >> Env.c:46:0: >> >> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h:29:8: >> note: ? >> getNativeScaleFactor? was declared here >> double getNativeScaleFactor(); >> ^ >> cc1: all warnings being treated as errors >> >> If we fix that we will get: >> >> >> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >> In function ?S >> plashGetScaledImageName?: >> >> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:809:5: >> error: t >> oo few arguments to function ?getNativeScaleFactor? >> *scaleFactor = getNativeScaleFactor(); >> ^ >> >> I observed these warnings/errors with 4.8.5 and it is a miracle for me >> why newer versions of GCC (apparently 4.9.2 which seems to be Oracles >> officially supported compiler according to >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) >> or gcc 5.4.0 whiohc I've tried on Ubuntu 16.04 don't detect this >> problem? >> >> Thank you and best regards, >> Volker > > From Sergey.Bylokhov at oracle.com Tue Aug 9 14:34:35 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 9 Aug 2016 17:34:35 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> Message-ID: Hi, Anton. Is it possible to call updateFocusableWindowState() from the initializeImpl()? initializeImpl() is a place where we init the peer before make it visible, but after constructor of the peer was called. On 29.06.16 21:04, Anton Tarasov wrote: > Hello, > > Please review the fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8160570 > webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 > > The problem is that a modal dialog can skip the activation/focus events > on OSX. > The fix is to cache the focusability state of the Window peer earlier, > in its ctor. > Please find more details in JIRA. > > Thanks, > Anton. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 9 16:11:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 9 Aug 2016 19:11:54 +0300 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> Message-ID: <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> Hi, Manajit. - Its seems that the test creates the Swing components on non-EDT. - The instructions are a little bit misleading, because popup will be shown even when the test is passed. - When I run the test on the current client ws, it is passed. Can you please double check that the test fails before the fix. On 01.08.16 12:35, Manajit Halder wrote: > Hi All, > > Kindly review the fix for JDK9. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156099 > > Webrev: > http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ > > Issue: > [macosx] Drag and drop of link from web browser, DataFlavor types > application/x-java-url and text/uri-list, getTransferData returns null > > Cause: > This issue is a regression of issue > https://bugs.openjdk.java.net/browse/JDK-8136763. > While adding fix to 8136763 code was modified to handle coping of > multiple files but proper distinction was not added between bytes > containing files and urls. > > Fix: > Fixed by comparing format of the bytes received for dataflavor > "mimetype=text/uri-list". > Fixed by distinguishing between bytes containing files and urls. In both > cases the dataflavor contains same ?mimetype=text/uri-list?, but the > format is different. > Format CF_FILE is only used in case of bytes containing files. > > Regards, > Manajit -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Aug 10 14:31:30 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Aug 2016 17:31:30 +0300 Subject: RFR(XXS): 8163408: Fix wrong prototype of getNativeScaleFactor() in systemScale.h In-Reply-To: References: Message-ID: Looks fine. On 09.08.16 10:37, Volker Simonis wrote: > I've just send the RFR to the same list on which the offending change > 8149115 has been reviewed. > > But I'm fine with any list, as long as the change gets reviewed :) > > Regards, > Volker > > On Mon, Aug 8, 2016 at 10:39 PM, Alexander Scherbatiy > wrote: >> The fix should be reviewed on the awt-dev alias. >> >> >> On 08/08/16 22:36, Volker Simonis wrote: >>> >>> Hi, >>> >>> can I please have a review for the following trivial fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8163408/ >>> https://bugs.openjdk.java.net/browse/JDK-8163408 >>> >>> I'd like to push this directly to jdk9/dev if possible because the >>> problem has already spread across all the other repos and I'd like to >>> fix it as fast as possible in all repos. >>> >>> The fix for "8149115: [hidpi] Linux: display-wise scaling factor >>> should probably be taken into account" changed the prototype for >>> getNativeScaleFactor() in systemScale.h from: >>> >>> int getNativeScaleFactor(); >>> >>> to >>> >>> double getNativeScaleFactor(); >>> >>> But forgot to add the "char*" parameter to the signature which is >>> required by the implementation in systemScale.c (and the various call >>> sites): >>> >>> double getNativeScaleFactor(char *output_name) { >>> >>> This leads to the following waring/error: >>> >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c: >>> In function ?Ja >>> va_sun_awt_X11GraphicsDevice_getNativeScaleFactor?: >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:2185:5: >>> error: c >>> all to function ?getNativeScaleFactor? without a real prototype >>> [-Werror=unprototyped-calls] >>> double scale = getNativeScaleFactor(name); >>> ^ >>> In file included from >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Graphics >>> Env.c:46:0: >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h:29:8: >>> note: ? >>> getNativeScaleFactor? was declared here >>> double getNativeScaleFactor(); >>> ^ >>> cc1: all warnings being treated as errors >>> >>> If we fix that we will get: >>> >>> >>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >>> In function ?S >>> plashGetScaledImageName?: >>> >>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:809:5: >>> error: t >>> oo few arguments to function ?getNativeScaleFactor? >>> *scaleFactor = getNativeScaleFactor(); >>> ^ >>> >>> I observed these warnings/errors with 4.8.5 and it is a miracle for me >>> why newer versions of GCC (apparently 4.9.2 which seems to be Oracles >>> officially supported compiler according to >>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) >>> or gcc 5.4.0 whiohc I've tried on Ubuntu 16.04 don't detect this >>> problem? >>> >>> Thank you and best regards, >>> Volker >> >> -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Wed Aug 10 14:38:51 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Wed, 10 Aug 2016 17:38:51 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> Message-ID: <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> Hi Sergey, all, There's an update test: http://cr.openjdk.java.net/~mcherkas/8160696/webrev.01/ Thanks, Mikhail. On 05.08.2016 21:17, Sergey Bylokhov wrote: > Hi, Mikhail. > Please update the header of the test and rename it to some meaningful > name. Also note that the frames should be disposed at the end of the > test. > > On 05.08.16 19:19, Mikhail Cherkasov wrote: >> Hi all, >> >> Please review a fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8160696 >> webrev: >> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.00/ >> >> Java throws exception: "IllegalArgumentException: adding a component to >> a container on a different GraphicsDevice" if you move a Java >> application to different monitor and >> add a Component to a Container on another graphics device, without >> explicitly >> removing the Component from its previous parent. >> >> Moving components between containers works fine if you remove the >> component >> manually before moving it to other container, however this is already >> done in addImpl >> method, so I've just put a removing the component from old parent before >> " checkGD". >> It works fine now and I'm not sure whether we need "checkGD" at all, >> however I leave it >> there just in case. >> >> Thanks, >> Mikhail. > > From alexandr.scherbatiy at oracle.com Wed Aug 10 14:40:25 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 10 Aug 2016 17:40:25 +0300 Subject: RFR(XXS): 8163408: Fix wrong prototype of getNativeScaleFactor() in systemScale.h In-Reply-To: References: Message-ID: Calling getNativeScaleFactor(NULL) leads that "com.ubuntu.user-interface" "scale-factor" and "com.canonical.Unity.Interface" "text-scale-factor" properties are just skipped in getDesktopScale(char *output_name) method from systemScale.c file. Should there be provided some default output screen name? I am not sure that the fix can be pushed to the jdk9/dev repository. The usual practice is to always push it to the jdk9/client first. Thanks, Alexandr. On 8/9/2016 10:37 AM, Volker Simonis wrote: > I've just send the RFR to the same list on which the offending change > 8149115 has been reviewed. > > But I'm fine with any list, as long as the change gets reviewed :) > > Regards, > Volker > > On Mon, Aug 8, 2016 at 10:39 PM, Alexander Scherbatiy > wrote: >> The fix should be reviewed on the awt-dev alias. >> >> >> On 08/08/16 22:36, Volker Simonis wrote: >>> Hi, >>> >>> can I please have a review for the following trivial fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8163408/ >>> https://bugs.openjdk.java.net/browse/JDK-8163408 >>> >>> I'd like to push this directly to jdk9/dev if possible because the >>> problem has already spread across all the other repos and I'd like to >>> fix it as fast as possible in all repos. >>> >>> The fix for "8149115: [hidpi] Linux: display-wise scaling factor >>> should probably be taken into account" changed the prototype for >>> getNativeScaleFactor() in systemScale.h from: >>> >>> int getNativeScaleFactor(); >>> >>> to >>> >>> double getNativeScaleFactor(); >>> >>> But forgot to add the "char*" parameter to the signature which is >>> required by the implementation in systemScale.c (and the various call >>> sites): >>> >>> double getNativeScaleFactor(char *output_name) { >>> >>> This leads to the following waring/error: >>> >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c: >>> In function ?Ja >>> va_sun_awt_X11GraphicsDevice_getNativeScaleFactor?: >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:2185:5: >>> error: c >>> all to function ?getNativeScaleFactor? without a real prototype >>> [-Werror=unprototyped-calls] >>> double scale = getNativeScaleFactor(name); >>> ^ >>> In file included from >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Graphics >>> Env.c:46:0: >>> >>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h:29:8: >>> note: ? >>> getNativeScaleFactor? was declared here >>> double getNativeScaleFactor(); >>> ^ >>> cc1: all warnings being treated as errors >>> >>> If we fix that we will get: >>> >>> >>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >>> In function ?S >>> plashGetScaledImageName?: >>> >>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:809:5: >>> error: t >>> oo few arguments to function ?getNativeScaleFactor? >>> *scaleFactor = getNativeScaleFactor(); >>> ^ >>> >>> I observed these warnings/errors with 4.8.5 and it is a miracle for me >>> why newer versions of GCC (apparently 4.9.2 which seems to be Oracles >>> officially supported compiler according to >>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) >>> or gcc 5.4.0 whiohc I've tried on Ubuntu 16.04 don't detect this >>> problem? >>> >>> Thank you and best regards, >>> Volker >> From Sergey.Bylokhov at oracle.com Wed Aug 10 14:49:18 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Aug 2016 17:49:18 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> Message-ID: How this test will fail before the fix? since the canvas is added only once "frms[0].add(canvas);" It seems that it should be added to the first and then to the second frame, no? On 10.08.16 17:38, Mikhail Cherkasov wrote: > Hi Sergey, all, > > There's an update test: > http://cr.openjdk.java.net/~mcherkas/8160696/webrev.01/ > > Thanks, > Mikhail. > > On 05.08.2016 21:17, Sergey Bylokhov wrote: >> Hi, Mikhail. >> Please update the header of the test and rename it to some meaningful >> name. Also note that the frames should be disposed at the end of the >> test. >> >> On 05.08.16 19:19, Mikhail Cherkasov wrote: >>> Hi all, >>> >>> Please review a fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8160696 >>> webrev: >>> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.00/ >>> >>> Java throws exception: "IllegalArgumentException: adding a component to >>> a container on a different GraphicsDevice" if you move a Java >>> application to different monitor and >>> add a Component to a Container on another graphics device, without >>> explicitly >>> removing the Component from its previous parent. >>> >>> Moving components between containers works fine if you remove the >>> component >>> manually before moving it to other container, however this is already >>> done in addImpl >>> method, so I've just put a removing the component from old parent before >>> " checkGD". >>> It works fine now and I'm not sure whether we need "checkGD" at all, >>> however I leave it >>> there just in case. >>> >>> Thanks, >>> Mikhail. >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Aug 10 14:54:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Aug 2016 17:54:56 +0300 Subject: [9] Review request for 8149115: [hidpi] Linux: display-wise scaling factor should probably be taken into account In-Reply-To: References: <8f97e1c2-353f-b7f8-c691-f7986284381b@oracle.com> <72f7290d-6cea-c074-4fab-5294d44b4736@oracle.com> <9bda5602-3f9b-3931-026d-642526a1f3ad@oracle.com> <6689b827-d725-1a0a-a7d1-13804404e07c@oracle.com> <9497e7e7-bf41-6afe-3867-d8c8059bbe18@oracle.com> <61f453dc-8ef4-9ebe-9fc2-a70718d3bcf9@oracle.com> <5184aba8-2dfc-73af-be49-7e0bcb87ea1a@oracle.com> <0ea4b416-9c0d-5e16-f1aa-049d847a3956@oracle.com> <062d3b41-7ece-d9b6-ab7d-701d008bad2d@oracle.com> Message-ID: <6be05fed-3f7f-5ff1-5615-85ca71ca724d@oracle.com> It is unclear why gdk_scale is applied on top of native scale? So if both GDK_SCALE and scale-factor are set, then we will get the multiply of them, is it expected? On 08.07.16 13:27, Alexander Zvegintsev wrote: > +1 > > > On 7/8/16 10:37 AM, Alexandr Scherbatiy wrote: >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/8/2016 9:25 AM, Semyon Sadetsky wrote: >>> I have changed variables declaration style in systemScale.c, because >>> it produced warnings in Solaris build. >>> >>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.03/ >>> >>> --Semyon >>> >>> On 7/7/2016 9:57 AM, Alexandr Scherbatiy wrote: >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/6/2016 11:46 PM, Alexander Zvegintsev wrote: >>>>> Still looks good. >>>>> >>>>> -- >>>>> Thanks, >>>>> Alexander. >>>>> >>>>> On 06.07.2016 21:42, Semyon Sadetsky wrote: >>>>>> Thanks, Alexander. Please see the updated webrev >>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.02/ >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 7/6/2016 9:03 PM, Alexander Zvegintsev wrote: >>>>>>> The fix looks good to me. >>>>>>> >>>>>>> Just a minor comment: multiple NULL checks in get_schema_value >>>>>>> could be wrapped in CHECK_NULL_RETURN macro, e.g.: >>>>>>> >>>>>>> CHECH_NULL_RETURN(fp_g_settings_schema_has_key >>>>>>> = dlsym(lib_handle, "g_settings_schema_has_key"), NULL); >>>>>>> CHECH_NULL_RETURN(fp_g_settings_new_full >>>>>>> = dlsym(lib_handle, "g_settings_new_full"), NULL); >>>>>>> >>>>>>> >>>>>>> On 7/6/16 5:27 PM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> The fix looks good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 7/6/2016 4:46 PM, Semyon Sadetsky wrote: >>>>>>>>> On 7/6/2016 12:26 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>>> On 7/5/2016 9:59 PM, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149115 >>>>>>>>>>> >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Currently the hidpi support on linux only reads GDK_SCALE >>>>>>>>>>> environment variable to get the native scale. Although, >>>>>>>>>>> Gnome3 and Unity DE use own settings to control the interface >>>>>>>>>>> scale. The fix adds possibility to read those settings to >>>>>>>>>>> make java apps hidpi scale similar to the native apps. >>>>>>>>>>> Currently only integer scale values are supported. If native >>>>>>>>>>> scale is not an integer value it is rounded to the nearest >>>>>>>>>>> integer. >>>>>>>>>> systemScale.c >>>>>>>>>> Should the while loop have a break statement in the >>>>>>>>>> getDesktopScale(...) method? >>>>>>>>> That's make sense. Please look at the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.01/ >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Wed Aug 10 15:07:07 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Wed, 10 Aug 2016 18:07:07 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> Message-ID: <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> Right, it addes it to other frame later: frms[1].add(canvas); On 10.08.2016 17:49, Sergey Bylokhov wrote: > How this test will fail before the fix? since the canvas is added only > once "frms[0].add(canvas);" It seems that it should be added to the > first and then to the second frame, no? > > On 10.08.16 17:38, Mikhail Cherkasov wrote: >> Hi Sergey, all, >> >> There's an update test: >> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.01/ >> >> Thanks, >> Mikhail. >> >> On 05.08.2016 21:17, Sergey Bylokhov wrote: >>> Hi, Mikhail. >>> Please update the header of the test and rename it to some meaningful >>> name. Also note that the frames should be disposed at the end of the >>> test. >>> >>> On 05.08.16 19:19, Mikhail Cherkasov wrote: >>>> Hi all, >>>> >>>> Please review a fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8160696 >>>> webrev: >>>> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.00/ >>>> >>>> Java throws exception: "IllegalArgumentException: adding a >>>> component to >>>> a container on a different GraphicsDevice" if you move a Java >>>> application to different monitor and >>>> add a Component to a Container on another graphics device, without >>>> explicitly >>>> removing the Component from its previous parent. >>>> >>>> Moving components between containers works fine if you remove the >>>> component >>>> manually before moving it to other container, however this is already >>>> done in addImpl >>>> method, so I've just put a removing the component from old parent >>>> before >>>> " checkGD". >>>> It works fine now and I'm not sure whether we need "checkGD" at all, >>>> however I leave it >>>> there just in case. >>>> >>>> Thanks, >>>> Mikhail. >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Aug 10 15:24:03 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 10 Aug 2016 18:24:03 +0300 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: References: Message-ID: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ > > > Issue: Currently different naming conventions are used for Hidpi image > on different platforms. > > With this change the names will be unified across all platforms. > > For a unscaled image image.ext following naming convention will be > followed. > > Unscaled name: image.ext > > Supported Scaled Names: > > If screen scale is integer number e.g. 2: image at 2x.ext > > > If screen scale is float value like 1.25: image at 125pct.ext > > The fix should be reviewed on the awt-dev alias. + if(*scaleFactor - (int)*scaleFactor < 0.000001) Should there be so high precision there? Could only percent values be compared like if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; It looks like the splash coordinates and sizes are rescaled in different places. Is it possible to do that in the same place? May be in java_awt_SplashScreen.c file getBounds() function? Thanks, Alexandr. > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Aug 10 15:32:09 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Aug 2016 18:32:09 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> Message-ID: On 10.08.16 18:07, Mikhail Cherkasov wrote: > Right, it addes it to other frame later: > > frms[1].add(canvas); Ouch I thought it was dispose of the frame. This fine then, but these frames should be disposed at the end of the test. > > > On 10.08.2016 17:49, Sergey Bylokhov wrote: >> How this test will fail before the fix? since the canvas is added only >> once "frms[0].add(canvas);" It seems that it should be added to the >> first and then to the second frame, no? >> >> On 10.08.16 17:38, Mikhail Cherkasov wrote: >>> Hi Sergey, all, >>> >>> There's an update test: >>> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.01/ >>> >>> Thanks, >>> Mikhail. >>> >>> On 05.08.2016 21:17, Sergey Bylokhov wrote: >>>> Hi, Mikhail. >>>> Please update the header of the test and rename it to some meaningful >>>> name. Also note that the frames should be disposed at the end of the >>>> test. >>>> >>>> On 05.08.16 19:19, Mikhail Cherkasov wrote: >>>>> Hi all, >>>>> >>>>> Please review a fix for the following bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8160696 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.00/ >>>>> >>>>> Java throws exception: "IllegalArgumentException: adding a >>>>> component to >>>>> a container on a different GraphicsDevice" if you move a Java >>>>> application to different monitor and >>>>> add a Component to a Container on another graphics device, without >>>>> explicitly >>>>> removing the Component from its previous parent. >>>>> >>>>> Moving components between containers works fine if you remove the >>>>> component >>>>> manually before moving it to other container, however this is already >>>>> done in addImpl >>>>> method, so I've just put a removing the component from old parent >>>>> before >>>>> " checkGD". >>>>> It works fine now and I'm not sure whether we need "checkGD" at all, >>>>> however I leave it >>>>> there just in case. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>> >>>> >>> >> >> > -- Best regards, Sergey. From mikhail.cherkasov at oracle.com Wed Aug 10 15:45:27 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Wed, 10 Aug 2016 18:45:27 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> Message-ID: <18ad832e-2f3c-f9d6-39ed-dd28b2960e2d@oracle.com> Oops, sorry, I missed this. On 10.08.2016 18:32, Sergey Bylokhov wrote: > but these frames should be disposed From mikhail.cherkasov at oracle.com Wed Aug 10 15:55:46 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Wed, 10 Aug 2016 18:55:46 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> Message-ID: <9bf60889-b649-1b80-2574-424df8dc89db@oracle.com> Now everything is in place: http://cr.openjdk.java.net/~mcherkas/8160696/webrev.02/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html On 10.08.2016 18:32, Sergey Bylokhov wrote: > but these frames should be disposed From volker.simonis at gmail.com Wed Aug 10 16:43:03 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Aug 2016 18:43:03 +0200 Subject: RFR(XXS): 8163408: Fix wrong prototype of getNativeScaleFactor() in systemScale.h In-Reply-To: References: Message-ID: Thanks Sergey! Finally I also found out why I couldn't see this problem with other compilers. -Wunprototyped-calls seems to be an undocumented Suse extension which is only available on SLES/OpenSuse GCC builds. Somehow it never made its way into upstream GCC. The only reference I could find is the following mail thread on the GCC mailing list: https://gcc.gnu.org/ml/gcc-patches/2013-04/threads.html#00363 Regards, Volker On Wed, Aug 10, 2016 at 4:31 PM, Sergey Bylokhov wrote: > Looks fine. > > > On 09.08.16 10:37, Volker Simonis wrote: >> >> I've just send the RFR to the same list on which the offending change >> 8149115 has been reviewed. >> >> But I'm fine with any list, as long as the change gets reviewed :) >> >> Regards, >> Volker >> >> On Mon, Aug 8, 2016 at 10:39 PM, Alexander Scherbatiy >> wrote: >>> >>> The fix should be reviewed on the awt-dev alias. >>> >>> >>> On 08/08/16 22:36, Volker Simonis wrote: >>>> >>>> >>>> Hi, >>>> >>>> can I please have a review for the following trivial fix: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8163408/ >>>> https://bugs.openjdk.java.net/browse/JDK-8163408 >>>> >>>> I'd like to push this directly to jdk9/dev if possible because the >>>> problem has already spread across all the other repos and I'd like to >>>> fix it as fast as possible in all repos. >>>> >>>> The fix for "8149115: [hidpi] Linux: display-wise scaling factor >>>> should probably be taken into account" changed the prototype for >>>> getNativeScaleFactor() in systemScale.h from: >>>> >>>> int getNativeScaleFactor(); >>>> >>>> to >>>> >>>> double getNativeScaleFactor(); >>>> >>>> But forgot to add the "char*" parameter to the signature which is >>>> required by the implementation in systemScale.c (and the various call >>>> sites): >>>> >>>> double getNativeScaleFactor(char *output_name) { >>>> >>>> This leads to the following waring/error: >>>> >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c: >>>> In function ?Ja >>>> va_sun_awt_X11GraphicsDevice_getNativeScaleFactor?: >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:2185:5: >>>> error: c >>>> all to function ?getNativeScaleFactor? without a real prototype >>>> [-Werror=unprototyped-calls] >>>> double scale = getNativeScaleFactor(name); >>>> ^ >>>> In file included from >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Graphics >>>> Env.c:46:0: >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h:29:8: >>>> note: ? >>>> getNativeScaleFactor? was declared here >>>> double getNativeScaleFactor(); >>>> ^ >>>> cc1: all warnings being treated as errors >>>> >>>> If we fix that we will get: >>>> >>>> >>>> >>>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >>>> In function ?S >>>> plashGetScaledImageName?: >>>> >>>> >>>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:809:5: >>>> error: t >>>> oo few arguments to function ?getNativeScaleFactor? >>>> *scaleFactor = getNativeScaleFactor(); >>>> ^ >>>> >>>> I observed these warnings/errors with 4.8.5 and it is a miracle for me >>>> why newer versions of GCC (apparently 4.9.2 which seems to be Oracles >>>> officially supported compiler according to >>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) >>>> or gcc 5.4.0 whiohc I've tried on Ubuntu 16.04 don't detect this >>>> problem? >>>> >>>> Thank you and best regards, >>>> Volker >>> >>> >>> > > > -- > Best regards, Sergey. From volker.simonis at gmail.com Wed Aug 10 16:51:50 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Aug 2016 18:51:50 +0200 Subject: RFR(XXS): 8163408: Fix wrong prototype of getNativeScaleFactor() in systemScale.h In-Reply-To: References: Message-ID: Hi Alexandr, sorry, but I saw your answer too late. I just noticed Sergeys review and pushed the fix jdk9/dev already. On Wed, Aug 10, 2016 at 4:40 PM, Alexandr Scherbatiy wrote: > > Calling getNativeScaleFactor(NULL) leads that "com.ubuntu.user-interface" > "scale-factor" and "com.canonical.Unity.Interface" "text-scale-factor" > properties are just skipped in getDesktopScale(char *output_name) method > from systemScale.c file. Should there be provided some default output screen > name? > I'm not sure what the default screen name should be? Anyway, I think the behavior without the fix was simply undefined until now as we've provided no argument at all. It could even lead to a crash if the first argument register happened to point to some unaccessible memory. If there's a simple default screen name, I agree that we should provide that instead of NULL. Regards, Volker > I am not sure that the fix can be pushed to the jdk9/dev repository. The > usual practice is to always push it to the jdk9/client first. > > Thanks, > Alexandr. > > > On 8/9/2016 10:37 AM, Volker Simonis wrote: >> >> I've just send the RFR to the same list on which the offending change >> 8149115 has been reviewed. >> >> But I'm fine with any list, as long as the change gets reviewed :) >> >> Regards, >> Volker >> >> On Mon, Aug 8, 2016 at 10:39 PM, Alexander Scherbatiy >> wrote: >>> >>> The fix should be reviewed on the awt-dev alias. >>> >>> >>> On 08/08/16 22:36, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> can I please have a review for the following trivial fix: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8163408/ >>>> https://bugs.openjdk.java.net/browse/JDK-8163408 >>>> >>>> I'd like to push this directly to jdk9/dev if possible because the >>>> problem has already spread across all the other repos and I'd like to >>>> fix it as fast as possible in all repos. >>>> >>>> The fix for "8149115: [hidpi] Linux: display-wise scaling factor >>>> should probably be taken into account" changed the prototype for >>>> getNativeScaleFactor() in systemScale.h from: >>>> >>>> int getNativeScaleFactor(); >>>> >>>> to >>>> >>>> double getNativeScaleFactor(); >>>> >>>> But forgot to add the "char*" parameter to the signature which is >>>> required by the implementation in systemScale.c (and the various call >>>> sites): >>>> >>>> double getNativeScaleFactor(char *output_name) { >>>> >>>> This leads to the following waring/error: >>>> >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c: >>>> In function ?Ja >>>> va_sun_awt_X11GraphicsDevice_getNativeScaleFactor?: >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:2185:5: >>>> error: c >>>> all to function ?getNativeScaleFactor? without a real prototype >>>> [-Werror=unprototyped-calls] >>>> double scale = getNativeScaleFactor(name); >>>> ^ >>>> In file included from >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Graphics >>>> Env.c:46:0: >>>> >>>> >>>> /OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h:29:8: >>>> note: ? >>>> getNativeScaleFactor? was declared here >>>> double getNativeScaleFactor(); >>>> ^ >>>> cc1: all warnings being treated as errors >>>> >>>> If we fix that we will get: >>>> >>>> >>>> >>>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >>>> In function ?S >>>> plashGetScaledImageName?: >>>> >>>> >>>> /usr/work/d046063/OpenJDK/jdk9-hs-comp-s390x/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:809:5: >>>> error: t >>>> oo few arguments to function ?getNativeScaleFactor? >>>> *scaleFactor = getNativeScaleFactor(); >>>> ^ >>>> >>>> I observed these warnings/errors with 4.8.5 and it is a miracle for me >>>> why newer versions of GCC (apparently 4.9.2 which seems to be Oracles >>>> officially supported compiler according to >>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) >>>> or gcc 5.4.0 whiohc I've tried on Ubuntu 16.04 don't detect this >>>> problem? >>>> >>>> Thank you and best regards, >>>> Volker >>> >>> > From ambarish.rapte at oracle.com Thu Aug 11 06:07:05 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 10 Aug 2016 23:07:05 -0700 (PDT) Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: <9bf60889-b649-1b80-2574-424df8dc89db@oracle.com> References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> <9bf60889-b649-1b80-2574-424df8dc89db@oracle.com> Message-ID: <61ca13e9-40ea-4153-9e92-dd012965d64e@default> Hi Mikhail, Here are few suggestions, Please add @key heedful jtreg tag. Please correct line 74. Use specific class imports instead of package import. Regards, Ambarish -----Original Message----- From: Mikhail Cherkasov Sent: Wednesday, August 10, 2016 9:26 PM To: Sergey Bylokhov; awt-dev at openjdk.java.net Subject: Re: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice Now everything is in place: http://cr.openjdk.java.net/~mcherkas/8160696/webrev.02/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html On 10.08.2016 18:32, Sergey Bylokhov wrote: > but these frames should be disposed From alexandr.scherbatiy at oracle.com Thu Aug 11 09:13:48 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 11 Aug 2016 13:13:48 +0400 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> Message-ID: <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> On 10/08/16 19:24, Alexandr Scherbatiy wrote: > > On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > >> Hello All, >> >> Please review the following webrev. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 >> >> Webrev: http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ >> >> >> Issue: Currently different naming conventions are used for Hidpi >> image on different platforms. >> >> With this change the names will be unified across all platforms. >> >> For a unscaled image image.ext following naming convention will be >> followed. >> >> Unscaled name: image.ext >> >> Supported Scaled Names: >> >> If screen scale is integer number e.g. 2: image at 2x.ext >> >> >> If screen scale is float value like 1.25: image at 125pct.ext >> >> > > The fix should be reviewed on the awt-dev alias. > > + if(*scaleFactor - (int)*scaleFactor < 0.000001) > > Should there be so high precision there? Could only percent values be > compared like > if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) > > > + //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > It looks like the splash coordinates and sizes are rescaled in > different places. Is it possible to do that in the same place? May be > in java_awt_SplashScreen.c file getBounds() function? src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c *scaleFactor = getNativeScaleFactor(); Could you also include the change which requires to add some default output screen name to the getNativeScaleFactor() function on Linux. There is the discussion about that: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html Thanks, Alexandr. > > Thanks, > Alexandr. > >> Regards, >> >> Rajeev Chamyal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Thu Aug 11 16:57:37 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Thu, 11 Aug 2016 19:57:37 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: <61ca13e9-40ea-4153-9e92-dd012965d64e@default> References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> <9bf60889-b649-1b80-2574-424df8dc89db@oracle.com> <61ca13e9-40ea-4153-9e92-dd012965d64e@default> Message-ID: Ambarish, thank you for comments, please review a new version: http://cr.openjdk.java.net/~mcherkas/8160696/webrev.03/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html On 11.08.2016 9:07, Ambarish Rapte wrote: > Hi Mikhail, > Here are few suggestions, > Please add @key heedful jtreg tag. > Please correct line 74. > Use specific class imports instead of package import. > > Regards, > Ambarish > > -----Original Message----- > From: Mikhail Cherkasov > Sent: Wednesday, August 10, 2016 9:26 PM > To: Sergey Bylokhov; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice > > Now everything is in place: > http://cr.openjdk.java.net/~mcherkas/8160696/webrev.02/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html > > > On 10.08.2016 18:32, Sergey Bylokhov wrote: >> but these frames should be disposed From Sergey.Bylokhov at oracle.com Fri Aug 12 13:04:48 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 16:04:48 +0300 Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> <9bf60889-b649-1b80-2574-424df8dc89db@oracle.com> <61ca13e9-40ea-4153-9e92-dd012965d64e@default> Message-ID: looks fine to me. On 11.08.16 19:57, Mikhail Cherkasov wrote: > Ambarish, thank you for comments, please review a new version: > > http://cr.openjdk.java.net/~mcherkas/8160696/webrev.03/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html > > > > On 11.08.2016 9:07, Ambarish Rapte wrote: >> Hi Mikhail, >> Here are few suggestions, >> Please add @key heedful jtreg tag. >> Please correct line 74. >> Use specific class imports instead of package import. >> >> Regards, >> Ambarish >> >> -----Original Message----- >> From: Mikhail Cherkasov >> Sent: Wednesday, August 10, 2016 9:26 PM >> To: Sergey Bylokhov; awt-dev at openjdk.java.net >> Subject: Re: Review Request for 8160696: >> IllegalArgumentException: adding a component to a container on a >> different GraphicsDevice >> >> Now everything is in place: >> http://cr.openjdk.java.net/~mcherkas/8160696/webrev.02/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html >> >> >> >> On 10.08.2016 18:32, Sergey Bylokhov wrote: >>> but these frames should be disposed > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Fri Aug 12 13:06:24 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Fri, 12 Aug 2016 06:06:24 -0700 (PDT) Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> Message-ID: Hi Alexandr and Sergey, Please review the updated patch. http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Sun Aug 14 19:47:06 2016 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 15 Aug 2016 01:17:06 +0530 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> Message-ID: <332AFBFB-DC90-48EC-99E5-C9EF1551BF72@oracle.com> Hi Sergey, Thank you for your review comments. I have modified the code as per your first two comments. For the last comment the fix was tested with JDK versions b123, b124, b125, b127 and b130 and the test failed with the popup message. Please review the modified review. http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ Thanks, Manajit > On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov wrote: > > Hi, Manajit. > - Its seems that the test creates the Swing components on non-EDT. > - The instructions are a little bit misleading, because popup will be shown even when the test is passed. > - When I run the test on the current client ws, it is passed. Can you please double check that the test fails before the fix. > > On 01.08.16 12:35, Manajit Halder wrote: >> Hi All, >> >> Kindly review the fix for JDK9. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8156099 >> >> Webrev: >> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >> >> Issue: >> [macosx] Drag and drop of link from web browser, DataFlavor types >> application/x-java-url and text/uri-list, getTransferData returns null >> >> Cause: >> This issue is a regression of issue >> https://bugs.openjdk.java.net/browse/JDK-8136763. >> While adding fix to 8136763 code was modified to handle coping of >> multiple files but proper distinction was not added between bytes >> containing files and urls. >> >> Fix: >> Fixed by comparing format of the bytes received for dataflavor >> "mimetype=text/uri-list". >> Fixed by distinguishing between bytes containing files and urls. In both >> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >> format is different. >> Format CF_FILE is only used in case of bytes containing files. >> >> Regards, >> Manajit > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Sun Aug 14 20:47:25 2016 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 15 Aug 2016 02:17:25 +0530 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> Message-ID: Hi Sergey, Thank you for your review comments. I have modified the code as per your first two comments. For the last comment the fix was tested with the following version and was found to be failed with the failure popup message: JDK b127 JDK b130 Please review the modified review. http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ Thanks, Manajit > On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov > wrote: > > Hi, Manajit. > - Its seems that the test creates the Swing components on non-EDT. > - The instructions are a little bit misleading, because popup will be shown even when the test is passed. > - When I run the test on the current client ws, it is passed. Can you please double check that the test fails before the fix. > > On 01.08.16 12:35, Manajit Halder wrote: >> Hi All, >> >> Kindly review the fix for JDK9. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8156099 >> >> Webrev: >> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >> >> Issue: >> [macosx] Drag and drop of link from web browser, DataFlavor types >> application/x-java-url and text/uri-list, getTransferData returns null >> >> Cause: >> This issue is a regression of issue >> https://bugs.openjdk.java.net/browse/JDK-8136763. >> While adding fix to 8136763 code was modified to handle coping of >> multiple files but proper distinction was not added between bytes >> containing files and urls. >> >> Fix: >> Fixed by comparing format of the bytes received for dataflavor >> "mimetype=text/uri-list". >> Fixed by distinguishing between bytes containing files and urls. In both >> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >> format is different. >> Format CF_FILE is only used in case of bytes containing files. >> >> Regards, >> Manajit > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Sun Aug 14 20:50:28 2016 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 15 Aug 2016 02:20:28 +0530 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> Message-ID: Hi Sergey, Thank you for your review comments. I have modified the code as per your first two comments. For the last comment the fix was tested with JDK versions b123, b124, b125, b127 and b130 and the test failed with the popup message. Please review the modified review. http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ Thanks, Manajit > On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov > wrote: > > Hi, Manajit. > - Its seems that the test creates the Swing components on non-EDT. > - The instructions are a little bit misleading, because popup will be shown even when the test is passed. > - When I run the test on the current client ws, it is passed. Can you please double check that the test fails before the fix. > > On 01.08.16 12:35, Manajit Halder wrote: >> Hi All, >> >> Kindly review the fix for JDK9. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8156099 >> >> Webrev: >> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >> >> Issue: >> [macosx] Drag and drop of link from web browser, DataFlavor types >> application/x-java-url and text/uri-list, getTransferData returns null >> >> Cause: >> This issue is a regression of issue >> https://bugs.openjdk.java.net/browse/JDK-8136763 . >> While adding fix to 8136763 code was modified to handle coping of >> multiple files but proper distinction was not added between bytes >> containing files and urls. >> >> Fix: >> Fixed by comparing format of the bytes received for dataflavor >> "mimetype=text/uri-list". >> Fixed by distinguishing between bytes containing files and urls. In both >> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >> format is different. >> Format CF_FILE is only used in case of bytes containing files. >> >> Regards, >> Manajit > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.rapte at oracle.com Mon Aug 15 05:31:25 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Sun, 14 Aug 2016 22:31:25 -0700 (PDT) Subject: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice In-Reply-To: References: <0e77d110-e861-3e97-1ef8-c0537e4a8294@oracle.com> <87b7f1bb-1836-2d7c-5092-5399583ce480@oracle.com> <8be7cb4a-b2c8-1046-3959-08c5c84651ed@oracle.com> <9bf60889-b649-1b80-2574-424df8dc89db@oracle.com> <61ca13e9-40ea-4153-9e92-dd012965d64e@default> Message-ID: <514404eb-56b4-4026-85db-22fb178c266b@default> Thanks Mikhail, +1 Regards, Ambarish -----Original Message----- From: Mikhail Cherkasov Sent: Thursday, August 11, 2016 10:28 PM To: Ambarish Rapte; Sergey Bylokhov; awt-dev at openjdk.java.net Subject: Re: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice Ambarish, thank you for comments, please review a new version: http://cr.openjdk.java.net/~mcherkas/8160696/webrev.03/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html On 11.08.2016 9:07, Ambarish Rapte wrote: > Hi Mikhail, > Here are few suggestions, > Please add @key heedful jtreg tag. > Please correct line 74. > Use specific class imports instead of package import. > > Regards, > Ambarish > > -----Original Message----- > From: Mikhail Cherkasov > Sent: Wednesday, August 10, 2016 9:26 PM > To: Sergey Bylokhov; awt-dev at openjdk.java.net > Subject: Re: Review Request for 8160696: IllegalArgumentException: adding a component to a container on a different GraphicsDevice > > Now everything is in place: > http://cr.openjdk.java.net/~mcherkas/8160696/webrev.02/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.html > > > On 10.08.2016 18:32, Sergey Bylokhov wrote: >> but these frames should be disposed From dmitry.markov at oracle.com Mon Aug 15 11:08:28 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Mon, 15 Aug 2016 14:08:28 +0300 Subject: [9] Review request for 8163583: [macosx] Press "To Back" button on the Dialog, the Dialog moves behind the Frame Message-ID: <57B1A2AC.4090401@oracle.com> Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8163583 webrev: http://cr.openjdk.java.net/~dmarkov/8163583/webrev.00/ Problem description: If toBack() method is invoked on dialog/frame which has not-null owner, the dialog/frame will be ordered below its owner/parent. Fix: The following methods in AWTWindow.m should be modified: - nativePushNSWindowToBack() add logic to perform a proper ordering for parent/child windows. - sendEvent() add logic to move parent windows to front and make sure that child windows are displayed above their nearest parents when the window is clicked by a mouse. Thanks, Dmitry From dmitry.markov at oracle.com Mon Aug 15 14:57:31 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Mon, 15 Aug 2016 17:57:31 +0300 Subject: [9] Review request for 8163583: [macosx] Press "To Back" button on the Dialog, the Dialog moves behind the Frame In-Reply-To: <57B1A2AC.4090401@oracle.com> References: <57B1A2AC.4090401@oracle.com> Message-ID: <57B1D85B.2010500@oracle.com> Just in case JCK tests passed on the build with fix. Thanks, Dmitry On 15/08/2016 14:08, dmitry markov wrote: > Hello, > > Could you review a fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8163583 > webrev: http://cr.openjdk.java.net/~dmarkov/8163583/webrev.00/ > > Problem description: > If toBack() method is invoked on dialog/frame which has not-null > owner, the dialog/frame will be ordered below its owner/parent. > > Fix: > The following methods in AWTWindow.m should be modified: > - nativePushNSWindowToBack() add logic to perform a proper ordering > for parent/child windows. > - sendEvent() add logic to move parent windows to front and make sure > that child windows are displayed above their nearest parents when the > window is clicked by a mouse. > > Thanks, > Dmitry From Sergey.Bylokhov at oracle.com Mon Aug 15 18:02:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 15 Aug 2016 21:02:24 +0300 Subject: [9] Review request for 8163583: [macosx] Press "To Back" button on the Dialog, the Dialog moves behind the Frame In-Reply-To: <57B1D85B.2010500@oracle.com> References: <57B1A2AC.4090401@oracle.com> <57B1D85B.2010500@oracle.com> Message-ID: Looks fine. On 15.08.16 17:57, dmitry markov wrote: > Just in case JCK tests passed on the build with fix. > > Thanks, > Dmitry > On 15/08/2016 14:08, dmitry markov wrote: >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8163583 >> webrev: http://cr.openjdk.java.net/~dmarkov/8163583/webrev.00/ >> >> Problem description: >> If toBack() method is invoked on dialog/frame which has not-null >> owner, the dialog/frame will be ordered below its owner/parent. >> >> Fix: >> The following methods in AWTWindow.m should be modified: >> - nativePushNSWindowToBack() add logic to perform a proper ordering >> for parent/child windows. >> - sendEvent() add logic to move parent windows to front and make sure >> that child windows are displayed above their nearest parents when the >> window is clicked by a mouse. >> >> Thanks, >> Dmitry > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Tue Aug 16 04:35:19 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 15 Aug 2016 21:35:19 -0700 (PDT) Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> Message-ID: <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Aug 16 05:26:29 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 15 Aug 2016 22:26:29 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> Message-ID: <020c37cc-c9af-4790-a591-29b71b410533@default> Hello Alexandr, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ Updates : 1) Updated the consition as suggested if(*scaleFactor - (int)*scaleFactor < 0.000001) 2) Includes the changes of src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c 3) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; This change is required only for windows and linux. As we use absolute system resolution for centring the splash on screen on these. i.e. if system resolution is 1920 X 1080(i.e. unscaled resolution) on windows and linux we use this for centring the splash on screen. For mac scaled resolution is used directly. Regards, Rajeev Chamyal From: Alexander Scherbatiy Sent: 11 August 2016 14:44 To: Rajeev Chamyal; awt-dev at openjdk.java.net; Philip Race; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention On 10/08/16 19:24, Alexandr Scherbatiy wrote: On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ Issue: Currently different naming conventions are used for Hidpi image on different platforms. With this change the names will be unified across all platforms. For a unscaled image image.ext following naming convention will be followed. Unscaled name: image.ext Supported Scaled Names: If screen scale is integer number e.g. 2: HYPERLINK "mailto:image at 2x.ext"image at 2x.ext If screen scale is float value like 1.25: HYPERLINK "mailto:image at 125pct.ext"image at 125pct.ext The fix should be reviewed on the awt-dev alias. + if(*scaleFactor - (int)*scaleFactor < 0.000001) Should there be so high precision there? Could only percent values be compared like if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; It looks like the splash coordinates and sizes are rescaled in different places. Is it possible to do that in the same place? May be in java_awt_SplashScreen.c file getBounds() function? src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c *scaleFactor = getNativeScaleFactor(); Could you also include the change which requires to add some default output screen name to the getNativeScaleFactor() function on Linux. There is the discussion about that: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html Thanks, Alexandr. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.rapte at oracle.com Tue Aug 16 10:16:57 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 16 Aug 2016 03:16:57 -0700 (PDT) Subject: Review Request for 8160056: TextField.setText breaks the contract of EOL Message-ID: Hi, Please review the change for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8160056 Webrev: http://cr.openjdk.java.net/~arapte/8160056/webrev.00/ Change Description: The TextField is a single line text component. If the input text contains new line characters then the character will be replace by space character. TextField replaces EOL(platform specific) and LF(\n) characters with space character. Information about LF character is not explicitly mentioned in the java doc. Hence adding the missing description. Regards, Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Tue Aug 16 16:20:07 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 16 Aug 2016 19:20:07 +0300 Subject: [9] Review request for 8162840: Desktop. enableSuddenTermination() has no effect Message-ID: <9b9b245b-b428-6de8-a2ed-c0fa29219ba5@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8162840/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8162840 We don't call QuitHandler and using default QuitStrategy if sudden termination is enabled. -- Thanks, Alexander. From Sergey.Bylokhov at oracle.com Tue Aug 16 16:21:50 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 19:21:50 +0300 Subject: [9] Review Request: 8164104 Cleanup of javaclient related mapfiles Message-ID: Hello. Please review cleanup of mapfiles, initially the problem was found here: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html - tabs were replaced by spaces - doubled empty lines removed jprt is ok. Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 Patch can be found at: http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 16 16:22:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 19:22:01 +0300 Subject: [9] Review Request: 8164104 Cleanup of javaclient related mapfiles Message-ID: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> Hello. Please review cleanup of mapfiles, initially the problem was found here: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html - tabs were replaced by spaces - doubled empty lines removed jprt is ok. Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 Patch can be found at: http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 16 16:27:07 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 19:27:07 +0300 Subject: [9] Review request for 8162840: Desktop. enableSuddenTermination() has no effect In-Reply-To: <9b9b245b-b428-6de8-a2ed-c0fa29219ba5@oracle.com> References: <9b9b245b-b428-6de8-a2ed-c0fa29219ba5@oracle.com> Message-ID: <103d7dcb-f901-95f3-5073-d5c93760ee67@oracle.com> Hi, Alexander. Is it possible to create a test for the fix? On 16.08.16 19:20, Alexander Zvegintsev wrote: > Hello, > > > please review the fix > > http://cr.openjdk.java.net/~azvegint/jdk/9/8162840/00/ > > for the issue > > https://bugs.openjdk.java.net/browse/JDK-8162840 > > > We don't call QuitHandler and using default QuitStrategy if sudden > termination is enabled. > > -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 16 16:33:33 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 16 Aug 2016 09:33:33 -0700 Subject: [9] Review Request: 8164104 Cleanup of javaclient related mapfiles In-Reply-To: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> References: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> Message-ID: <57B3405D.2060504@oracle.com> I think "JPRT is OK" is good but may be not enough here? I am not sure if the build will complain about missing entries for JNI methods since there is no direct linking against these. Can you do a quick sanity run through of Java2Demo on Linux .. and ideally Solaris x64 too. -phil. On 08/16/2016 09:22 AM, Sergey Bylokhov wrote: > Hello. > > Please review cleanup of mapfiles, initially the problem was found here: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html > > - tabs were replaced by spaces > - doubled empty lines removed > > jprt is ok. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 > Patch can be found at: > http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch > From alexandr.scherbatiy at oracle.com Tue Aug 16 16:35:55 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 16 Aug 2016 19:35:55 +0300 Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> Message-ID: <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage should handle > this scale internally, and create double sized surface when > necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled internally. > Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, > width and height were passed without scaling, > which was creating a bitmap of specified width and height, hence the > output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was NOT > hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be discussed on > awt-dev alias. > > Should the backbuffer width and height be also scaled for the > BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Aug 16 16:41:56 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 16 Aug 2016 19:41:56 +0300 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <020c37cc-c9af-4790-a591-29b71b410533@default> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> Message-ID: <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> The fix looks good to me. It would be better if a native speaker look at the documentation change in the launcher.properties file. Thanks, Alexandr. On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ > > > Updates : > > 1)Updated the consition as suggested if(*scaleFactor - > (int)*scaleFactor < 0.000001) > > 2)Includes the changes of > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > > 3)+ //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > This change is required only for windows and linux. As we use absolute > system resolution for centring the splash on screen on these. > > i.e. if system resolution is 1920 X 1080(i.e. unscaled resolution) on > windows and linux we use this for centring the splash on screen. For > mac scaled resolution is used directly. > > Regards, > > Rajeev Chamyal > > *From:*Alexander Scherbatiy > *Sent:* 11 August 2016 14:44 > *To:* Rajeev Chamyal; awt-dev at openjdk.java.net; Philip Race; Sergey > Bylokhov > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > On 10/08/16 19:24, Alexandr Scherbatiy wrote: > > On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ > > > Issue: Currently different naming conventions are used for > Hidpi image on different platforms. > > With this change the names will be unified across all platforms. > > For a unscaled image image.ext following naming convention > will be followed. > > Unscaled name: image.ext > > Supported Scaled Names: > > If screen scale is integer number e.g. 2: image at 2x.ext > > > If screen scale is float value like 1.25: image at 125pct.ext > > > > The fix should be reviewed on the awt-dev alias. > > + if(*scaleFactor - (int)*scaleFactor < 0.000001) > > Should there be so high precision there? Could only percent values > be compared like > if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) > > > + //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > It looks like the splash coordinates and sizes are rescaled in > different places. Is it possible to do that in the same place? May > be in java_awt_SplashScreen.c file getBounds() function? > > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > *scaleFactor = getNativeScaleFactor(); > > Could you also include the change which requires to add some default > output screen name to the getNativeScaleFactor() function on Linux. > There is the discussion about that: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html > > Thanks, > Alexandr. > > > Thanks, > Alexandr. > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Tue Aug 16 16:47:05 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 16 Aug 2016 19:47:05 +0300 Subject: [9] Review request for 8162840: Desktop. enableSuddenTermination() has no effect In-Reply-To: <103d7dcb-f901-95f3-5073-d5c93760ee67@oracle.com> References: <9b9b245b-b428-6de8-a2ed-c0fa29219ba5@oracle.com> <103d7dcb-f901-95f3-5073-d5c93760ee67@oracle.com> Message-ID: Sure, but it is already created by Yuri and attached to the issue. I can include it with this fix, however as far I know SQE has a separate task to cover this JEP with tests and this test is a part of this task. On 8/16/16 7:27 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Is it possible to create a test for the fix? > > On 16.08.16 19:20, Alexander Zvegintsev wrote: >> Hello, >> >> >> please review the fix >> >> http://cr.openjdk.java.net/~azvegint/jdk/9/8162840/00/ >> >> for the issue >> >> https://bugs.openjdk.java.net/browse/JDK-8162840 >> >> >> We don't call QuitHandler and using default QuitStrategy if sudden >> termination is enabled. >> >> > > -- Thanks, Alexander. From philip.race at oracle.com Tue Aug 16 16:57:58 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 16 Aug 2016 09:57:58 -0700 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> Message-ID: <57B34616.5030203@oracle.com> On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > It would be better if a native speaker look at the documentation > change in the launcher.properties file. That documentation seems to cover only *some* of the extensions we discussed. It ought to cite all of them if it does so at all. How else are people supposed to know what they can use ? Where else are you documenting it? Perhaps the launcher "man" page should be updated too find . -name java.1 ./src/linux/doc/man/java.1 ./src/linux/doc/man/ja/java.1 ./src/bsd/doc/man/java.1 ./src/bsd/doc/man/ja/java.1 ./src/solaris/doc/sun/man/man1/java.1 ./src/solaris/doc/sun/man/man1/ja/java.1 .. although I think there is also some HTML version maintained by the pubs/docs team that is not in OpenJDK - the above does not include Windows or Mac. I don't know offhand what is recommended these days. We'll have to find someone who does more with the launcher to help point to where to do the documentation. And the doc does not really explain what is going on here. Reading that I might think I am supposed to pass -splash:image at 2x.ext if I want a hi-dpi image and that is not the idea at all, is it ? The idea is you would still specify -splash:image.ext and the *implementation* will look for the most appropriate scaled image for the current desktop. I think we should also have a CCC cover this (somehow). -phil. > > Thanks, > Alexandr. > > On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ >> >> >> Updates : >> >> 1)Updated the consition as suggested if(*scaleFactor - >> (int)*scaleFactor < 0.000001) >> >> 2)Includes the changes of >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> >> 3)+ //map the splash co-ordinates as per system scale >> + splash->x /= splash->scaleFactor; >> + splash->y /= splash->scaleFactor; >> >> This change is required only for windows and linux. As we use >> absolute system resolution for centring the splash on screen on these. >> >> i.e. if system resolution is 1920 X 1080(i.e. unscaled resolution) on >> windows and linux we use this for centring the splash on screen. For >> mac scaled resolution is used directly. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexander Scherbatiy >> *Sent:* 11 August 2016 14:44 >> *To:* Rajeev Chamyal; awt-dev at openjdk.java.net; Philip Race; Sergey >> Bylokhov >> *Subject:* Re: [9] Review Request JDK-8151787 >> Unify the HiDPI splash screen image naming convention >> >> On 10/08/16 19:24, Alexandr Scherbatiy wrote: >> >> On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: >> >> Hello All, >> >> Please review the following webrev. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 >> >> Webrev: >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ >> >> >> Issue: Currently different naming conventions are used for >> Hidpi image on different platforms. >> >> With this change the names will be unified across all platforms. >> >> For a unscaled image image.ext following naming convention >> will be followed. >> >> Unscaled name: image.ext >> >> Supported Scaled Names: >> >> If screen scale is integer number e.g. 2: image at 2x.ext >> >> >> If screen scale is float value like 1.25: image at 125pct.ext >> >> >> >> The fix should be reviewed on the awt-dev alias. >> >> + if(*scaleFactor - (int)*scaleFactor < 0.000001) >> >> Should there be so high precision there? Could only percent >> values be compared like >> if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) >> >> >> + //map the splash co-ordinates as per system scale >> + splash->x /= splash->scaleFactor; >> + splash->y /= splash->scaleFactor; >> >> It looks like the splash coordinates and sizes are rescaled in >> different places. Is it possible to do that in the same place? >> May be in java_awt_SplashScreen.c file getBounds() function? >> >> >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> *scaleFactor = getNativeScaleFactor(); >> >> Could you also include the change which requires to add some default >> output screen name to the getNativeScaleFactor() function on Linux. >> There is the discussion about that: >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html >> >> Thanks, >> Alexandr. >> >> >> Thanks, >> Alexandr. >> >> >> Regards, >> >> Rajeev Chamyal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Aug 16 17:24:34 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 16 Aug 2016 20:24:34 +0300 Subject: Swing Dev>[9] Review Request JDK-8161913 [PIT] java/awt/Window/8159168/SetShapeTest.java mostly fails In-Reply-To: <22e55c0e-a2af-42fc-9330-7681a091fb3a@default> References: <22e55c0e-a2af-42fc-9330-7681a091fb3a@default> Message-ID: <79ad0a75-64fb-dc77-9daa-957a58114e89@oracle.com> Changed the alias to the awt-dev. The fix looks good to me. Thanks, Alexandr. On 8/16/2016 10:23 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161913 > > Webrev : http://cr.openjdk.java.net/~rchamyal/8161913/webrev.00/ > > > Issue : Test was failing when run repeatedly. > > Fix: Added delay in test. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Wed Aug 17 07:22:11 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 17 Aug 2016 10:22:11 +0300 Subject: [9] Review request for 8162840: Desktop. enableSuddenTermination() has no effect In-Reply-To: References: <9b9b245b-b428-6de8-a2ed-c0fa29219ba5@oracle.com> <103d7dcb-f901-95f3-5073-d5c93760ee67@oracle.com> Message-ID: <2a74e07f-8206-bea3-bbd1-98e7c101ca54@oracle.com> In fact, we have a bunch of them in the func. workspace, all more or less easily portable to jtreg. I'll move them in a bulk, time permitting. -yan On 08/16/2016 07:47 PM, Alexander Zvegintsev wrote: > Sure, but it is already created by Yuri and attached to the issue. > > I can include it with this fix, however as far I know SQE has a separate > task to cover this JEP with tests and this test is a part of this task. > > > On 8/16/16 7:27 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Is it possible to create a test for the fix? >> >> On 16.08.16 19:20, Alexander Zvegintsev wrote: >>> Hello, >>> >>> >>> please review the fix >>> >>> http://cr.openjdk.java.net/~azvegint/jdk/9/8162840/00/ >>> >>> for the issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8162840 >>> >>> >>> We don't call QuitHandler and using default QuitStrategy if sudden >>> termination is enabled. >>> >>> >> >> > From prem.balakrishnan at oracle.com Wed Aug 17 08:30:52 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Wed, 17 Aug 2016 01:30:52 -0700 (PDT) Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> Message-ID: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Wed Aug 17 08:35:02 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 17 Aug 2016 14:05:02 +0530 Subject: Swing Dev>[9] Review Request JDK-8161913 [PIT] java/awt/Window/8159168/SetShapeTest.java mostly fails In-Reply-To: References: <22e55c0e-a2af-42fc-9330-7681a091fb3a@default> <79ad0a75-64fb-dc77-9daa-957a58114e89@oracle.com> Message-ID: Looks good to me. With Regards, Avik Niyogi > From: Alexandr Scherbatiy > Sent: 16 August 2016 22:55 > To: Rajeev Chamyal; Sergey Bylokhov; awt-dev at openjdk.java.net > Subject: Re: Swing Dev>[9] Review Request JDK-8161913 [PIT] java/awt/Window/8159168/SetShapeTest.java mostly fails > > Changed the alias to the awt-dev. > > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/16/2016 10:23 AM, Rajeev Chamyal wrote: > Hello All, > > Please review the following webrev. > Bug: https://bugs.openjdk.java.net/browse/JDK-8161913 > Webrev : http://cr.openjdk.java.net/~rchamyal/8161913/webrev.00/ > > Issue : Test was failing when run repeatedly. > > Fix: Added delay in test. > > Regards, > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Aug 17 11:12:07 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 17 Aug 2016 14:12:07 +0300 Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> Message-ID: On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values from > getDefaultScaleX()/getDefaultScaleY(), which I have used in the > current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage should handle > this scale internally, and create double sized surface when > necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled internally. > Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, > width and height were passed without scaling, > which was creating a bitmap of specified width and height, hence the > output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales from > getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return > right values after setting the scaled image sizes in the fix? > - Region.clipScale() which is used in many places rounds values. The > usual rule is to use Math.floor() for image coordinates rounding and > Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was NOT > hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be discussed on > awt-dev alias. > > Should the backbuffer width and height be also scaled for the > BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Aug 17 13:33:32 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 17 Aug 2016 16:33:32 +0300 Subject: [9] Review Request: 8164104 Cleanup of javaclient related mapfiles In-Reply-To: <57B3405D.2060504@oracle.com> References: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> <57B3405D.2060504@oracle.com> Message-ID: <9db92a0e-69f4-a299-714e-02cb7fffd165@oracle.com> Tested on solarisX64/solarisSparc/linuxX64 no issues were found(SwingSet2/Java2Demo). But I wonder why the text on solarissparc filled by yellow shadow(Is it a known issue)? On 16.08.16 19:33, Phil Race wrote: > I think "JPRT is OK" is good but may be not enough here? > I am not sure if the build will complain about missing entries > for JNI methods since there is no direct linking against these. > Can you do a quick sanity run through of Java2Demo on Linux .. > and ideally Solaris x64 too. > > -phil. > > On 08/16/2016 09:22 AM, Sergey Bylokhov wrote: >> Hello. >> >> Please review cleanup of mapfiles, initially the problem was found here: >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html >> >> - tabs were replaced by spaces >> - doubled empty lines removed >> >> jprt is ok. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 >> Patch can be found at: >> http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch >> > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Thu Aug 18 06:59:59 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Wed, 17 Aug 2016 23:59:59 -0700 (PDT) Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> Message-ID: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Aug 18 09:27:14 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 18 Aug 2016 12:27:14 +0300 Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> Message-ID: Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > AccelSurface is implemented by *ONLY* D3DSurfaceData and > OGLSurfaceData classes, > > Both of these classes extend SurfaceData as well. > > Hence, casting of 'as' variable which is of type AccelSurface object > to SurfaceData is always VALID. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Wednesday, August 17, 2016 4:42 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values from > getDefaultScaleX()/getDefaultScaleY(), which I have used in the > current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Is it always true that the 'as' variable which has type AccelSurface > in the fix is always instance of SurfaceData? > > Thanks, > Alexandr. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage should handle > this scale internally, and create double sized surface when > necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled internally. > Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, > width and height were passed without scaling, > which was creating a bitmap of specified width and height, hence the > output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales from > getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return > right values after setting the scaled image sizes in the fix? > - Region.clipScale() which is used in many places rounds values. The > usual rule is to use Math.floor() for image coordinates rounding and > Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was NOT > hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be discussed on > awt-dev alias. > > Should the backbuffer width and height be also scaled for the > BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Aug 18 09:28:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 18 Aug 2016 12:28:01 +0300 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> Message-ID: <0a9646f2-f141-845d-4411-0a5c6536e1aa@oracle.com> Looks fine. please change the title of the frame to some text related to this fix, instead of "Updating TrayIcon Popup Menu Item Test" On 14.08.16 23:50, Manajit Halder wrote: > Hi Sergey, > > Thank you for your review comments. > > I have modified the code as per your first two comments. > For the last comment the fix was tested with JDK versions b123, b124, > b125, b127 and b130 and > the test failed with the popup message. > > Please review the modified review. > http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ > > Thanks, > Manajit > >> On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov >> > wrote: >> >> Hi, Manajit. >> - Its seems that the test creates the Swing components on non-EDT. >> - The instructions are a little bit misleading, because popup will be >> shown even when the test is passed. >> - When I run the test on the current client ws, it is passed. Can you >> please double check that the test fails before the fix. >> >> On 01.08.16 12:35, Manajit Halder wrote: >>> Hi All, >>> >>> Kindly review the fix for JDK9. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8156099 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >>> >>> Issue: >>> [macosx] Drag and drop of link from web browser, DataFlavor types >>> application/x-java-url and text/uri-list, getTransferData returns null >>> >>> Cause: >>> This issue is a regression of issue >>> https://bugs.openjdk.java.net/browse/JDK-8136763. >>> While adding fix to 8136763 code was modified to handle coping of >>> multiple files but proper distinction was not added between bytes >>> containing files and urls. >>> >>> Fix: >>> Fixed by comparing format of the bytes received for dataflavor >>> "mimetype=text/uri-list". >>> Fixed by distinguishing between bytes containing files and urls. In both >>> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >>> format is different. >>> Format CF_FILE is only used in case of bytes containing files. >>> >>> Regards, >>> Manajit >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Thu Aug 18 09:42:18 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 18 Aug 2016 02:42:18 -0700 (PDT) Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> Message-ID: <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Thu Aug 18 11:55:48 2016 From: manajit.halder at oracle.com (Manajit Halder) Date: Thu, 18 Aug 2016 17:25:48 +0530 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: <0a9646f2-f141-845d-4411-0a5c6536e1aa@oracle.com> References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> <0a9646f2-f141-845d-4411-0a5c6536e1aa@oracle.com> Message-ID: Hi Sergey, Thank you for the review. I have modified the code as per your comment. http://cr.openjdk.java.net/~mhalder/8156099/webrev.02/ Thanks, Manajit > On 18-Aug-2016, at 2:58 pm, Sergey Bylokhov wrote: > > Looks fine. > please change the title of the frame to some text related to this fix, instead of "Updating TrayIcon Popup Menu Item Test" > > On 14.08.16 23:50, Manajit Halder wrote: >> Hi Sergey, >> >> Thank you for your review comments. >> >> I have modified the code as per your first two comments. >> For the last comment the fix was tested with JDK versions b123, b124, >> b125, b127 and b130 and >> the test failed with the popup message. >> >> Please review the modified review. >> http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ >> >> Thanks, >> Manajit >> >>> On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov >>> >> wrote: >>> >>> Hi, Manajit. >>> - Its seems that the test creates the Swing components on non-EDT. >>> - The instructions are a little bit misleading, because popup will be >>> shown even when the test is passed. >>> - When I run the test on the current client ws, it is passed. Can you >>> please double check that the test fails before the fix. >>> >>> On 01.08.16 12:35, Manajit Halder wrote: >>>> Hi All, >>>> >>>> Kindly review the fix for JDK9. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8156099 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >>>> >>>> Issue: >>>> [macosx] Drag and drop of link from web browser, DataFlavor types >>>> application/x-java-url and text/uri-list, getTransferData returns null >>>> >>>> Cause: >>>> This issue is a regression of issue >>>> https://bugs.openjdk.java.net/browse/JDK-8136763 . >>>> While adding fix to 8136763 code was modified to handle coping of >>>> multiple files but proper distinction was not added between bytes >>>> containing files and urls. >>>> >>>> Fix: >>>> Fixed by comparing format of the bytes received for dataflavor >>>> "mimetype=text/uri-list". >>>> Fixed by distinguishing between bytes containing files and urls. In both >>>> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >>>> format is different. >>>> Format CF_FILE is only used in case of bytes containing files. >>>> >>>> Regards, >>>> Manajit >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Aug 18 12:39:02 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 18 Aug 2016 05:39:02 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <57B34616.5030203@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> Message-ID: <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> Hello Phil, Thanks for the review. Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ Updated file src/java.base/share/classes/sun/launcher/resources/launcher.properties Regards, Rajeev Chamyal From: Phil Race Sent: 16 August 2016 22:28 To: Alexandr Scherbatiy Cc: Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: The fix looks good to me. It would be better if a native speaker look at the documentation change in the launcher.properties file. That documentation seems to cover only *some* of the extensions we discussed. It ought to cite all of them if it does so at all. How else are people supposed to know what they can use ? Where else are you documenting it? Perhaps the launcher "man" page should be updated too find . -name java.1 ./src/linux/doc/man/java.1 ./src/linux/doc/man/ja/java.1 ./src/bsd/doc/man/java.1 ./src/bsd/doc/man/ja/java.1 ./src/solaris/doc/sun/man/man1/java.1 ./src/solaris/doc/sun/man/man1/ja/java.1 .. although I think there is also some HTML version maintained by the pubs/docs team that is not in OpenJDK - the above does not include Windows or Mac. I don't know offhand what is recommended these days. We'll have to find someone who does more with the launcher to help point to where to do the documentation. And the doc does not really explain what is going on here. Reading that I might think I am supposed to pass -splash:image at 2x.ext if I want a hi-dpi image and that is not the idea at all, is it ? The idea is you would still specify -splash:image.ext and the *implementation* will look for the most appropriate scaled image for the current desktop. I think we should also have a CCC cover this (somehow). -phil. Thanks, Alexandr. On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: Hello Alexandr, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ Updates : 1) Updated the consition as suggested if(*scaleFactor - (int)*scaleFactor < 0.000001) 2) Includes the changes of src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c 3) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; This change is required only for windows and linux. As we use absolute system resolution for centring the splash on screen on these. i.e. if system resolution is 1920 X 1080(i.e. unscaled resolution) on windows and linux we use this for centring the splash on screen. For mac scaled resolution is used directly. Regards, Rajeev Chamyal From: Alexander Scherbatiy Sent: 11 August 2016 14:44 To: Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Philip Race; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention On 10/08/16 19:24, Alexandr Scherbatiy wrote: On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ Issue: Currently different naming conventions are used for Hidpi image on different platforms. With this change the names will be unified across all platforms. For a unscaled image image.ext following naming convention will be followed. Unscaled name: image.ext Supported Scaled Names: If screen scale is integer number e.g. 2: HYPERLINK "mailto:image at 2x.ext"image at 2x.ext If screen scale is float value like 1.25: HYPERLINK "mailto:image at 125pct.ext"image at 125pct.ext The fix should be reviewed on the awt-dev alias. + if(*scaleFactor - (int)*scaleFactor < 0.000001) Should there be so high precision there? Could only percent values be compared like if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; It looks like the splash coordinates and sizes are rescaled in different places. Is it possible to do that in the same place? May be in java_awt_SplashScreen.c file getBounds() function? src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c *scaleFactor = getNativeScaleFactor(); Could you also include the change which requires to add some default output screen name to the getNativeScaleFactor() function on Linux. There is the discussion about that: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html Thanks, Alexandr. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 18 22:10:16 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 15:10:16 -0700 Subject: [9] Review Request: 8164104 Cleanup of javaclient related mapfiles In-Reply-To: <9db92a0e-69f4-a299-714e-02cb7fffd165@oracle.com> References: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> <57B3405D.2060504@oracle.com> <9db92a0e-69f4-a299-714e-02cb7fffd165@oracle.com> Message-ID: <57B63248.3080904@oracle.com> On 8/17/16, 6:33 AM, Sergey Bylokhov wrote: > Tested on solarisX64/solarisSparc/linuxX64 no issues were > found(SwingSet2/Java2Demo). Sounds good. +1 > But I wonder why the text on solarissparc filled by yellow shadow(Is > it a known issue)? Yes there is an open bug. I believe it is a SPARC (or more probably big endian) issue in the Xrender server-side support for sub-pixel text. I believe I've observed this with Xvnc where both X libs, Xserver and Vnc are all running on the SPARC server and the latter two in one combined process. So a bug "not in our code" but I've never been able to put all the pieces together - or rather find the time to do that - to find where in the stack the problem lies. -phil. > > On 16.08.16 19:33, Phil Race wrote: >> I think "JPRT is OK" is good but may be not enough here? >> I am not sure if the build will complain about missing entries >> for JNI methods since there is no direct linking against these. >> Can you do a quick sanity run through of Java2Demo on Linux .. >> and ideally Solaris x64 too. >> >> -phil. >> >> On 08/16/2016 09:22 AM, Sergey Bylokhov wrote: >>> Hello. >>> >>> Please review cleanup of mapfiles, initially the problem was found >>> here: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html >>> >>> - tabs were replaced by spaces >>> - doubled empty lines removed >>> >>> jprt is ok. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 >>> Patch can be found at: >>> http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch >>> >> > > From philip.race at oracle.com Thu Aug 18 23:17:55 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 16:17:55 -0700 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> Message-ID: <57B64223.8090304@oracle.com> Better, although it still does not document the supported set of scale name extensions that we discussed/proposed off-line. -phil. On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Thanks for the review. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ > > > Updated file > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Regards, > > Rajeev Chamyal > > *From:*Phil Race > *Sent:* 16 August 2016 22:28 > *To:* Alexandr Scherbatiy > *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > It would be better if a native speaker look at the documentation > change in the launcher.properties file. > > > That documentation seems to cover only *some* of the extensions we > discussed. > It ought to cite all of them if it does so at all. How else are people > supposed > to know what they can use ? Where else are you documenting it? > Perhaps the launcher "man" page should be updated too > find . -name java.1 > ./src/linux/doc/man/java.1 > ./src/linux/doc/man/ja/java.1 > ./src/bsd/doc/man/java.1 > ./src/bsd/doc/man/ja/java.1 > ./src/solaris/doc/sun/man/man1/java.1 > ./src/solaris/doc/sun/man/man1/ja/java.1 > > .. although I think there is also some HTML version maintained by the > pubs/docs team > that is not in OpenJDK - the above does not include Windows or Mac. > I don't know offhand what is recommended these days. We'll have to > find someone > who does more with the launcher to help point to where to do the > documentation. > > And the doc does not really explain what is going on here. Reading > that I might > think I am supposed to pass -splash:image at 2x.ext if I want a hi-dpi image > and that is not the idea at all, is it ? > The idea is you would still specify -splash:image.ext and the > *implementation* > will look for the most appropriate scaled image for the current desktop. > > I think we should also have a CCC cover this (somehow). > > -phil. > > > > Thanks, > Alexandr. > > On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ > > > Updates : > > 1)Updated the consition as suggested if(*scaleFactor - > (int)*scaleFactor < 0.000001) > > 2)Includes the changes of > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > > 3)+ //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > > This change is required only for windows and linux. As we use > absolute system resolution for centring the splash on screen > on these. > > i.e. if system resolution is 1920 X 1080(i.e. unscaled > resolution) on windows and linux we use this for centring the > splash on screen. For mac scaled resolution is used directly. > > Regards, > > Rajeev Chamyal > > *From:*Alexander Scherbatiy > *Sent:* 11 August 2016 14:44 > *To:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Philip Race; Sergey Bylokhov > *Subject:* Re: [9] Review Request > JDK-8151787 Unify the HiDPI splash screen image naming convention > > On 10/08/16 19:24, Alexandr Scherbatiy wrote: > > > On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ > > > Issue: Currently different naming conventions are used > for Hidpi image on different platforms. > > With this change the names will be unified across all > platforms. > > For a unscaled image image.ext following naming > convention will be followed. > > Unscaled name: image.ext > > Supported Scaled Names: > > If screen scale is integer number e.g. 2: image at 2x.ext > > > If screen scale is float value like 1.25: > image at 125pct.ext > > > The fix should be reviewed on the awt-dev alias. > > + if(*scaleFactor - (int)*scaleFactor < 0.000001) > > Should there be so high precision there? Could only > percent values be compared like > if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) > > > + //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > It looks like the splash coordinates and sizes are > rescaled in different places. Is it possible to do that in > the same place? May be in java_awt_SplashScreen.c file > getBounds() function? > > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > *scaleFactor = getNativeScaleFactor(); > > Could you also include the change which requires to add some > default output screen name to the getNativeScaleFactor() > function on Linux. There is the discussion about that: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html > > Thanks, > Alexandr. > > > > Thanks, > Alexandr. > > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Fri Aug 19 10:41:36 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 19 Aug 2016 03:41:36 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <57B64223.8090304@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> Message-ID: <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> Hello Phil, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ Updated file src/java.base/share/classes/sun/launcher/resources/launcher.properties Added all other supported name extensions. Regards, Rajeev Chamyal From: Philip Race Sent: 19 August 2016 04:48 To: Rajeev Chamyal Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention Better, although it still does not document the supported set of scale name extensions that we discussed/proposed off-line. -phil. On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: Hello Phil, Thanks for the review. Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/"http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ Updated file src/java.base/share/classes/sun/launcher/resources/launcher.properties Regards, Rajeev Chamyal From: Phil Race Sent: 16 August 2016 22:28 To: Alexandr Scherbatiy Cc: Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: The fix looks good to me. It would be better if a native speaker look at the documentation change in the launcher.properties file. That documentation seems to cover only *some* of the extensions we discussed. It ought to cite all of them if it does so at all. How else are people supposed to know what they can use ? Where else are you documenting it? Perhaps the launcher "man" page should be updated too find . -name java.1 ./src/linux/doc/man/java.1 ./src/linux/doc/man/ja/java.1 ./src/bsd/doc/man/java.1 ./src/bsd/doc/man/ja/java.1 ./src/solaris/doc/sun/man/man1/java.1 ./src/solaris/doc/sun/man/man1/ja/java.1 .. although I think there is also some HTML version maintained by the pubs/docs team that is not in OpenJDK - the above does not include Windows or Mac. I don't know offhand what is recommended these days. We'll have to find someone who does more with the launcher to help point to where to do the documentation. And the doc does not really explain what is going on here. Reading that I might think I am supposed to pass -splash:image at 2x.ext if I want a hi-dpi image and that is not the idea at all, is it ? The idea is you would still specify -splash:image.ext and the *implementation* will look for the most appropriate scaled image for the current desktop. I think we should also have a CCC cover this (somehow). -phil. Thanks, Alexandr. On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: Hello Alexandr, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ Updates : 1) Updated the consition as suggested if(*scaleFactor - (int)*scaleFactor < 0.000001) 2) Includes the changes of src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c 3) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; This change is required only for windows and linux. As we use absolute system resolution for centring the splash on screen on these. i.e. if system resolution is 1920 X 1080(i.e. unscaled resolution) on windows and linux we use this for centring the splash on screen. For mac scaled resolution is used directly. Regards, Rajeev Chamyal From: Alexander Scherbatiy Sent: 11 August 2016 14:44 To: Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Philip Race; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention On 10/08/16 19:24, Alexandr Scherbatiy wrote: On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ Issue: Currently different naming conventions are used for Hidpi image on different platforms. With this change the names will be unified across all platforms. For a unscaled image image.ext following naming convention will be followed. Unscaled name: image.ext Supported Scaled Names: If screen scale is integer number e.g. 2: HYPERLINK "mailto:image at 2x.ext"image at 2x.ext If screen scale is float value like 1.25: HYPERLINK "mailto:image at 125pct.ext"image at 125pct.ext The fix should be reviewed on the awt-dev alias. + if(*scaleFactor - (int)*scaleFactor < 0.000001) Should there be so high precision there? Could only percent values be compared like if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) + //map the splash co-ordinates as per system scale + splash->x /= splash->scaleFactor; + splash->y /= splash->scaleFactor; It looks like the splash coordinates and sizes are rescaled in different places. Is it possible to do that in the same place? May be in java_awt_SplashScreen.c file getBounds() function? src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c *scaleFactor = getNativeScaleFactor(); Could you also include the change which requires to add some default output screen name to the getNativeScaleFactor() function on Linux. There is the discussion about that: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html Thanks, Alexandr. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prem.balakrishnan at oracle.com Fri Aug 19 12:16:05 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Fri, 19 Aug 2016 05:16:05 -0700 (PDT) Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> Message-ID: <5fb211e7-da91-4a5a-92f0-14c7d3d6a472@default> Reminder From: Prem Balakrishnan Sent: Thursday, August 18, 2016 3:12 PM To: Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Aug 19 20:17:04 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Aug 2016 13:17:04 -0700 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> Message-ID: <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. -phil. On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ > > > Updated file > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Added all other supported name extensions. > > Regards, > > Rajeev Chamyal > > *From:*Philip Race > *Sent:* 19 August 2016 04:48 > *To:* Rajeev Chamyal > *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > Better, although it still does not document the supported set of scale > name extensions that we discussed/proposed off-line. > > -phil. > > On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Thanks for the review. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ > > > Updated file > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Regards, > > Rajeev Chamyal > > *From:*Phil Race > *Sent:* 16 August 2016 22:28 > *To:* Alexandr Scherbatiy > *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > It would be better if a native speaker look at the > documentation change in the launcher.properties file. > > > That documentation seems to cover only *some* of the extensions we > discussed. > It ought to cite all of them if it does so at all. How else are > people supposed > to know what they can use ? Where else are you documenting it? > Perhaps the launcher "man" page should be updated too > find . -name java.1 > ./src/linux/doc/man/java.1 > ./src/linux/doc/man/ja/java.1 > ./src/bsd/doc/man/java.1 > ./src/bsd/doc/man/ja/java.1 > ./src/solaris/doc/sun/man/man1/java.1 > ./src/solaris/doc/sun/man/man1/ja/java.1 > > .. although I think there is also some HTML version maintained by > the pubs/docs team > that is not in OpenJDK - the above does not include Windows or Mac. > I don't know offhand what is recommended these days. We'll have to > find someone > who does more with the launcher to help point to where to do the > documentation. > > And the doc does not really explain what is going on here. Reading > that I might > think I am supposed to pass -splash:image at 2x.ext if I want a > hi-dpi image > and that is not the idea at all, is it ? > The idea is you would still specify -splash:image.ext and the > *implementation* > will look for the most appropriate scaled image for the current > desktop. > > I think we should also have a CCC cover this (somehow). > > -phil. > > > > > Thanks, > Alexandr. > > On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ > > > Updates : > > 1)Updated the consition as suggested if(*scaleFactor - > (int)*scaleFactor < 0.000001) > > 2)Includes the changes of > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > > 3)+ //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > > > This change is required only for windows and linux. As we > use absolute system resolution for centring the splash on > screen on these. > > i.e. if system resolution is 1920 X 1080(i.e. unscaled > resolution) on windows and linux we use this for centring > the splash on screen. For mac scaled resolution is used > directly. > > Regards, > > Rajeev Chamyal > > *From:*Alexander Scherbatiy > *Sent:* 11 August 2016 14:44 > *To:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Philip Race; Sergey > Bylokhov > *Subject:* Re: [9] Review Request > JDK-8151787 Unify the HiDPI splash screen image naming > convention > > On 10/08/16 19:24, Alexandr Scherbatiy wrote: > > > > On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ > > > > Issue: Currently different naming conventions are > used for Hidpi image on different platforms. > > With this change the names will be unified across > all platforms. > > For a unscaled image image.ext following naming > convention will be followed. > > Unscaled name: image.ext > > Supported Scaled Names: > > If screen scale is integer number e.g. 2: > image at 2x.ext > > If screen scale is float value like 1.25: > image at 125pct.ext > > > The fix should be reviewed on the awt-dev alias. > > + if(*scaleFactor - (int)*scaleFactor < 0.000001) > > Should there be so high precision there? Could only > percent values be compared like > if ((*scaleFactor *100) != ((int)(*scaleFactor)) * 100) > > > + //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > It looks like the splash coordinates and sizes are > rescaled in different places. Is it possible to do > that in the same place? May be in > java_awt_SplashScreen.c file getBounds() function? > > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > *scaleFactor = getNativeScaleFactor(); > > Could you also include the change which requires to add > some default output screen name to the > getNativeScaleFactor() function on Linux. There is the > discussion about that: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html > > Thanks, > Alexandr. > > > > > Thanks, > Alexandr. > > > > > Regards, > > Rajeev Chamyal > From Sergey.Bylokhov at oracle.com Sat Aug 20 11:11:38 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 20 Aug 2016 14:11:38 +0300 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> <0a9646f2-f141-845d-4411-0a5c6536e1aa@oracle.com> Message-ID: +1 On 18.08.16 14:55, Manajit Halder wrote: > Hi Sergey, > > Thank you for the review. I have modified the code as per your comment. > http://cr.openjdk.java.net/~mhalder/8156099/webrev.02/ > > Thanks, > Manajit > >> On 18-Aug-2016, at 2:58 pm, Sergey Bylokhov >> > wrote: >> >> Looks fine. >> please change the title of the frame to some text related to this fix, >> instead of "Updating TrayIcon Popup Menu Item Test" >> >> On 14.08.16 23:50, Manajit Halder wrote: >>> Hi Sergey, >>> >>> Thank you for your review comments. >>> >>> I have modified the code as per your first two comments. >>> For the last comment the fix was tested with JDK versions b123, b124, >>> b125, b127 and b130 and >>> the test failed with the popup message. >>> >>> Please review the modified review. >>> http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ >>> >>> Thanks, >>> Manajit >>> >>>> On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov >>>> >>> > >>>> wrote: >>>> >>>> Hi, Manajit. >>>> - Its seems that the test creates the Swing components on non-EDT. >>>> - The instructions are a little bit misleading, because popup will be >>>> shown even when the test is passed. >>>> - When I run the test on the current client ws, it is passed. Can you >>>> please double check that the test fails before the fix. >>>> >>>> On 01.08.16 12:35, Manajit Halder wrote: >>>>> Hi All, >>>>> >>>>> Kindly review the fix for JDK9. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8156099 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >>>>> >>>>> Issue: >>>>> [macosx] Drag and drop of link from web browser, DataFlavor types >>>>> application/x-java-url and text/uri-list, getTransferData returns null >>>>> >>>>> Cause: >>>>> This issue is a regression of issue >>>>> https://bugs.openjdk.java.net/browse/JDK-8136763. >>>>> While adding fix to 8136763 code was modified to handle coping of >>>>> multiple files but proper distinction was not added between bytes >>>>> containing files and urls. >>>>> >>>>> Fix: >>>>> Fixed by comparing format of the bytes received for dataflavor >>>>> "mimetype=text/uri-list". >>>>> Fixed by distinguishing between bytes containing files and urls. In >>>>> both >>>>> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >>>>> format is different. >>>>> Format CF_FILE is only used in case of bytes containing files. >>>>> >>>>> Regards, >>>>> Manajit >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Aug 22 07:02:06 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 22 Aug 2016 12:32:06 +0530 Subject: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> Message-ID: <57BAA36E.2010704@oracle.com> I wonder how it compiles? I tried a small program ------------------ public class Test { AccelSurface b = new AccelSurface(); SurfaceData c = (SurfaceData)b; } class SurfaceData extends Surface {} class Surface {} class AccelSurface extends Surface {} --------- and it fails to compile Test.java:3: error: incompatible types: AccelSurface cannot be converted to SurfaceData SurfaceData c = (SurfaceData)b; ANyways, did you check with opengl pipeline? It seems getDefaultScaleX/Y is not present in OGLSurfaceData which will result in falling back to SurfaceData in which case the scale will be 1. Regards Prasanta On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: > > Added ?2d-dev? team for review > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 18, 2016 2:57 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Could you also send the review to the 2d-dev alias? > > Thanks, > Alexandr. > > On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > AccelSurface is implemented by *ONLY* D3DSurfaceData and > OGLSurfaceData classes, > > Both of these classes extend SurfaceData as well. > > Hence, casting of 'as' variable which is of type AccelSurface > object to SurfaceData is always VALID. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Wednesday, August 17, 2016 4:42 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values from > getDefaultScaleX()/getDefaultScaleY(), which I have used in the > current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Is it always true that the 'as' variable which has type > AccelSurface in the fix is always instance of SurfaceData? > > Thanks, > Alexandr. > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; > awt-dev at openjdk.java.net ; Sergey > Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage should > handle this scale internally, and create double sized surface when > necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled internally. > Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, h) > call, width and height were passed without scaling, > > which was creating a bitmap of specified width and height, hence > the output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales from > getDefaultScaleX()/getDefaultScaleY() methods. Do these methods > return right values after setting the scaled image sizes in the fix? > - Region.clipScale() which is used in many places rounds values. > The usual rule is to use Math.floor() for image coordinates > rounding and Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was NOT > hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be discussed on > awt-dev alias. > > Should the backbuffer width and height be also scaled for the > BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Mon Aug 22 07:06:50 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 22 Aug 2016 12:36:50 +0530 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> Message-ID: <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> + 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Aug 22 08:33:18 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 22 Aug 2016 11:33:18 +0300 Subject: [9] Review request for 8149115: [hidpi] Linux: display-wise scaling factor should probably be taken into account In-Reply-To: <6be05fed-3f7f-5ff1-5615-85ca71ca724d@oracle.com> References: <8f97e1c2-353f-b7f8-c691-f7986284381b@oracle.com> <72f7290d-6cea-c074-4fab-5294d44b4736@oracle.com> <9bda5602-3f9b-3931-026d-642526a1f3ad@oracle.com> <6689b827-d725-1a0a-a7d1-13804404e07c@oracle.com> <9497e7e7-bf41-6afe-3867-d8c8059bbe18@oracle.com> <61f453dc-8ef4-9ebe-9fc2-a70718d3bcf9@oracle.com> <5184aba8-2dfc-73af-be49-7e0bcb87ea1a@oracle.com> <0ea4b416-9c0d-5e16-f1aa-049d847a3956@oracle.com> <062d3b41-7ece-d9b6-ab7d-701d008bad2d@oracle.com> <6be05fed-3f7f-5ff1-5615-85ca71ca724d@oracle.com> Message-ID: <7097b726-6dc0-d4d4-5422-58760830b5fd@oracle.com> On 8/10/2016 5:54 PM, Sergey Bylokhov wrote: > It is unclear why gdk_scale is applied on top of native scale? So if > both GDK_SCALE and scale-factor are set, then we will get the multiply > of them, is it expected? yes. GDK_SCALE is to scale gtklib based apps. Desktop scale is a separate scale. --Semyon > > On 08.07.16 13:27, Alexander Zvegintsev wrote: >> +1 >> >> >> On 7/8/16 10:37 AM, Alexandr Scherbatiy wrote: >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 7/8/2016 9:25 AM, Semyon Sadetsky wrote: >>>> I have changed variables declaration style in systemScale.c, because >>>> it produced warnings in Solaris build. >>>> >>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.03/ >>>> >>>> --Semyon >>>> >>>> On 7/7/2016 9:57 AM, Alexandr Scherbatiy wrote: >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/6/2016 11:46 PM, Alexander Zvegintsev wrote: >>>>>> Still looks good. >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Alexander. >>>>>> >>>>>> On 06.07.2016 21:42, Semyon Sadetsky wrote: >>>>>>> Thanks, Alexander. Please see the updated webrev >>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.02/ >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> >>>>>>> On 7/6/2016 9:03 PM, Alexander Zvegintsev wrote: >>>>>>>> The fix looks good to me. >>>>>>>> >>>>>>>> Just a minor comment: multiple NULL checks in get_schema_value >>>>>>>> could be wrapped in CHECK_NULL_RETURN macro, e.g.: >>>>>>>> >>>>>>>> CHECH_NULL_RETURN(fp_g_settings_schema_has_key >>>>>>>> = dlsym(lib_handle, "g_settings_schema_has_key"), >>>>>>>> NULL); >>>>>>>> CHECH_NULL_RETURN(fp_g_settings_new_full >>>>>>>> = dlsym(lib_handle, "g_settings_new_full"), NULL); >>>>>>>> >>>>>>>> >>>>>>>> On 7/6/16 5:27 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> The fix looks good to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 7/6/2016 4:46 PM, Semyon Sadetsky wrote: >>>>>>>>>> On 7/6/2016 12:26 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>>> On 7/5/2016 9:59 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149115 >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Currently the hidpi support on linux only reads GDK_SCALE >>>>>>>>>>>> environment variable to get the native scale. Although, >>>>>>>>>>>> Gnome3 and Unity DE use own settings to control the interface >>>>>>>>>>>> scale. The fix adds possibility to read those settings to >>>>>>>>>>>> make java apps hidpi scale similar to the native apps. >>>>>>>>>>>> Currently only integer scale values are supported. If native >>>>>>>>>>>> scale is not an integer value it is rounded to the nearest >>>>>>>>>>>> integer. >>>>>>>>>>> systemScale.c >>>>>>>>>>> Should the while loop have a break statement in the >>>>>>>>>>> getDesktopScale(...) method? >>>>>>>>>> That's make sense. Please look at the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.01/ >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Aug 22 10:35:32 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Aug 2016 13:35:32 +0300 Subject: [9] Review request for 8149115: [hidpi] Linux: display-wise scaling factor should probably be taken into account In-Reply-To: <7097b726-6dc0-d4d4-5422-58760830b5fd@oracle.com> References: <8f97e1c2-353f-b7f8-c691-f7986284381b@oracle.com> <72f7290d-6cea-c074-4fab-5294d44b4736@oracle.com> <9bda5602-3f9b-3931-026d-642526a1f3ad@oracle.com> <6689b827-d725-1a0a-a7d1-13804404e07c@oracle.com> <9497e7e7-bf41-6afe-3867-d8c8059bbe18@oracle.com> <61f453dc-8ef4-9ebe-9fc2-a70718d3bcf9@oracle.com> <5184aba8-2dfc-73af-be49-7e0bcb87ea1a@oracle.com> <0ea4b416-9c0d-5e16-f1aa-049d847a3956@oracle.com> <062d3b41-7ece-d9b6-ab7d-701d008bad2d@oracle.com> <6be05fed-3f7f-5ff1-5615-85ca71ca724d@oracle.com> <7097b726-6dc0-d4d4-5422-58760830b5fd@oracle.com> Message-ID: <739f89f3-8309-37fa-2e00-e8ba8ea9cdae@oracle.com> On 22.08.16 11:33, Semyon Sadetsky wrote: >> It is unclear why gdk_scale is applied on top of native scale? So if >> both GDK_SCALE and scale-factor are set, then we will get the multiply >> of them, is it expected? > yes. GDK_SCALE is to scale gtklib based apps. Desktop scale is a > separate scale. So if the user will want to have double scale the he can set desktop scale=2.0(which is supported by one set of applications) and GDK_SCALE=2.0(which is supported by another set of applications), in this case the java scale will be 4, right? > > --Semyon >> >> On 08.07.16 13:27, Alexander Zvegintsev wrote: >>> +1 >>> >>> >>> On 7/8/16 10:37 AM, Alexandr Scherbatiy wrote: >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/8/2016 9:25 AM, Semyon Sadetsky wrote: >>>>> I have changed variables declaration style in systemScale.c, because >>>>> it produced warnings in Solaris build. >>>>> >>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.03/ >>>>> >>>>> --Semyon >>>>> >>>>> On 7/7/2016 9:57 AM, Alexandr Scherbatiy wrote: >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/6/2016 11:46 PM, Alexander Zvegintsev wrote: >>>>>>> Still looks good. >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Alexander. >>>>>>> >>>>>>> On 06.07.2016 21:42, Semyon Sadetsky wrote: >>>>>>>> Thanks, Alexander. Please see the updated webrev >>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.02/ >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> >>>>>>>> On 7/6/2016 9:03 PM, Alexander Zvegintsev wrote: >>>>>>>>> The fix looks good to me. >>>>>>>>> >>>>>>>>> Just a minor comment: multiple NULL checks in get_schema_value >>>>>>>>> could be wrapped in CHECK_NULL_RETURN macro, e.g.: >>>>>>>>> >>>>>>>>> CHECH_NULL_RETURN(fp_g_settings_schema_has_key >>>>>>>>> = dlsym(lib_handle, "g_settings_schema_has_key"), >>>>>>>>> NULL); >>>>>>>>> CHECH_NULL_RETURN(fp_g_settings_new_full >>>>>>>>> = dlsym(lib_handle, "g_settings_new_full"), NULL); >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/6/16 5:27 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> The fix looks good to me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 7/6/2016 4:46 PM, Semyon Sadetsky wrote: >>>>>>>>>>> On 7/6/2016 12:26 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>>> On 7/5/2016 9:59 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149115 >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Currently the hidpi support on linux only reads GDK_SCALE >>>>>>>>>>>>> environment variable to get the native scale. Although, >>>>>>>>>>>>> Gnome3 and Unity DE use own settings to control the interface >>>>>>>>>>>>> scale. The fix adds possibility to read those settings to >>>>>>>>>>>>> make java apps hidpi scale similar to the native apps. >>>>>>>>>>>>> Currently only integer scale values are supported. If native >>>>>>>>>>>>> scale is not an integer value it is rounded to the nearest >>>>>>>>>>>>> integer. >>>>>>>>>>>> systemScale.c >>>>>>>>>>>> Should the while loop have a break statement in the >>>>>>>>>>>> getDesktopScale(...) method? >>>>>>>>>>> That's make sense. Please look at the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8149115/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Mon Aug 22 11:13:47 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 22 Aug 2016 04:13:47 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> Message-ID: Hello Phil, Thanks for the review, Please review updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ Updated files: src/java.base/share/classes/sun/launcher/resources/launcher.properties src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h Regards, Rajeev Chamyal -----Original Message----- From: Phil Race Sent: 20 August 2016 01:47 To: Rajeev Chamyal Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. -phil. On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ > > > Updated file > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Added all other supported name extensions. > > Regards, > > Rajeev Chamyal > > *From:*Philip Race > *Sent:* 19 August 2016 04:48 > *To:* Rajeev Chamyal > *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > Better, although it still does not document the supported set of scale > name extensions that we discussed/proposed off-line. > > -phil. > > On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Thanks for the review. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ > > > Updated file > > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Regards, > > Rajeev Chamyal > > *From:*Phil Race > *Sent:* 16 August 2016 22:28 > *To:* Alexandr Scherbatiy > *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > It would be better if a native speaker look at the > documentation change in the launcher.properties file. > > > That documentation seems to cover only *some* of the extensions we > discussed. > It ought to cite all of them if it does so at all. How else are > people supposed > to know what they can use ? Where else are you documenting it? > Perhaps the launcher "man" page should be updated too > find . -name java.1 > ./src/linux/doc/man/java.1 > ./src/linux/doc/man/ja/java.1 > ./src/bsd/doc/man/java.1 > ./src/bsd/doc/man/ja/java.1 > ./src/solaris/doc/sun/man/man1/java.1 > ./src/solaris/doc/sun/man/man1/ja/java.1 > > .. although I think there is also some HTML version maintained by > the pubs/docs team > that is not in OpenJDK - the above does not include Windows or Mac. > I don't know offhand what is recommended these days. We'll have to > find someone > who does more with the launcher to help point to where to do the > documentation. > > And the doc does not really explain what is going on here. Reading > that I might > think I am supposed to pass -splash:image at 2x.ext if I want a > hi-dpi image > and that is not the idea at all, is it ? > The idea is you would still specify -splash:image.ext and the > *implementation* > will look for the most appropriate scaled image for the current > desktop. > > I think we should also have a CCC cover this (somehow). > > -phil. > > > > > Thanks, > Alexandr. > > On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ > > > > Updates : > > 1)Updated the consition as suggested if(*scaleFactor - > (int)*scaleFactor < 0.000001) > > 2)Includes the changes of > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > > 3)+ //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > > > This change is required only for windows and linux. As we > use absolute system resolution for centring the splash on > screen on these. > > i.e. if system resolution is 1920 X 1080(i.e. unscaled > resolution) on windows and linux we use this for centring > the splash on screen. For mac scaled resolution is used > directly. > > Regards, > > Rajeev Chamyal > > *From:*Alexander Scherbatiy > *Sent:* 11 August 2016 14:44 > *To:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Philip Race; Sergey > Bylokhov > *Subject:* Re: [9] Review Request > JDK-8151787 Unify the HiDPI splash screen image naming > convention > > On 10/08/16 19:24, Alexandr Scherbatiy wrote: > > > > On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8151787 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ > > > > > Issue: Currently different naming conventions are > used for Hidpi image on different platforms. > > With this change the names will be unified across > all platforms. > > For a unscaled image image.ext following naming > convention will be followed. > > Unscaled name: image.ext > > Supported Scaled Names: > > If screen scale is integer number e.g. 2: > image at 2x.ext > > If screen scale is float value like 1.25: > image at 125pct.ext > > > The fix should be reviewed on the awt-dev alias. > > + if(*scaleFactor - (int)*scaleFactor < 0.000001) > > Should there be so high precision there? Could only > percent values be compared like > if ((*scaleFactor *100) != ((int)(*scaleFactor)) * > 100) > > > + //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > It looks like the splash coordinates and sizes are > rescaled in different places. Is it possible to do > that in the same place? May be in > java_awt_SplashScreen.c file getBounds() function? > > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > *scaleFactor = getNativeScaleFactor(); > > Could you also include the change which requires to add > some default output screen name to the > getNativeScaleFactor() function on Linux. There is the > discussion about that: > > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html > > Thanks, > Alexandr. > > > > > Thanks, > Alexandr. > > > > > Regards, > > Rajeev Chamyal > From Sergey.Bylokhov at oracle.com Mon Aug 22 11:22:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Aug 2016 14:22:01 +0300 Subject: [9] Review request for 8162840: Desktop. enableSuddenTermination() has no effect In-Reply-To: <2a74e07f-8206-bea3-bbd1-98e7c101ca54@oracle.com> References: <9b9b245b-b428-6de8-a2ed-c0fa29219ba5@oracle.com> <103d7dcb-f901-95f3-5073-d5c93760ee67@oracle.com> <2a74e07f-8206-bea3-bbd1-98e7c101ca54@oracle.com> Message-ID: <84a42c6b-395e-b1ba-d3a2-9a7e51e5c057@oracle.com> Ok, then the current fix looks fine. On 17.08.16 10:22, Yuri Nesterenko wrote: > In fact, we have a bunch of them in the func. workspace, > all more or less easily portable to jtreg. I'll move them in a bulk, > time permitting. > > -yan > > On 08/16/2016 07:47 PM, Alexander Zvegintsev wrote: >> Sure, but it is already created by Yuri and attached to the issue. >> >> I can include it with this fix, however as far I know SQE has a separate >> task to cover this JEP with tests and this test is a part of this task. >> >> >> On 8/16/16 7:27 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Is it possible to create a test for the fix? >>> >>> On 16.08.16 19:20, Alexander Zvegintsev wrote: >>>> Hello, >>>> >>>> >>>> please review the fix >>>> >>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8162840/00/ >>>> >>>> for the issue >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8162840 >>>> >>>> >>>> We don't call QuitHandler and using default QuitStrategy if sudden >>>> termination is enabled. >>>> >>>> >>> >>> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Aug 22 18:19:57 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 22 Aug 2016 21:19:57 +0300 Subject: [9] Review request for 8161910: [PIT] regression: HW/LW mixing seems broken on Unity Message-ID: <65b51ffb-cdbb-2ca1-c3b0-83b90b33e5d5@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8161910 webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/ A regression of the 8036915 in which a new frame dimensioning algo was introduced for the Unity WM because the latter differs from other WMs a lot. The algo has a flaw in some scenarios when the extent size event is delayed while the initial frame insets were established correctly, therefore the frame dimensions do not require any tuning. In this case the content window need to be notified right in the extent event handler to let the content to receive its new dimensions because subsequent XConfigureNotify event may be omitted. --Semyon From alexandr.scherbatiy at oracle.com Tue Aug 23 09:28:38 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 23 Aug 2016 13:28:38 +0400 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: On 22/08/16 11:06, Avik Niyogi wrote: > + 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. - I am not a native speaker. May be something like this would be better: ------ /** * This method is not supported by {@code AbstractMultiResolutionImage} * and always throws {@code UnsupportedOperationException} * * @return {@code UnsupportedOperationException} is thrown * @throws UnsupportedOperationException this method is not supported ------ - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) Thanks, Alexandr. >> >> With Regards, >> Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Tue Aug 23 10:27:32 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 23 Aug 2016 13:27:32 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog Message-ID: <57BC2514.8060906@oracle.com> Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8050478 webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ Problem description: Cursor is not updated correctly after closing a modal dialog. The root cause of the issue is lack of a mouse exit event during displaying of the modal dialog. Fix: It is necessary to generate MouseExited event for the window which is going to be blocked by the modal dialog. Thanks, Dmitry From Sergey.Bylokhov at oracle.com Tue Aug 23 19:01:14 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Aug 2016 22:01:14 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog In-Reply-To: <57BC2514.8060906@oracle.com> References: <57BC2514.8060906@oracle.com> Message-ID: <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> Why this event is not generated by the nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog? On 23.08.16 13:27, dmitry markov wrote: > Hello, > > Could you review a fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8050478 > webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ > > Problem description: > Cursor is not updated correctly after closing a modal dialog. The root > cause of the issue is lack of a mouse exit event during displaying of > the modal dialog. > > Fix: > It is necessary to generate MouseExited event for the window which is > going to be blocked by the modal dialog. > > Thanks, > Dmitry -- Best regards, Sergey. From james.graham at oracle.com Tue Aug 23 21:32:13 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 23 Aug 2016 14:32:13 -0700 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: I wonder why the @throws is not inherited...? Another way to fix this would be to implement it in the base Image class with the throw and all classes that can return a graphics override it. Then you wouldn't even need documentation in the AMRI class just to say "never mind we don't provide this method". The spec mentions that the method only works for off-screen images. While an AMRI may contain some off-screen images, it is not itself an off-screen so it should mention that. If we choose to list it in the methods in AMRI then I would just copy the entire comment from the super class Image and edit it based on the assumption that it is not supported for off-screen images, something like: /** * This inherited method can only be called for off-screen images, and throws * an exception in classes like this that do not support it. * @return there is no return value for a non-off-screen image. * @exception UnsupportedOperationException since this class does not represent * an off-screen image. */ ...jim On 8/23/16 2:28 AM, Alexander Scherbatiy wrote: > On 22/08/16 11:06, Avik Niyogi wrote: >> + 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. > - I am not a native speaker. May be something like this would be better: > ------ > /** > * This method is not supported by {@code AbstractMultiResolutionImage} > * and always throws {@code UnsupportedOperationException} > * > * @return {@code UnsupportedOperationException} is thrown > * @throws UnsupportedOperationException this method is not supported > ------ > > - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) > > Thanks, > Alexandr. > >>> >>> With Regards, >>> Avik Niyogi >> > From avik.niyogi at oracle.com Wed Aug 24 06:43:23 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 24 Aug 2016 12:13:23 +0530 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: <797449A8-4A5B-41A3-8798-FC3B0E2C0C5C@oracle.com> Hi Jim, Just a few queries I have regarding the inputs provided. I have added them inline in red. Thank you for further inputs in advance. > On 24-Aug-2016, at 3:02 am, Jim Graham wrote: > > I wonder why the @throws is not inherited...? > > Another way to fix this would be to implement it in the base Image class with the throw and all classes that can return a graphics override it. Then you wouldn't even need documentation in the AMRI class just to say "never mind we don't provide this method?. AN: According to the bug description as written by the JCK team, they are expecting a custom synopsis for all the overridden methods in the AMRI class. Is this absolutely necessary for the JCK implementation. Is the real reason that a custom documentation required or is the documentation derived not available while creating JCK tests and/or they are not apt descriptions for the JCK tests? Either ways, which way of documentation of the AMRI class seem most appropriate and which requirement mention should be given the right precedence? For example: For the getWidth(ImageObserver observer) method, the description which would have come in a new webrev would have been the following. /** * Returns the width of the base image. If the width is not yet known, * this method returns -1 and the specified * ImageObserver object is notified later. * @param observer an object waiting for the image to be loaded. * @return the width of this image, or -1 * if the width is not yet known. */ Does this look apposite for the AMRI class or does this seem ?too custom? for the worse? > The spec mentions that the method only works for off-screen images. While an AMRI may contain some off-screen images, it is not itself an off-screen so it should mention that. If we choose to list it in the methods in AMRI then I would just copy the entire comment from the super class Image and edit it based on the assumption that it is not supported for off-screen images, something like: > > /** > * This inherited method can only be called for off-screen images, and throws > * an exception in classes like this that do not support it. > * @return there is no return value for a non-off-screen image. > * @exception UnsupportedOperationException since this class does not represent AN: Is there any particular reason we need to use @exception and not @throws? Sorry if it seems like a novice question, but when is either one used and why is @throws not the right tag to use here? > * an off-screen image. > */ > > ...jim > > On 8/23/16 2:28 AM, Alexander Scherbatiy wrote: >> On 22/08/16 11:06, Avik Niyogi wrote: >>> + 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. >> - I am not a native speaker. May be something like this would be better: >> ------ >> /** >> * This method is not supported by {@code AbstractMultiResolutionImage} >> * and always throws {@code UnsupportedOperationException} >> * >> * @return {@code UnsupportedOperationException} is thrown >> * @throws UnsupportedOperationException this method is not supported >> ------ >> >> - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) >> >> Thanks, >> Alexandr. >> >>>> >>>> With Regards, >>>> Avik Niyogi >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Wed Aug 24 08:03:01 2016 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 24 Aug 2016 11:03:01 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog In-Reply-To: <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> References: <57BC2514.8060906@oracle.com> <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> Message-ID: <59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com> Hi Sergey, Thank you for the review. Actually the event is generated when the dialog is displayed, but it is discarded in deliverJavaMouseEvent() function (see AWTView.m) since the window is already disabled. When we are going to show a modal dialog we disable/block previously displayed windows via setModalBlocked() method. So we have to generate and send MouseExited event to the window before it is disabled/blocked by the modal dialog. Thanks, Dmitry > On 23 Aug 2016, at 22:01, Sergey Bylokhov wrote: > > Why this event is not generated by the nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog? > > On 23.08.16 13:27, dmitry markov wrote: >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8050478 >> webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ >> >> Problem description: >> Cursor is not updated correctly after closing a modal dialog. The root >> cause of the issue is lack of a mouse exit event during displaying of >> the modal dialog. >> >> Fix: >> It is necessary to generate MouseExited event for the window which is >> going to be blocked by the modal dialog. >> >> Thanks, >> Dmitry > > > -- > Best regards, Sergey. From semyon.sadetsky at oracle.com Wed Aug 24 13:24:02 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 24 Aug 2016 16:24:02 +0300 Subject: [9] Review request for 8161910: [PIT] regression: HW/LW mixing seems broken on Unity In-Reply-To: <65b51ffb-cdbb-2ca1-c3b0-83b90b33e5d5@oracle.com> References: <65b51ffb-cdbb-2ca1-c3b0-83b90b33e5d5@oracle.com> Message-ID: <83e3c1a9-128a-a13a-a486-8101952b3763@oracle.com> The fix was amended to http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.01/ Because Unity WM may change initial window location (for example when window overlaps desktop bars) I removed the optimization that skipped frame bounds revalidation in case of the initial frame insets was correct. This should guaranty the ConfigureNotify event always to come after the extent size event. --Semyon On 8/22/2016 9:19 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8161910 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/ > > A regression of the 8036915 in which a new frame dimensioning algo was > introduced for the Unity WM because the latter differs from other WMs > a lot. The algo has a flaw in some scenarios when the extent size > event is delayed while the initial frame insets were established > correctly, therefore the frame dimensions do not require any tuning. > In this case the content window need to be notified right in the > extent event handler to let the content to receive its new dimensions > because subsequent XConfigureNotify event may be omitted. > > --Semyon > > From Sergey.Bylokhov at oracle.com Wed Aug 24 15:27:12 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Aug 2016 18:27:12 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog In-Reply-To: <59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com> References: <57BC2514.8060906@oracle.com> <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> <59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com> Message-ID: Then I suggest to add a new method which will generate the EXIT before disable the window(I think it is better way?), or rename the current method since after the fix this is not a simple nativeSetEnabled() method. On 24.08.16 11:03, Dmitry Markov wrote: > Hi Sergey, > > Thank you for the review. > > Actually the event is generated when the dialog is displayed, but it is discarded in deliverJavaMouseEvent() function (see AWTView.m) since the window is already disabled. When we are going to show a modal dialog we disable/block previously displayed windows via setModalBlocked() method. So we have to generate and send MouseExited event to the window before it is disabled/blocked by the modal dialog. > > Thanks, > Dmitry >> On 23 Aug 2016, at 22:01, Sergey Bylokhov wrote: >> >> Why this event is not generated by the nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog? >> >> On 23.08.16 13:27, dmitry markov wrote: >>> Hello, >>> >>> Could you review a fix for jdk9, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8050478 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ >>> >>> Problem description: >>> Cursor is not updated correctly after closing a modal dialog. The root >>> cause of the issue is lack of a mouse exit event during displaying of >>> the modal dialog. >>> >>> Fix: >>> It is necessary to generate MouseExited event for the window which is >>> going to be blocked by the modal dialog. >>> >>> Thanks, >>> Dmitry >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Wed Aug 24 19:18:01 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 24 Aug 2016 22:18:01 +0300 Subject: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest Message-ID: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8159432 webrev: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.00/ The issue is connected to the restoring focus to the previously focused window when there are a lot of focus restore requests are coming very often (for example series of windows showing and hiding quickly). In this case waiting for asynchronous focus causes nested waiting loop, and if number of such requests is big enough the StackOverflowError is thrown. To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise. --Semyon From james.graham at oracle.com Wed Aug 24 22:46:03 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 24 Aug 2016 15:46:03 -0700 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: <797449A8-4A5B-41A3-8798-FC3B0E2C0C5C@oracle.com> References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> <797449A8-4A5B-41A3-8798-FC3B0E2C0C5C@oracle.com> Message-ID: Hi Avik, On 8/23/16 11:43 PM, Avik Niyogi wrote: > Hi Jim, > > Just a few queries I have regarding the inputs provided. I have added them inline in red. Thank you for further inputs > in advance. >> On 24-Aug-2016, at 3:02 am, Jim Graham > wrote: >> >> I wonder why the @throws is not inherited...? >> >> Another way to fix this would be to implement it in the base Image class with the throw and all classes that can >> return a graphics override it. Then you wouldn't even need documentation in the AMRI class just to say "never mind we >> don't provide this method?. > AN: According to the bug description as written by the JCK team, they are expecting a custom synopsis for all > the overridden methods in the AMRI class. Is this absolutely necessary for the JCK implementation. Is the real reason > that a custom documentation required or is the documentation derived not available while creating JCK tests and/or they > are not apt descriptions for the JCK tests? Either ways, which way of documentation of the AMRI class seem most > appropriate and which requirement mention should be given the right precedence? I don't have answers to your questions, I just know that the documentation that was inherited (which seems to have missed inheriting the thrown exceptions) contains no mention of the exception that will be thrown here. I also know that this method is not relevant to this type of image and the fact that we have to override it just to have it choose the escape clause inherent in the spec is silly. We beg the question by having to implement it and then explain that we are implementing it only to assert that it can't be implemented. That's a silly situation that should be instead handled by having the exception be the default implementation on the super class and have only those methods that can implement the behavior override it. If we have a concrete implementation in the base Image class then this method doesn't even appear in the documentation of the AMRI class in the first place (it appears in the list of inherited methods which has the full description). On the other hand, one could argue that the super class method is sort of vague in describing which types of image support the method and which do not. In that case, then I think it makes sense for AMRI to override it just to state its policy on whether one can get a graphics from it. If that is the route we go for this method then I think it makes sense to mention "why" we are throwing the exception rather than simply state that we are throwing it. > For example: > For the getWidth(ImageObserver observer) method, the description which would have come in a new webrev would have been > the following. > > /** > * Returns the width of the base image. If the width is not yet known, > * this method returns -1 and the specified > * ImageObserver object is notified later. > * @param observer an object waiting for the image to be loaded. > * @return the width of this image, or -1 > * if the width is not yet known. > */ > > Does this look apposite for the AMRI class or does this seem ?too custom? for the worse? Note that the AMRI class does provide a width and height so it does need to override these methods. Also, the return values from these methods are special in the case of an AMRI and so the exact behavior needs to be described in these methods (in particular, that the w/h of the base image is used). >> The spec mentions that the method only works for off-screen images. While an AMRI may contain some off-screen images, >> it is not itself an off-screen so it should mention that. If we choose to list it in the methods in AMRI then I would >> just copy the entire comment from the super class Image and edit it based on the assumption that it is not supported >> for off-screen images, something like: >> >> /** >> * This inherited method can only be called for off-screen images, and throws >> * an exception in classes like this that do not support it. >> * @return there is no return value for a non-off-screen image. >> * @exception UnsupportedOperationException since this class does not represent > AN: Is there any particular reason we need to use @exception and not @throws? > Sorry if it seems like a novice question, but when is either one used and why is @throws not the right tag to use here? I just copied and pasted from the source code for the Image.getGraphics() method and it used @exception. They are described as synonyms by the documentation on writing javadocs and I'm not sure whether we prefer one or the other. Phil might know the answer to that... ...jim >> * an off-screen image. >> */ >> >> ...jim From dmitry.markov at oracle.com Thu Aug 25 10:53:19 2016 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 25 Aug 2016 13:53:19 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog In-Reply-To: References: <57BC2514.8060906@oracle.com> <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> <59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com> Message-ID: Hi Sergey, I have updated the fix based on your suggestion, (i.e. add a new method). Please find a new version here: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.01/ Thanks, Dmitry > On 24 Aug 2016, at 18:27, Sergey Bylokhov wrote: > > Then I suggest to add a new method which will generate the EXIT before disable the window(I think it is better way?), or rename the current method since after the fix this is not a simple nativeSetEnabled() method. > > On 24.08.16 11:03, Dmitry Markov wrote: >> Hi Sergey, >> >> Thank you for the review. >> >> Actually the event is generated when the dialog is displayed, but it is discarded in deliverJavaMouseEvent() function (see AWTView.m) since the window is already disabled. When we are going to show a modal dialog we disable/block previously displayed windows via setModalBlocked() method. So we have to generate and send MouseExited event to the window before it is disabled/blocked by the modal dialog. >> >> Thanks, >> Dmitry >>> On 23 Aug 2016, at 22:01, Sergey Bylokhov wrote: >>> >>> Why this event is not generated by the nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog? >>> >>> On 23.08.16 13:27, dmitry markov wrote: >>>> Hello, >>>> >>>> Could you review a fix for jdk9, please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050478 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ >>>> >>>> Problem description: >>>> Cursor is not updated correctly after closing a modal dialog. The root >>>> cause of the issue is lack of a mouse exit event during displaying of >>>> the modal dialog. >>>> >>>> Fix: >>>> It is necessary to generate MouseExited event for the window which is >>>> going to be blocked by the modal dialog. >>>> >>>> Thanks, >>>> Dmitry >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Aug 25 14:54:00 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 25 Aug 2016 07:54:00 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> Message-ID: <479b4df5-e8f9-42dd-be67-31ec6112d3e5@default> Hello Phil, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ Regards, Rajeev Chamyal -----Original Message----- From: Rajeev Chamyal Sent: 22 August 2016 16:44 To: Philip Race Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: RE: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention Hello Phil, Thanks for the review, Please review updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ Updated files: src/java.base/share/classes/sun/launcher/resources/launcher.properties src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h Regards, Rajeev Chamyal -----Original Message----- From: Phil Race Sent: 20 August 2016 01:47 To: Rajeev Chamyal Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. -phil. On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ > > > Updated file > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Added all other supported name extensions. > > Regards, > > Rajeev Chamyal > > *From:*Philip Race > *Sent:* 19 August 2016 04:48 > *To:* Rajeev Chamyal > *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > Better, although it still does not document the supported set of scale > name extensions that we discussed/proposed off-line. > > -phil. > > On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: > > Hello Phil, > > Thanks for the review. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ > > > Updated file > > src/java.base/share/classes/sun/launcher/resources/launcher.properties > > Regards, > > Rajeev Chamyal > > *From:*Phil Race > *Sent:* 16 August 2016 22:28 > *To:* Alexandr Scherbatiy > *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8151787 > Unify the HiDPI splash screen image naming convention > > On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > It would be better if a native speaker look at the > documentation change in the launcher.properties file. > > > That documentation seems to cover only *some* of the extensions we > discussed. > It ought to cite all of them if it does so at all. How else are > people supposed > to know what they can use ? Where else are you documenting it? > Perhaps the launcher "man" page should be updated too > find . -name java.1 > ./src/linux/doc/man/java.1 > ./src/linux/doc/man/ja/java.1 > ./src/bsd/doc/man/java.1 > ./src/bsd/doc/man/ja/java.1 > ./src/solaris/doc/sun/man/man1/java.1 > ./src/solaris/doc/sun/man/man1/ja/java.1 > > .. although I think there is also some HTML version maintained by > the pubs/docs team > that is not in OpenJDK - the above does not include Windows or Mac. > I don't know offhand what is recommended these days. We'll have to > find someone > who does more with the launcher to help point to where to do the > documentation. > > And the doc does not really explain what is going on here. Reading > that I might > think I am supposed to pass -splash:image at 2x.ext if I want a > hi-dpi image > and that is not the idea at all, is it ? > The idea is you would still specify -splash:image.ext and the > *implementation* > will look for the most appropriate scaled image for the current > desktop. > > I think we should also have a CCC cover this (somehow). > > -phil. > > > > > Thanks, > Alexandr. > > On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ > > > > Updates : > > 1)Updated the consition as suggested if(*scaleFactor - > (int)*scaleFactor < 0.000001) > > 2)Includes the changes of > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > > 3)+ //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > > > This change is required only for windows and linux. As we > use absolute system resolution for centring the splash on > screen on these. > > i.e. if system resolution is 1920 X 1080(i.e. unscaled > resolution) on windows and linux we use this for centring > the splash on screen. For mac scaled resolution is used > directly. > > Regards, > > Rajeev Chamyal > > *From:*Alexander Scherbatiy > *Sent:* 11 August 2016 14:44 > *To:* Rajeev Chamyal; awt-dev at openjdk.java.net > ; Philip Race; Sergey > Bylokhov > *Subject:* Re: [9] Review Request > JDK-8151787 Unify the HiDPI splash screen image naming > convention > > On 10/08/16 19:24, Alexandr Scherbatiy wrote: > > > > On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8151787 > > Webrev: > > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ > > > > > Issue: Currently different naming conventions are > used for Hidpi image on different platforms. > > With this change the names will be unified across > all platforms. > > For a unscaled image image.ext following naming > convention will be followed. > > Unscaled name: image.ext > > Supported Scaled Names: > > If screen scale is integer number e.g. 2: > image at 2x.ext > > If screen scale is float value like 1.25: > image at 125pct.ext > > > The fix should be reviewed on the awt-dev alias. > > + if(*scaleFactor - (int)*scaleFactor < 0.000001) > > Should there be so high precision there? Could only > percent values be compared like > if ((*scaleFactor *100) != ((int)(*scaleFactor)) * > 100) > > > + //map the splash co-ordinates as per system scale > + splash->x /= splash->scaleFactor; > + splash->y /= splash->scaleFactor; > > It looks like the splash coordinates and sizes are > rescaled in different places. Is it possible to do > that in the same place? May be in > java_awt_SplashScreen.c file getBounds() function? > > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c > *scaleFactor = getNativeScaleFactor(); > > Could you also include the change which requires to add > some default output screen name to the > getNativeScaleFactor() function on Linux. There is the > discussion about that: > > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html > > Thanks, > Alexandr. > > > > > Thanks, > Alexandr. > > > > > Regards, > > Rajeev Chamyal > From alexandr.scherbatiy at oracle.com Thu Aug 25 16:17:02 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 25 Aug 2016 19:17:02 +0300 Subject: Review Request for 8160056: TextField.setText breaks the contract of EOL In-Reply-To: References: Message-ID: <536072a8-eb39-9a51-dc58-1ef68e1853f5@oracle.com> The fix looks good to me. Thanks, Alexandr. On 8/16/2016 1:16 PM, Ambarish Rapte wrote: > > Hi, > > Please review the change for JDK9, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160056 > > Webrev: > http://cr.openjdk.java.net/~arapte/8160056/webrev.00/ > > > Change Description: > > The TextField is a single line text component. > > If the input text contains new line characters then the character will > be replace by space character. > > TextField replaces EOL(platform specific) and > LF(\n) characters with space character. > > Information about LF character is not explicitly > mentioned in the java doc. > > Hence adding the missing description. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Aug 25 16:37:04 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 25 Aug 2016 19:37:04 +0300 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> Message-ID: <9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote: > Hello Phil, > > Thanks for the review, > Please review updated webrev. > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ > Updated files: > src/java.base/share/classes/sun/launcher/resources/launcher.properties > src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m > src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h? Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Phil Race > Sent: 20 August 2016 01:47 > To: Rajeev Chamyal > Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy > Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention > > I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. > > -phil. > > On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: >> Hello Phil, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ >> >> >> Updated file >> src/java.base/share/classes/sun/launcher/resources/launcher.properties >> >> Added all other supported name extensions. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Philip Race >> *Sent:* 19 August 2016 04:48 >> *To:* Rajeev Chamyal >> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy >> *Subject:* Re: [9] Review Request JDK-8151787 >> Unify the HiDPI splash screen image naming convention >> >> Better, although it still does not document the supported set of scale >> name extensions that we discussed/proposed off-line. >> >> -phil. >> >> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: >> >> Hello Phil, >> >> Thanks for the review. >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ >> >> >> Updated file >> >> src/java.base/share/classes/sun/launcher/resources/launcher.properties >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Phil Race >> *Sent:* 16 August 2016 22:28 >> *To:* Alexandr Scherbatiy >> *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net >> ; Sergey Bylokhov >> *Subject:* Re: [9] Review Request JDK-8151787 >> Unify the HiDPI splash screen image naming convention >> >> On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: >> >> >> The fix looks good to me. >> >> It would be better if a native speaker look at the >> documentation change in the launcher.properties file. >> >> >> That documentation seems to cover only *some* of the extensions we >> discussed. >> It ought to cite all of them if it does so at all. How else are >> people supposed >> to know what they can use ? Where else are you documenting it? >> Perhaps the launcher "man" page should be updated too >> find . -name java.1 >> ./src/linux/doc/man/java.1 >> ./src/linux/doc/man/ja/java.1 >> ./src/bsd/doc/man/java.1 >> ./src/bsd/doc/man/ja/java.1 >> ./src/solaris/doc/sun/man/man1/java.1 >> ./src/solaris/doc/sun/man/man1/ja/java.1 >> >> .. although I think there is also some HTML version maintained by >> the pubs/docs team >> that is not in OpenJDK - the above does not include Windows or Mac. >> I don't know offhand what is recommended these days. We'll have to >> find someone >> who does more with the launcher to help point to where to do the >> documentation. >> >> And the doc does not really explain what is going on here. Reading >> that I might >> think I am supposed to pass -splash:image at 2x.ext if I want a >> hi-dpi image >> and that is not the idea at all, is it ? >> The idea is you would still specify -splash:image.ext and the >> *implementation* >> will look for the most appropriate scaled image for the current >> desktop. >> >> I think we should also have a CCC cover this (somehow). >> >> -phil. >> >> >> >> >> Thanks, >> Alexandr. >> >> On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ >> >> >> >> Updates : >> >> 1)Updated the consition as suggested if(*scaleFactor - >> (int)*scaleFactor < 0.000001) >> >> 2)Includes the changes of >> >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> >> 3)+ //map the splash co-ordinates as per system scale >> + splash->x /= splash->scaleFactor; >> + splash->y /= splash->scaleFactor; >> >> >> >> This change is required only for windows and linux. As we >> use absolute system resolution for centring the splash on >> screen on these. >> >> i.e. if system resolution is 1920 X 1080(i.e. unscaled >> resolution) on windows and linux we use this for centring >> the splash on screen. For mac scaled resolution is used >> directly. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexander Scherbatiy >> *Sent:* 11 August 2016 14:44 >> *To:* Rajeev Chamyal; awt-dev at openjdk.java.net >> ; Philip Race; Sergey >> Bylokhov >> *Subject:* Re: [9] Review Request >> JDK-8151787 Unify the HiDPI splash screen image naming >> convention >> >> On 10/08/16 19:24, Alexandr Scherbatiy wrote: >> >> >> >> On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: >> >> Hello All, >> >> Please review the following webrev. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8151787 >> >> Webrev: >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ >> >> >> >> >> Issue: Currently different naming conventions are >> used for Hidpi image on different platforms. >> >> With this change the names will be unified across >> all platforms. >> >> For a unscaled image image.ext following naming >> convention will be followed. >> >> Unscaled name: image.ext >> >> Supported Scaled Names: >> >> If screen scale is integer number e.g. 2: >> image at 2x.ext >> >> If screen scale is float value like 1.25: >> image at 125pct.ext >> >> >> The fix should be reviewed on the awt-dev alias. >> >> + if(*scaleFactor - (int)*scaleFactor < 0.000001) >> >> Should there be so high precision there? Could only >> percent values be compared like >> if ((*scaleFactor *100) != ((int)(*scaleFactor)) * >> 100) >> >> >> + //map the splash co-ordinates as per system scale >> + splash->x /= splash->scaleFactor; >> + splash->y /= splash->scaleFactor; >> >> It looks like the splash coordinates and sizes are >> rescaled in different places. Is it possible to do >> that in the same place? May be in >> java_awt_SplashScreen.c file getBounds() function? >> >> >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> *scaleFactor = getNativeScaleFactor(); >> >> Could you also include the change which requires to add >> some default output screen name to the >> getNativeScaleFactor() function on Linux. There is the >> discussion about that: >> >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.html >> >> Thanks, >> Alexandr. >> >> >> >> >> Thanks, >> Alexandr. >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> From alexandr.scherbatiy at oracle.com Thu Aug 25 16:44:24 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 25 Aug 2016 19:44:24 +0300 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <57B34616.5030203@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> Message-ID: <81fe90cd-03d0-e66f-b4ca-9f0455bebffc@oracle.com> Hi Rajeev, You need to follow the following procedure for issues which require CCC request: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html - add jdk9-fc-request label to the JBS issue - update the JBS issue to add a comment whose first line is "FC Extension Request" - in that comment describe the remaining work to be done, the risk level, a brief justification, and your best estimate of the date by which the feature will be complete Thanks, Alexandr. On 8/16/2016 7:57 PM, Phil Race wrote: > I think we should also have a CCC cover this (somehow). > > -phil. From rajeev.chamyal at oracle.com Thu Aug 25 16:57:22 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 25 Aug 2016 09:57:22 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <81fe90cd-03d0-e66f-b4ca-9f0455bebffc@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <81fe90cd-03d0-e66f-b4ca-9f0455bebffc@oracle.com> Message-ID: <3d823b1f-0401-4d96-990a-9cf0df0c85cb@default> Hello Alexandr, As per the mail link the procedure is applicable for JEPs and small enhancements. http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html But the issue under review is a bug. Regards, Rajeev Chamyal -----Original Message----- From: Alexandr Scherbatiy Sent: 25 August 2016 22:14 To: Rajeev Chamyal Cc: Phil Race; awt-dev at openjdk.java.net; Sergey Bylokhov; Victor Dyakov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention Hi Rajeev, You need to follow the following procedure for issues which require CCC request: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html - add jdk9-fc-request label to the JBS issue - update the JBS issue to add a comment whose first line is "FC Extension Request" - in that comment describe the remaining work to be done, the risk level, a brief justification, and your best estimate of the date by which the feature will be complete Thanks, Alexandr. On 8/16/2016 7:57 PM, Phil Race wrote: > I think we should also have a CCC cover this (somehow). > > -phil. From alexander.zvegintsev at oracle.com Fri Aug 26 02:53:33 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 26 Aug 2016 05:53:33 +0300 Subject: [9] Review request 8155083: On Windows, usage of USER_ATTENTION_WINDOW depends on state setting order Message-ID: <37de76bc-4698-e716-6779-9e5acfa0f49f@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8155083/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8155083 With current implementation we are showing initially iconified window with SW_SHOWMINIMIZED flag, it activates the window, FlashWindowEx doesn't work with active window. We could use SW_SHOWMINNOACTIVE instead, but there is another issue: if app has more than one window it doesn't work either. The fix it to use FlashWindow(). -- -- Thanks, Alexander. From rajeev.chamyal at oracle.com Fri Aug 26 06:49:41 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 25 Aug 2016 23:49:41 -0700 (PDT) Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> <9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com> Message-ID: Hello Alexandr, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/ Regards, Rajeev Chamyal -----Original Message----- From: Alexandr Scherbatiy Sent: 25 August 2016 22:07 To: Rajeev Chamyal; Philip Race Cc: awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention On 8/22/2016 2:13 PM, Rajeev Chamyal wrote: > Hello Phil, > > Thanks for the review, > Please review updated webrev. > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ > Updated files: > src/java.base/share/classes/sun/launcher/resources/launcher.properties > src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m > src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h? Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Phil Race > Sent: 20 August 2016 01:47 > To: Rajeev Chamyal > Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy > Subject: Re: [9] Review Request JDK-8151787 Unify > the HiDPI splash screen image naming convention > > I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. > > -phil. > > On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: >> Hello Phil, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ >> >> >> Updated file >> src/java.base/share/classes/sun/launcher/resources/launcher.propertie >> s >> >> Added all other supported name extensions. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Philip Race >> *Sent:* 19 August 2016 04:48 >> *To:* Rajeev Chamyal >> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy >> *Subject:* Re: [9] Review Request JDK-8151787 >> Unify the HiDPI splash screen image naming convention >> >> Better, although it still does not document the supported set of >> scale name extensions that we discussed/proposed off-line. >> >> -phil. >> >> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: >> >> Hello Phil, >> >> Thanks for the review. >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ >> >> >> Updated file >> >> src/java.base/share/classes/sun/launcher/resources/launcher.propertie >> s >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Phil Race >> *Sent:* 16 August 2016 22:28 >> *To:* Alexandr Scherbatiy >> *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net >> ; Sergey Bylokhov >> *Subject:* Re: [9] Review Request JDK-8151787 >> Unify the HiDPI splash screen image naming convention >> >> On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: >> >> >> The fix looks good to me. >> >> It would be better if a native speaker look at the >> documentation change in the launcher.properties file. >> >> >> That documentation seems to cover only *some* of the extensions we >> discussed. >> It ought to cite all of them if it does so at all. How else are >> people supposed >> to know what they can use ? Where else are you documenting it? >> Perhaps the launcher "man" page should be updated too >> find . -name java.1 >> ./src/linux/doc/man/java.1 >> ./src/linux/doc/man/ja/java.1 >> ./src/bsd/doc/man/java.1 >> ./src/bsd/doc/man/ja/java.1 >> ./src/solaris/doc/sun/man/man1/java.1 >> ./src/solaris/doc/sun/man/man1/ja/java.1 >> >> .. although I think there is also some HTML version maintained by >> the pubs/docs team >> that is not in OpenJDK - the above does not include Windows or Mac. >> I don't know offhand what is recommended these days. We'll have to >> find someone >> who does more with the launcher to help point to where to do the >> documentation. >> >> And the doc does not really explain what is going on here. Reading >> that I might >> think I am supposed to pass -splash:image at 2x.ext if I want a >> hi-dpi image >> and that is not the idea at all, is it ? >> The idea is you would still specify -splash:image.ext and the >> *implementation* >> will look for the most appropriate scaled image for the current >> desktop. >> >> I think we should also have a CCC cover this (somehow). >> >> -phil. >> >> >> >> >> Thanks, >> Alexandr. >> >> On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ >> >> >> >> Updates : >> >> 1)Updated the consition as suggested if(*scaleFactor - >> (int)*scaleFactor < 0.000001) >> >> 2)Includes the changes of >> >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> >> 3)+ //map the splash co-ordinates as per system scale >> + splash->x /= splash->scaleFactor; >> + splash->y /= splash->scaleFactor; >> >> >> >> This change is required only for windows and linux. As we >> use absolute system resolution for centring the splash on >> screen on these. >> >> i.e. if system resolution is 1920 X 1080(i.e. unscaled >> resolution) on windows and linux we use this for centring >> the splash on screen. For mac scaled resolution is used >> directly. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexander Scherbatiy >> *Sent:* 11 August 2016 14:44 >> *To:* Rajeev Chamyal; awt-dev at openjdk.java.net >> ; Philip Race; Sergey >> Bylokhov >> *Subject:* Re: [9] Review Request >> JDK-8151787 Unify the HiDPI splash screen image naming >> convention >> >> On 10/08/16 19:24, Alexandr Scherbatiy wrote: >> >> >> >> On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: >> >> Hello All, >> >> Please review the following webrev. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8151787 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ >> >> >> >> >> Issue: Currently different naming conventions are >> used for Hidpi image on different platforms. >> >> With this change the names will be unified across >> all platforms. >> >> For a unscaled image image.ext following naming >> convention will be followed. >> >> Unscaled name: image.ext >> >> Supported Scaled Names: >> >> If screen scale is integer number e.g. 2: >> image at 2x.ext >> >> If screen scale is float value like 1.25: >> image at 125pct.ext >> >> >> The fix should be reviewed on the awt-dev alias. >> >> + if(*scaleFactor - (int)*scaleFactor < 0.000001) >> >> Should there be so high precision there? Could only >> percent values be compared like >> if ((*scaleFactor *100) != ((int)(*scaleFactor)) * >> 100) >> >> >> + //map the splash co-ordinates as per system scale >> + splash->x /= splash->scaleFactor; >> + splash->y /= splash->scaleFactor; >> >> It looks like the splash coordinates and sizes are >> rescaled in different places. Is it possible to do >> that in the same place? May be in >> java_awt_SplashScreen.c file getBounds() function? >> >> >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >> *scaleFactor = getNativeScaleFactor(); >> >> Could you also include the change which requires to add >> some default output screen name to the >> getNativeScaleFactor() function on Linux. There is the >> discussion about that: >> >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.htm >> l >> >> Thanks, >> Alexandr. >> >> >> >> >> Thanks, >> Alexandr. >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> From alexandr.scherbatiy at oracle.com Fri Aug 26 08:43:30 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 26 Aug 2016 11:43:30 +0300 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: <3d823b1f-0401-4d96-990a-9cf0df0c85cb@default> References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <81fe90cd-03d0-e66f-b4ca-9f0455bebffc@oracle.com> <3d823b1f-0401-4d96-990a-9cf0df0c85cb@default> Message-ID: On 8/25/2016 7:57 PM, Rajeev Chamyal wrote: > Hello Alexandr, > > As per the mail link the procedure is applicable for JEPs and small enhancements. > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > But the issue under review is a bug. Then it is fine. Thanks, Alexandr. > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: 25 August 2016 22:14 > To: Rajeev Chamyal > Cc: Phil Race; awt-dev at openjdk.java.net; Sergey Bylokhov; Victor Dyakov > Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention > > > Hi Rajeev, > > You need to follow the following procedure for issues which require CCC > request: > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > > - add jdk9-fc-request label to the JBS issue > - update the JBS issue to add a comment whose first line is "FC Extension Request" > - in that comment describe the remaining work to be done, the risk level, a brief justification, and your best estimate of the date by which the feature will be complete > > Thanks, > Alexandr. > > On 8/16/2016 7:57 PM, Phil Race wrote: >> I think we should also have a CCC cover this (somehow). >> >> -phil. From alexandr.scherbatiy at oracle.com Fri Aug 26 08:53:27 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 26 Aug 2016 11:53:27 +0300 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> <9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com> Message-ID: <35de9cd3-7d0e-aac7-3f47-597343062ff8@oracle.com> On 8/26/2016 9:49 AM, Rajeev Chamyal wrote: > Hello Alexandr, > > Please review the updated webrev. > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/ The part which does not relate to the updated documentation looks good to me. Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: 25 August 2016 22:07 > To: Rajeev Chamyal; Philip Race > Cc: awt-dev at openjdk.java.net; Sergey Bylokhov > Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention > > On 8/22/2016 2:13 PM, Rajeev Chamyal wrote: >> Hello Phil, >> >> Thanks for the review, >> Please review updated webrev. >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ >> Updated files: >> src/java.base/share/classes/sun/launcher/resources/launcher.properties >> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m >> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h > The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h? > > Thanks, > Alexandr. > >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Phil Race >> Sent: 20 August 2016 01:47 >> To: Rajeev Chamyal >> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy >> Subject: Re: [9] Review Request JDK-8151787 Unify >> the HiDPI splash screen image naming convention >> >> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. >> >> -phil. >> >> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: >>> Hello Phil, >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ >>> >>> >>> Updated file >>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie >>> s >>> >>> Added all other supported name extensions. >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Philip Race >>> *Sent:* 19 August 2016 04:48 >>> *To:* Rajeev Chamyal >>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy >>> *Subject:* Re: [9] Review Request JDK-8151787 >>> Unify the HiDPI splash screen image naming convention >>> >>> Better, although it still does not document the supported set of >>> scale name extensions that we discussed/proposed off-line. >>> >>> -phil. >>> >>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: >>> >>> Hello Phil, >>> >>> Thanks for the review. >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ >>> >>> >>> Updated file >>> >>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie >>> s >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Phil Race >>> *Sent:* 16 August 2016 22:28 >>> *To:* Alexandr Scherbatiy >>> *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net >>> ; Sergey Bylokhov >>> *Subject:* Re: [9] Review Request JDK-8151787 >>> Unify the HiDPI splash screen image naming convention >>> >>> On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: >>> >>> >>> The fix looks good to me. >>> >>> It would be better if a native speaker look at the >>> documentation change in the launcher.properties file. >>> >>> >>> That documentation seems to cover only *some* of the extensions we >>> discussed. >>> It ought to cite all of them if it does so at all. How else are >>> people supposed >>> to know what they can use ? Where else are you documenting it? >>> Perhaps the launcher "man" page should be updated too >>> find . -name java.1 >>> ./src/linux/doc/man/java.1 >>> ./src/linux/doc/man/ja/java.1 >>> ./src/bsd/doc/man/java.1 >>> ./src/bsd/doc/man/ja/java.1 >>> ./src/solaris/doc/sun/man/man1/java.1 >>> ./src/solaris/doc/sun/man/man1/ja/java.1 >>> >>> .. although I think there is also some HTML version maintained by >>> the pubs/docs team >>> that is not in OpenJDK - the above does not include Windows or Mac. >>> I don't know offhand what is recommended these days. We'll have to >>> find someone >>> who does more with the launcher to help point to where to do the >>> documentation. >>> >>> And the doc does not really explain what is going on here. Reading >>> that I might >>> think I am supposed to pass -splash:image at 2x.ext if I want a >>> hi-dpi image >>> and that is not the idea at all, is it ? >>> The idea is you would still specify -splash:image.ext and the >>> *implementation* >>> will look for the most appropriate scaled image for the current >>> desktop. >>> >>> I think we should also have a CCC cover this (somehow). >>> >>> -phil. >>> >>> >>> >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: >>> >>> Hello Alexandr, >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ >>> >>> >>> >>> Updates : >>> >>> 1)Updated the consition as suggested if(*scaleFactor - >>> (int)*scaleFactor < 0.000001) >>> >>> 2)Includes the changes of >>> >>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >>> >>> 3)+ //map the splash co-ordinates as per system scale >>> + splash->x /= splash->scaleFactor; >>> + splash->y /= splash->scaleFactor; >>> >>> >>> >>> This change is required only for windows and linux. As we >>> use absolute system resolution for centring the splash on >>> screen on these. >>> >>> i.e. if system resolution is 1920 X 1080(i.e. unscaled >>> resolution) on windows and linux we use this for centring >>> the splash on screen. For mac scaled resolution is used >>> directly. >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Alexander Scherbatiy >>> *Sent:* 11 August 2016 14:44 >>> *To:* Rajeev Chamyal; awt-dev at openjdk.java.net >>> ; Philip Race; Sergey >>> Bylokhov >>> *Subject:* Re: [9] Review Request >>> JDK-8151787 Unify the HiDPI splash screen image naming >>> convention >>> >>> On 10/08/16 19:24, Alexandr Scherbatiy wrote: >>> >>> >>> >>> On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: >>> >>> Hello All, >>> >>> Please review the following webrev. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8151787 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ >>> >>> >>> >>> >>> Issue: Currently different naming conventions are >>> used for Hidpi image on different platforms. >>> >>> With this change the names will be unified across >>> all platforms. >>> >>> For a unscaled image image.ext following naming >>> convention will be followed. >>> >>> Unscaled name: image.ext >>> >>> Supported Scaled Names: >>> >>> If screen scale is integer number e.g. 2: >>> image at 2x.ext >>> >>> If screen scale is float value like 1.25: >>> image at 125pct.ext >>> >>> >>> The fix should be reviewed on the awt-dev alias. >>> >>> + if(*scaleFactor - (int)*scaleFactor < 0.000001) >>> >>> Should there be so high precision there? Could only >>> percent values be compared like >>> if ((*scaleFactor *100) != ((int)(*scaleFactor)) * >>> 100) >>> >>> >>> + //map the splash co-ordinates as per system scale >>> + splash->x /= splash->scaleFactor; >>> + splash->y /= splash->scaleFactor; >>> >>> It looks like the splash coordinates and sizes are >>> rescaled in different places. Is it possible to do >>> that in the same place? May be in >>> java_awt_SplashScreen.c file getBounds() function? >>> >>> >>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >>> *scaleFactor = getNativeScaleFactor(); >>> >>> Could you also include the change which requires to add >>> some default output screen name to the >>> getNativeScaleFactor() function on Linux. There is the >>> discussion about that: >>> >>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.htm >>> l >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> Regards, >>> >>> Rajeev Chamyal >>> From philip.race at oracle.com Fri Aug 26 21:40:21 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 26 Aug 2016 14:40:21 -0700 Subject: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention In-Reply-To: References: <653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com> <5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com> <020c37cc-c9af-4790-a591-29b71b410533@default> <6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com> <57B34616.5030203@oracle.com> <434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default> <57B64223.8090304@oracle.com> <420cab11-7fec-4e12-a053-79ff9a1e1cd8@default> <16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com> <9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com> Message-ID: <57C0B745.3040601@oracle.com> Seems fine now. 1) Please do a CCC for this 2) Please file a doc. bug so docs team can update the HTML man page and also perhaps https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html -phil On 8/25/16, 11:49 PM, Rajeev Chamyal wrote: > Hello Alexandr, > > Please review the updated webrev. > http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/ > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: 25 August 2016 22:07 > To: Rajeev Chamyal; Philip Race > Cc: awt-dev at openjdk.java.net; Sergey Bylokhov > Subject: Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention > > On 8/22/2016 2:13 PM, Rajeev Chamyal wrote: >> Hello Phil, >> >> Thanks for the review, >> Please review updated webrev. >> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/ >> Updated files: >> src/java.base/share/classes/sun/launcher/resources/launcher.properties >> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m >> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h > The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h? > > Thanks, > Alexandr. > >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Phil Race >> Sent: 20 August 2016 01:47 >> To: Rajeev Chamyal >> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy >> Subject: Re: [9] Review Request JDK-8151787 Unify >> the HiDPI splash screen image naming convention >> >> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax. >> >> -phil. >> >> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote: >>> Hello Phil, >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/ >>> >>> >>> Updated file >>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie >>> s >>> >>> Added all other supported name extensions. >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Philip Race >>> *Sent:* 19 August 2016 04:48 >>> *To:* Rajeev Chamyal >>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy >>> *Subject:* Re: [9] Review Request JDK-8151787 >>> Unify the HiDPI splash screen image naming convention >>> >>> Better, although it still does not document the supported set of >>> scale name extensions that we discussed/proposed off-line. >>> >>> -phil. >>> >>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote: >>> >>> Hello Phil, >>> >>> Thanks for the review. >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ >>> >>> >>> Updated file >>> >>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie >>> s >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Phil Race >>> *Sent:* 16 August 2016 22:28 >>> *To:* Alexandr Scherbatiy >>> *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net >>> ; Sergey Bylokhov >>> *Subject:* Re: [9] Review Request JDK-8151787 >>> Unify the HiDPI splash screen image naming convention >>> >>> On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote: >>> >>> >>> The fix looks good to me. >>> >>> It would be better if a native speaker look at the >>> documentation change in the launcher.properties file. >>> >>> >>> That documentation seems to cover only *some* of the extensions we >>> discussed. >>> It ought to cite all of them if it does so at all. How else are >>> people supposed >>> to know what they can use ? Where else are you documenting it? >>> Perhaps the launcher "man" page should be updated too >>> find . -name java.1 >>> ./src/linux/doc/man/java.1 >>> ./src/linux/doc/man/ja/java.1 >>> ./src/bsd/doc/man/java.1 >>> ./src/bsd/doc/man/ja/java.1 >>> ./src/solaris/doc/sun/man/man1/java.1 >>> ./src/solaris/doc/sun/man/man1/ja/java.1 >>> >>> .. although I think there is also some HTML version maintained by >>> the pubs/docs team >>> that is not in OpenJDK - the above does not include Windows or Mac. >>> I don't know offhand what is recommended these days. We'll have to >>> find someone >>> who does more with the launcher to help point to where to do the >>> documentation. >>> >>> And the doc does not really explain what is going on here. Reading >>> that I might >>> think I am supposed to pass -splash:image at 2x.ext if I want a >>> hi-dpi image >>> and that is not the idea at all, is it ? >>> The idea is you would still specify -splash:image.ext and the >>> *implementation* >>> will look for the most appropriate scaled image for the current >>> desktop. >>> >>> I think we should also have a CCC cover this (somehow). >>> >>> -phil. >>> >>> >>> >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/16/2016 8:26 AM, Rajeev Chamyal wrote: >>> >>> Hello Alexandr, >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/ >>> >>> >>> >>> Updates : >>> >>> 1)Updated the consition as suggested if(*scaleFactor - >>> (int)*scaleFactor< 0.000001) >>> >>> 2)Includes the changes of >>> >>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >>> >>> 3)+ //map the splash co-ordinates as per system scale >>> + splash->x /= splash->scaleFactor; >>> + splash->y /= splash->scaleFactor; >>> >>> >>> >>> This change is required only for windows and linux. As we >>> use absolute system resolution for centring the splash on >>> screen on these. >>> >>> i.e. if system resolution is 1920 X 1080(i.e. unscaled >>> resolution) on windows and linux we use this for centring >>> the splash on screen. For mac scaled resolution is used >>> directly. >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Alexander Scherbatiy >>> *Sent:* 11 August 2016 14:44 >>> *To:* Rajeev Chamyal; awt-dev at openjdk.java.net >>> ; Philip Race; Sergey >>> Bylokhov >>> *Subject:* Re: [9] Review Request >>> JDK-8151787 Unify the HiDPI splash screen image naming >>> convention >>> >>> On 10/08/16 19:24, Alexandr Scherbatiy wrote: >>> >>> >>> >>> On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: >>> >>> Hello All, >>> >>> Please review the following webrev. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8151787 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/ >>> >>> >>> >>> >>> Issue: Currently different naming conventions are >>> used for Hidpi image on different platforms. >>> >>> With this change the names will be unified across >>> all platforms. >>> >>> For a unscaled image image.ext following naming >>> convention will be followed. >>> >>> Unscaled name: image.ext >>> >>> Supported Scaled Names: >>> >>> If screen scale is integer number e.g. 2: >>> image at 2x.ext >>> >>> If screen scale is float value like 1.25: >>> image at 125pct.ext >>> >>> >>> The fix should be reviewed on the awt-dev alias. >>> >>> + if(*scaleFactor - (int)*scaleFactor< 0.000001) >>> >>> Should there be so high precision there? Could only >>> percent values be compared like >>> if ((*scaleFactor *100) != ((int)(*scaleFactor)) * >>> 100) >>> >>> >>> + //map the splash co-ordinates as per system scale >>> + splash->x /= splash->scaleFactor; >>> + splash->y /= splash->scaleFactor; >>> >>> It looks like the splash coordinates and sizes are >>> rescaled in different places. Is it possible to do >>> that in the same place? May be in >>> java_awt_SplashScreen.c file getBounds() function? >>> >>> >>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c >>> *scaleFactor = getNativeScaleFactor(); >>> >>> Could you also include the change which requires to add >>> some default output screen name to the >>> getNativeScaleFactor() function on Linux. There is the >>> discussion about that: >>> >>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.htm >>> l >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> Regards, >>> >>> Rajeev Chamyal >>> From philip.race at oracle.com Fri Aug 26 21:47:41 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Aug 2016 14:47:41 -0700 Subject: RFR: 8164899: Provide package access to setComponentMixingCutoutShape Message-ID: <57C0B8FD.3000805@oracle.com> bug : https://bugs.openjdk.java.net/browse/JDK-8164899 webrev: http://cr.openjdk.java.net/~prr/8164899/ Transitional support for this API in jigsaw mode. It is not public but it is more accessible than it was .. -phil. From avik.niyogi at oracle.com Mon Aug 29 06:52:11 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 29 Aug 2016 12:22:11 +0530 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: Hi All, Please review the proposed specification for JDK9 including inputs from reviver reviews. http://cr.openjdk.java.net/~aniyogi/8138771/webrev.01/ Thank you in advance. With Regards, Avik Niyogi > On 23-Aug-2016, at 2:58 pm, Alexander Scherbatiy wrote: > > On 22/08/16 11:06, Avik Niyogi wrote: >> + 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. > - I am not a native speaker. May be something like this would be better: > ------ > /** > * This method is not supported by {@code AbstractMultiResolutionImage} > * and always throws {@code UnsupportedOperationException} > * > * @return {@code UnsupportedOperationException} is thrown > * @throws UnsupportedOperationException this method is not supported > ------ > > - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) > > Thanks, > Alexandr. > >>> >>> With Regards, >>> Avik Niyogi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at tagtraum.com Mon Aug 29 10:30:14 2016 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 29 Aug 2016 12:30:14 +0200 Subject: [9] Review request for JDK-8156099: [macosx] Drag and drop of link from web browser, DataFlavor types application/x-java-url and text/uri-list, getTransferData returns null In-Reply-To: References: <05C51CD9-68D6-4F5C-ACE8-50B4C155ADC1@oracle.com> <1df6d9f6-7c48-5a7e-c591-89b51c0e60ce@oracle.com> <0a9646f2-f141-845d-4411-0a5c6536e1aa@oracle.com> Message-ID: <9251A9EC-8952-4778-AF04-9C64AF1885D6@tagtraum.com> A little late, but in the fix for CDataTransferer.java charset = new String((byte[]) transferable.getTransferData(javaTextEncodingFlavor), "UTF-8?); should probably be import java.nio.charset.StandardCharsets; [...] charset = new String((byte[]) transferable.getTransferData(javaTextEncodingFlavor), StandardCharsets.UTF_8); to avoid the unnecessary charset lookup. And I know, this is only a minor detail and does not make a big diff. Just trying to improve the codebase. I?m grateful this has finally been addressed and am very much looking forward to the backport to JDK8! Cheers, -hendrik > On Aug 20, 2016, at 13:11, Sergey Bylokhov wrote: > > +1 > > On 18.08.16 14:55, Manajit Halder wrote: >> Hi Sergey, >> >> Thank you for the review. I have modified the code as per your comment. >> http://cr.openjdk.java.net/~mhalder/8156099/webrev.02/ >> >> Thanks, >> Manajit >> >>> On 18-Aug-2016, at 2:58 pm, Sergey Bylokhov >>> > wrote: >>> >>> Looks fine. >>> please change the title of the frame to some text related to this fix, >>> instead of "Updating TrayIcon Popup Menu Item Test" >>> >>> On 14.08.16 23:50, Manajit Halder wrote: >>>> Hi Sergey, >>>> >>>> Thank you for your review comments. >>>> >>>> I have modified the code as per your first two comments. >>>> For the last comment the fix was tested with JDK versions b123, b124, >>>> b125, b127 and b130 and >>>> the test failed with the popup message. >>>> >>>> Please review the modified review. >>>> http://cr.openjdk.java.net/~mhalder/8156099/webrev.01/ >>>> >>>> Thanks, >>>> Manajit >>>> >>>>> On 09-Aug-2016, at 9:41 pm, Sergey Bylokhov >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi, Manajit. >>>>> - Its seems that the test creates the Swing components on non-EDT. >>>>> - The instructions are a little bit misleading, because popup will be >>>>> shown even when the test is passed. >>>>> - When I run the test on the current client ws, it is passed. Can you >>>>> please double check that the test fails before the fix. >>>>> >>>>> On 01.08.16 12:35, Manajit Halder wrote: >>>>>> Hi All, >>>>>> >>>>>> Kindly review the fix for JDK9. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8156099 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mhalder/8156099/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> [macosx] Drag and drop of link from web browser, DataFlavor types >>>>>> application/x-java-url and text/uri-list, getTransferData returns null >>>>>> >>>>>> Cause: >>>>>> This issue is a regression of issue >>>>>> https://bugs.openjdk.java.net/browse/JDK-8136763. >>>>>> While adding fix to 8136763 code was modified to handle coping of >>>>>> multiple files but proper distinction was not added between bytes >>>>>> containing files and urls. >>>>>> >>>>>> Fix: >>>>>> Fixed by comparing format of the bytes received for dataflavor >>>>>> "mimetype=text/uri-list". >>>>>> Fixed by distinguishing between bytes containing files and urls. In >>>>>> both >>>>>> cases the dataflavor contains same ?mimetype=text/uri-list?, but the >>>>>> format is different. >>>>>> Format CF_FILE is only used in case of bytes containing files. >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From alexandr.scherbatiy at oracle.com Mon Aug 29 12:25:18 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 29 Aug 2016 15:25:18 +0300 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: <50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com> On 8/29/2016 9:52 AM, Avik Niyogi wrote: > Hi All, > > Please review the proposed specification for JDK9 including inputs > from reviver reviews. > > *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.01/ > * > There is the {@inheritDoc} which allows to use a javadoc from the parent method. Javadoc for AbstractMultiResolutionImage.getWidth()/getHeight()/getSource()/getProperty() could be like: /** * This method simply delegates to the {@code getBaseImage()}. * It is equivalent to: {@code getBaseImage().getWidth(observer)). * * @see #getBaseImage * * @since 9 */ Thanks, Alexandr. > Thank you in advance. > > With Regards, > Avik Niyogi > >> On 23-Aug-2016, at 2:58 pm, Alexander Scherbatiy >> > > wrote: >> >> On 22/08/16 11:06, Avik Niyogi wrote: >>> + 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. >> - I am not a native speaker. May be something like this would be better: >> ------ >> /** >> * This method is not supported by {@code >> AbstractMultiResolutionImage} >> * and always throws {@code UnsupportedOperationException} >> * >> * @return {@code UnsupportedOperationException} is thrown >> * @throws UnsupportedOperationException this method is not supported >> ------ >> >> - others overridden method should have a documentation that they >> delegate call to the base image (see #getBaseImage) >> >> Thanks, >> Alexandr. >> >>>> >>>> With Regards, >>>> Avik Niyogi >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Aug 29 12:34:14 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 15:34:14 +0300 Subject: Review Request for 8160056: TextField.setText breaks the contract of EOL In-Reply-To: <536072a8-eb39-9a51-dc58-1ef68e1853f5@oracle.com> References: <536072a8-eb39-9a51-dc58-1ef68e1853f5@oracle.com> Message-ID: +1 On 25.08.16 19:17, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/16/2016 1:16 PM, Ambarish Rapte wrote: >> >> Hi, >> >> Please review the change for JDK9, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160056 >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/8160056/webrev.00/ >> >> >> >> >> >> >> Change Description: >> >> >> >> The TextField is a single line text component. >> >> If the input text contains new line characters then the character will >> be replace by space character. >> >> >> >> TextField replaces EOL(platform specific) and >> LF(\n) characters with space character. >> >> Information about LF character is not explicitly >> mentioned in the java doc. >> >> Hence adding the missing description. >> >> >> >> >> >> Regards, >> >> Ambarish >> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Aug 29 15:53:28 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 18:53:28 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog In-Reply-To: References: <57BC2514.8060906@oracle.com> <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> <59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com> Message-ID: Looks fine. On 25.08.16 13:53, Dmitry Markov wrote: > Hi Sergey, > > I have updated the fix based on your suggestion, (i.e. add a new > method). Please find a new version here: > http://cr.openjdk.java.net/~dmarkov/8050478/webrev.01/ > > Thanks, > Dmitry >> On 24 Aug 2016, at 18:27, Sergey Bylokhov > > wrote: >> >> Then I suggest to add a new method which will generate the EXIT before >> disable the window(I think it is better way?), or rename the current >> method since after the fix this is not a simple nativeSetEnabled() method. >> >> On 24.08.16 11:03, Dmitry Markov wrote: >>> Hi Sergey, >>> >>> Thank you for the review. >>> >>> Actually the event is generated when the dialog is displayed, but it >>> is discarded in deliverJavaMouseEvent() function (see AWTView.m) >>> since the window is already disabled. When we are going to show a >>> modal dialog we disable/block previously displayed windows via >>> setModalBlocked() method. So we have to generate and send MouseExited >>> event to the window before it is disabled/blocked by the modal dialog. >>> >>> Thanks, >>> Dmitry >>>> On 23 Aug 2016, at 22:01, Sergey Bylokhov >>>> > wrote: >>>> >>>> Why this event is not generated by the >>>> nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog? >>>> >>>> On 23.08.16 13:27, dmitry markov wrote: >>>>> Hello, >>>>> >>>>> Could you review a fix for jdk9, please? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050478 >>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ >>>>> >>>>> Problem description: >>>>> Cursor is not updated correctly after closing a modal dialog. The root >>>>> cause of the issue is lack of a mouse exit event during displaying of >>>>> the modal dialog. >>>>> >>>>> Fix: >>>>> It is necessary to generate MouseExited event for the window which is >>>>> going to be blocked by the modal dialog. >>>>> >>>>> Thanks, >>>>> Dmitry >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Aug 29 16:30:42 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 29 Aug 2016 19:30:42 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> Message-ID: Hi Anton, is it really OS X only problem? It seems on other platforms the peer focusability is updated in the same way. --Semyon On 6/29/2016 9:04 PM, Anton Tarasov wrote: > Hello, > > Please review the fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8160570 > webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 > > > The problem is that a modal dialog can skip the activation/focus > events on OSX. > The fix is to cache the focusability state of the Window peer earlier, > in its ctor. > Please find more details in JIRA. > > Thanks, > Anton. From anton.tarasov at jetbrains.com Mon Aug 29 17:29:10 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 29 Aug 2016 20:29:10 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> Message-ID: <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> Hi Semyon, As I wrote in JIRA, the problem is caused by the fact that a native window (for a modal dialog) is shown before the peer starts to show. (This seems strange, and you can investigate the reason, I?m not aware) The problem is thus specific to OSX. Regards, Anton. > On 29 Aug 2016, at 19:30, Semyon Sadetsky wrote: > > Hi Anton, > > is it really OS X only problem? It seems on other platforms the peer focusability is updated in the same way. > > --Semyon > > > On 6/29/2016 9:04 PM, Anton Tarasov wrote: >> Hello, >> >> Please review the fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >> >> The problem is that a modal dialog can skip the activation/focus events on OSX. >> The fix is to cache the focusability state of the Window peer earlier, in its ctor. >> Please find more details in JIRA. >> >> Thanks, >> Anton. > From anton.tarasov at jetbrains.com Mon Aug 29 17:31:34 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 29 Aug 2016 20:31:34 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> Message-ID: Hi Sergey, Ok, I?ve changed it as you suggested: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.1 Regards, Anton. > On 09 Aug 2016, at 17:34, Sergey Bylokhov wrote: > > Hi, Anton. > Is it possible to call updateFocusableWindowState() from the initializeImpl()? initializeImpl() is a place where we init the peer before make it visible, but after constructor of the peer was called. > > On 29.06.16 21:04, Anton Tarasov wrote: >> Hello, >> >> Please review the fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >> >> The problem is that a modal dialog can skip the activation/focus events >> on OSX. >> The fix is to cache the focusability state of the Window peer earlier, >> in its ctor. >> Please find more details in JIRA. >> >> Thanks, >> Anton. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Aug 29 18:08:13 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 29 Aug 2016 21:08:13 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> Message-ID: <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> On 8/29/2016 8:29 PM, Anton Tarasov wrote: > Hi Semyon, > > As I wrote in JIRA, the problem is caused by the fact that a native window (for a modal dialog) is shown before the peer starts to show. (This seems strange, and you can investigate the reason, I?m not aware) Maybe because NSWindow.orderFrontRegardless() is called? Why it is called on that moment and why the "Regardless" version is used? --Semyon > The problem is thus specific to OSX. > > Regards, > Anton. > >> On 29 Aug 2016, at 19:30, Semyon Sadetsky wrote: >> >> Hi Anton, >> >> is it really OS X only problem? It seems on other platforms the peer focusability is updated in the same way. >> >> --Semyon >> >> >> On 6/29/2016 9:04 PM, Anton Tarasov wrote: >>> Hello, >>> >>> Please review the fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >>> >>> The problem is that a modal dialog can skip the activation/focus events on OSX. >>> The fix is to cache the focusability state of the Window peer earlier, in its ctor. >>> Please find more details in JIRA. >>> >>> Thanks, >>> Anton. From dmitry.markov at oracle.com Tue Aug 30 08:20:14 2016 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Tue, 30 Aug 2016 11:20:14 +0300 Subject: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog In-Reply-To: References: <57BC2514.8060906@oracle.com> <948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com> <59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com> Message-ID: <9BEECA1C-6092-429A-9372-8AE63BAB7343@oracle.com> Thank you very much, Sergey! Looking for a second +1 from someone else. Thanks, Dmitry > On 29 Aug 2016, at 18:53, Sergey Bylokhov wrote: > > Looks fine. > > On 25.08.16 13:53, Dmitry Markov wrote: >> Hi Sergey, >> >> I have updated the fix based on your suggestion, (i.e. add a new >> method). Please find a new version here: >> http://cr.openjdk.java.net/~dmarkov/8050478/webrev.01/ >> >> Thanks, >> Dmitry >>> On 24 Aug 2016, at 18:27, Sergey Bylokhov >> > wrote: >>> >>> Then I suggest to add a new method which will generate the EXIT before >>> disable the window(I think it is better way?), or rename the current >>> method since after the fix this is not a simple nativeSetEnabled() method. >>> >>> On 24.08.16 11:03, Dmitry Markov wrote: >>>> Hi Sergey, >>>> >>>> Thank you for the review. >>>> >>>> Actually the event is generated when the dialog is displayed, but it >>>> is discarded in deliverJavaMouseEvent() function (see AWTView.m) >>>> since the window is already disabled. When we are going to show a >>>> modal dialog we disable/block previously displayed windows via >>>> setModalBlocked() method. So we have to generate and send MouseExited >>>> event to the window before it is disabled/blocked by the modal dialog. >>>> >>>> Thanks, >>>> Dmitry >>>>> On 23 Aug 2016, at 22:01, Sergey Bylokhov >>>>> > wrote: >>>>> >>>>> Why this event is not generated by the >>>>> nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog? >>>>> >>>>> On 23.08.16 13:27, dmitry markov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you review a fix for jdk9, please? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050478 >>>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/ >>>>>> >>>>>> Problem description: >>>>>> Cursor is not updated correctly after closing a modal dialog. The root >>>>>> cause of the issue is lack of a mouse exit event during displaying of >>>>>> the modal dialog. >>>>>> >>>>>> Fix: >>>>>> It is necessary to generate MouseExited event for the window which is >>>>>> going to be blocked by the modal dialog. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From avik.niyogi at oracle.com Tue Aug 30 09:17:24 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 30 Aug 2016 14:47:24 +0530 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: <50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com> References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> <50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com> Message-ID: Hi All, Please review the proposed specification for JDK9 including inputs from reviewer reviews. http://cr.openjdk.java.net/~aniyogi/8138771/webrev.02/ Thank you in advance. With Regards, Avik Niyogi > On 29-Aug-2016, at 5:55 pm, Alexandr Scherbatiy wrote: > > On 8/29/2016 9:52 AM, Avik Niyogi wrote: >> Hi All, >> >> Please review the proposed specification for JDK9 including inputs from reviver reviews. >> >> http://cr.openjdk.java.net/~aniyogi/8138771/webrev.01/ >> > There is the {@inheritDoc} which allows to use a javadoc from the parent method. > Javadoc for AbstractMultiResolutionImage.getWidth()/getHeight()/getSource()/getProperty() could be like: > > /** > * This method simply delegates to the {@code getBaseImage()}. > * It is equivalent to: {@code getBaseImage().getWidth(observer)). > * > * @see #getBaseImage > * > * @since 9 > */ > > Thanks, > Alexandr. > >> Thank you in advance. >> >> With Regards, >> Avik Niyogi >> >>> On 23-Aug-2016, at 2:58 pm, Alexander Scherbatiy > wrote: >>> >>> On 22/08/16 11:06, Avik Niyogi wrote: >>>> + 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. >>> - I am not a native speaker. May be something like this would be better: >>> ------ >>> /** >>> * This method is not supported by {@code AbstractMultiResolutionImage} >>> * and always throws {@code UnsupportedOperationException} >>> * >>> * @return {@code UnsupportedOperationException} is thrown >>> * @throws UnsupportedOperationException this method is not supported >>> ------ >>> >>> - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) >>> >>> Thanks, >>> Alexandr. >>> >>>>> >>>>> With Regards, >>>>> Avik Niyogi >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Aug 30 10:47:24 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 30 Aug 2016 13:47:24 +0300 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> <50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com> Message-ID: On 8/30/2016 12:17 PM, Avik Niyogi wrote: > Hi All, > Please review the proposed specification for JDK9 including inputs > from reviewer reviews. > > *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.02/* > > I believe the @return tag should have a simple description in other case the compilation fails because of enabled javadoc warning errors. Thanks, Alexandr. > Thank you in advance. > > With Regards, > Avik Niyogi > >> On 29-Aug-2016, at 5:55 pm, Alexandr Scherbatiy >> > > wrote: >> >> On 8/29/2016 9:52 AM, Avik Niyogi wrote: >>> Hi All, >>> >>> Please review the proposed specification for JDK9 including inputs >>> from reviver reviews. >>> >>> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.01/ >>> * >>> >> There is the {@inheritDoc} which allows to use a javadoc from the >> parent method. >> Javadoc for >> AbstractMultiResolutionImage.getWidth()/getHeight()/getSource()/getProperty() >> could be like: >> >> /** >> * This method simply delegates to the {@code getBaseImage()}. >> * It is equivalent to: {@code getBaseImage().getWidth(observer)). >> * >> * @see #getBaseImage >> * >> * @since 9 >> */ >> >> Thanks, >> Alexandr. >> >>> Thank you in advance. >>> >>> With Regards, >>> Avik Niyogi >>> >>>> On 23-Aug-2016, at 2:58 pm, Alexander Scherbatiy >>>> >>> > wrote: >>>> >>>> On 22/08/16 11:06, Avik Niyogi wrote: >>>>> + 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. >>>> - I am not a native speaker. May be something like this would be >>>> better: >>>> ------ >>>> /** >>>> * This method is not supported by {@code >>>> AbstractMultiResolutionImage} >>>> * and always throws {@code UnsupportedOperationException} >>>> * >>>> * @return {@code UnsupportedOperationException} is thrown >>>> * @throws UnsupportedOperationException this method is not >>>> supported >>>> ------ >>>> >>>> - others overridden method should have a documentation that they >>>> delegate call to the base image (see #getBaseImage) >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>> >>>>>> With Regards, >>>>>> Avik Niyogi >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Aug 30 13:26:32 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 30 Aug 2016 16:26:32 +0300 Subject: [9] Review request for 8159432: [hidpi] Linux: display-wise scaling factor issues Message-ID: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8163100 webrev: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.00/ - UI scale listener is added to track system scale changes in Java. - Support for individual monitor scale is removed in case of Xinerama because it is not supported in native apps. - Bug with display name comparison during reading of system scale settings is fixed. --Semyon From anton.tarasov at jetbrains.com Tue Aug 30 15:18:53 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 30 Aug 2016 18:18:53 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> Message-ID: <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> Hi Semyon, On 8/29/2016 9:08 PM, Semyon Sadetsky wrote: > On 8/29/2016 8:29 PM, Anton Tarasov wrote: > >> Hi Semyon, >> >> As I wrote in JIRA, the problem is caused by the fact that a native >> window (for a modal dialog) is shown before the peer starts to show. >> (This seems strange, and you can investigate the reason, I?m not aware) > Maybe because NSWindow.orderFrontRegardless() is called? Why it is > called on that moment and why the "Regardless" version is used? Well, I suggest a one-line fix, harmless from my point of view. And I'm pointing to a problematic spot alongside. I'd love to know why modal dialogs are shown that way, but I'm afraid there was a hidden reason. May be it's gone, please investigate it (sorry, I don't have enough resources to do that at the moment). If you don't mind I'd push the fix in its current version... Regards, Anton. > > --Semyon >> The problem is thus specific to OSX. >> >> Regards, >> Anton. >> >>> On 29 Aug 2016, at 19:30, Semyon Sadetsky >>> wrote: >>> >>> Hi Anton, >>> >>> is it really OS X only problem? It seems on other platforms the peer >>> focusability is updated in the same way. >>> >>> --Semyon >>> >>> >>> On 6/29/2016 9:04 PM, Anton Tarasov wrote: >>>> Hello, >>>> >>>> Please review the fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >>>> >>>> >>>> The problem is that a modal dialog can skip the activation/focus >>>> events on OSX. >>>> The fix is to cache the focusability state of the Window peer >>>> earlier, in its ctor. >>>> Please find more details in JIRA. >>>> >>>> Thanks, >>>> Anton. > From alexandr.scherbatiy at oracle.com Tue Aug 30 15:57:58 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 30 Aug 2016 18:57:58 +0300 Subject: [9] Review request for 8159432: [hidpi] Linux: display-wise scaling factor issues In-Reply-To: References: Message-ID: <49f02273-079d-44a3-0351-c127c16840dd@oracle.com> The fix looks good to me. The bug id in the email subject should be updated to 8163100. Thanks, Alexandr. On 8/30/2016 4:26 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8163100 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.00/ > > - UI scale listener is added to track system scale changes in Java. > > - Support for individual monitor scale is removed in case of Xinerama > because it is not supported in native apps. > > - Bug with display name comparison during reading of system scale > settings is fixed. > > --Semyon > > From semyon.sadetsky at oracle.com Tue Aug 30 16:05:11 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 30 Aug 2016 19:05:11 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> Message-ID: On 8/30/2016 6:18 PM, Anton Tarasov wrote: > Hi Semyon, > > On 8/29/2016 9:08 PM, Semyon Sadetsky wrote: >> On 8/29/2016 8:29 PM, Anton Tarasov wrote: >> >>> Hi Semyon, >>> >>> As I wrote in JIRA, the problem is caused by the fact that a native >>> window (for a modal dialog) is shown before the peer starts to show. >>> (This seems strange, and you can investigate the reason, I?m not aware) >> Maybe because NSWindow.orderFrontRegardless() is called? Why it is >> called on that moment and why the "Regardless" version is used? > > Well, I suggest a one-line fix, harmless from my point of view. And > I'm pointing to a problematic spot alongside. I'd love to know why > modal dialogs are shown that way, but I'm afraid there was a hidden > reason. May be it's gone, please investigate it (sorry, I don't have > enough resources to do that at the moment). If you don't mind I'd push > the fix in its current version... Okay, Anton. It seems nobody of has time to investigate this. Couldn't you, please, create a new JIRA ticket and describe the problem in it for further investigation. Maybe you will be able to come back to this issue in future releases. --Semyon > > Regards, > Anton. > >> >> --Semyon >>> The problem is thus specific to OSX. >>> >>> Regards, >>> Anton. >>> >>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky >>>> wrote: >>>> >>>> Hi Anton, >>>> >>>> is it really OS X only problem? It seems on other platforms the >>>> peer focusability is updated in the same way. >>>> >>>> --Semyon >>>> >>>> >>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote: >>>>> Hello, >>>>> >>>>> Please review the fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >>>>> >>>>> >>>>> The problem is that a modal dialog can skip the activation/focus >>>>> events on OSX. >>>>> The fix is to cache the focusability state of the Window peer >>>>> earlier, in its ctor. >>>>> Please find more details in JIRA. >>>>> >>>>> Thanks, >>>>> Anton. >> > From semyon.sadetsky at oracle.com Tue Aug 30 16:18:29 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 30 Aug 2016 19:18:29 +0300 Subject: [9] Review request for 8161910: [PIT] regression: HW/LW mixing seems broken on Unity In-Reply-To: <83e3c1a9-128a-a13a-a486-8101952b3763@oracle.com> References: <65b51ffb-cdbb-2ca1-c3b0-83b90b33e5d5@oracle.com> <83e3c1a9-128a-a13a-a486-8101952b3763@oracle.com> Message-ID: Sorry for inconvenience, but I have to update this fix once again. http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.02 I have found the main root cause of the issue. In the 8036815 I have missed one insets_corrected = true; statement in the RaparentNotify handler. In my new Unity algo for establishing frame dimensions the insets correction should be postponed until the frame extent property is set. This is corrected in the updated fix. Also the frame insets correction optimization is restored with only one exclusion when the client area is not set to ensure that the target frame will receive the final size and location update. --Semyon On 8/24/2016 4:24 PM, Semyon Sadetsky wrote: > The fix was amended to > http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.01/ > > Because Unity WM may change initial window location (for example when > window overlaps desktop bars) I removed the optimization that skipped > frame bounds revalidation in case of the initial frame insets was > correct. This should guaranty the ConfigureNotify event always to come > after the extent size event. > > --Semyon > > On 8/22/2016 9:19 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8161910 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/ >> >> A regression of the 8036915 in which a new frame dimensioning algo >> was introduced for the Unity WM because the latter differs from other >> WMs a lot. The algo has a flaw in some scenarios when the extent >> size event is delayed while the initial frame insets were established >> correctly, therefore the frame dimensions do not require any tuning. >> In this case the content window need to be notified right in the >> extent event handler to let the content to receive its new dimensions >> because subsequent XConfigureNotify event may be omitted. >> >> --Semyon >> >> > From alexander.zvegintsev at oracle.com Tue Aug 30 18:58:04 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 30 Aug 2016 21:58:04 +0300 Subject: [9] Review request for 8164536: enableSuddenTermination() - Not throws SecurityException if a security manager exists and it will not allow the caller to invoke System.exit Message-ID: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com> Hello, Please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8164536 This fix add check for canProcessApplicationEvents runtime permission(currently used by eawt) for Desktop and Taskbar classes. -- Thanks, Alexander. From Sergey.Bylokhov at oracle.com Tue Aug 30 19:44:36 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 30 Aug 2016 22:44:36 +0300 Subject: [9] Review request for 8164536: enableSuddenTermination() - Not throws SecurityException if a security manager exists and it will not allow the caller to invoke System.exit In-Reply-To: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com> References: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com> Message-ID: <137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com> Hi, Alexander. Probably the name of this permission can be added to AWTPermissions.java? I am not sure why some of the methods require "canProcessApplicationEvents" permission. For example Taskbar.getTaskbar()? I guess Desktop.getDesktop() is used a template but it does not throw such exceptions and/or require similar permissions. On 30.08.16 21:58, Alexander Zvegintsev wrote: > Hello, > > Please review the fix > > http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/ > > for the issue > > https://bugs.openjdk.java.net/browse/JDK-8164536 > > This fix add check for canProcessApplicationEvents runtime > permission(currently used by eawt) for Desktop and Taskbar classes. > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 30 20:45:08 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 30 Aug 2016 23:45:08 +0300 Subject: RFR: 8164899: Provide package access to setComponentMixingCutoutShape In-Reply-To: <57C0B8FD.3000805@oracle.com> References: <57C0B8FD.3000805@oracle.com> Message-ID: <092171ef-a15c-ae67-cb2e-56d505d40a52@oracle.com> Looks fine. On 27.08.16 0:47, Phil Race wrote: > bug : https://bugs.openjdk.java.net/browse/JDK-8164899 > webrev: http://cr.openjdk.java.net/~prr/8164899/ > > Transitional support for this API in jigsaw mode. > It is not public but it is more accessible than it was .. > > -phil. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 30 20:57:40 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 30 Aug 2016 23:57:40 +0300 Subject: [9] Review request for 8159432: [hidpi] Linux: display-wise scaling factor issues In-Reply-To: References: Message-ID: <84d50f83-1819-8806-193a-77a9f273e308@oracle.com> Why in X11GraphicsDevice.java we cannot call initScaleFactor() directly without isUIScaleEnabled() check like we do on win/osx? The same check is made inside this method. On 30.08.16 16:26, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8163100 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.00/ > > - UI scale listener is added to track system scale changes in Java. > > - Support for individual monitor scale is removed in case of Xinerama > because it is not supported in native apps. > > - Bug with display name comparison during reading of system scale > settings is fixed. > > --Semyon > > -- Best regards, Sergey. From james.graham at oracle.com Tue Aug 30 22:59:24 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 30 Aug 2016 15:59:24 -0700 Subject: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> <50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com> Message-ID: I agree that the @return tags need to be filled in. In the first descriptive sentence of the delegation methods, note that "{@code getBaseImage()}" is a reference to a function and not an object, so it sounds like the methods are implemented as "return getBaseImage()" which is not valid because the image is not the return value. If you want to provide a code reference there, then it would be better to say that: * This method simply delegates to the image returned from the * {@code #getBaseImage()} method. Also, since you provide pseudo-code equivalent for all of the methods, which suffices to demonstrate the relationship with the getBaseImage() method, I think the first reference could simply be the words "base image", especially since you are referring to the concept of a base image rather than the actual method that returns it, as in: * This method simply delegates to the base image. * It is equivalent to: ... (Or) * This method simply delegates to the same method on the base image. * It is equivalent to: ... Also, I'd change the getGraphics description to the following, detailing why we throw the exception: * As per the contract of the base {@code Image#getGraphics()} method, * this implementation will always throw {@code UnsupportedOperationException} * since only off-screen images can return a {@code Graphics} object. ...jim On 8/30/16 3:47 AM, Alexandr Scherbatiy wrote: > On 8/30/2016 12:17 PM, Avik Niyogi wrote: >> Hi All, >> Please review the proposed specification for JDK9 including inputs from reviewer reviews. >> >> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.02/* >> > I believe the @return tag should have a simple description in other case the compilation fails because of enabled > javadoc warning errors. > > Thanks, > Alexandr. > >> Thank you in advance. >> >> With Regards, >> Avik Niyogi >> >>> On 29-Aug-2016, at 5:55 pm, Alexandr Scherbatiy >> > wrote: >>> >>> On 8/29/2016 9:52 AM, Avik Niyogi wrote: >>>> Hi All, >>>> >>>> Please review the proposed specification for JDK9 including inputs from reviver reviews. >>>> >>>> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.01/ * >>>> >>> There is the {@inheritDoc} which allows to use a javadoc from the parent method. >>> Javadoc for AbstractMultiResolutionImage.getWidth()/getHeight()/getSource()/getProperty() could be like: >>> >>> /** >>> * This method simply delegates to the {@code getBaseImage()}. >>> * It is equivalent to: {@code getBaseImage().getWidth(observer)). >>> * >>> * @see #getBaseImage >>> * >>> * @since 9 >>> */ >>> >>> Thanks, >>> Alexandr. >>> >>>> Thank you in advance. >>>> >>>> With Regards, >>>> Avik Niyogi >>>> >>>>> On 23-Aug-2016, at 2:58 pm, Alexander Scherbatiy >>>> > wrote: >>>>> >>>>> On 22/08/16 11:06, Avik Niyogi wrote: >>>>>> + 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. >>>>> - I am not a native speaker. May be something like this would be better: >>>>> ------ >>>>> /** >>>>> * This method is not supported by {@code AbstractMultiResolutionImage} >>>>> * and always throws {@code UnsupportedOperationException} >>>>> * >>>>> * @return {@code UnsupportedOperationException} is thrown >>>>> * @throws UnsupportedOperationException this method is not supported >>>>> ------ >>>>> >>>>> - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>> >>>>>>> With Regards, >>>>>>> Avik Niyogi >>>>>> >>>>> >>>> >>> >> > From alexander.zvegintsev at oracle.com Wed Aug 31 00:27:01 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 31 Aug 2016 03:27:01 +0300 Subject: [9] Review request for 8164536: enableSuddenTermination() - Not throws SecurityException if a security manager exists and it will not allow the caller to invoke System.exit In-Reply-To: <137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com> References: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com> <137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com> Message-ID: Hi Sergey, It could be, but actually RuntimePermission is used by eawt(sure we can change it too, but I don't see a point) Please see the updated webrev: http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/01/ -- Thanks, Alexander. On 30.08.2016 22:44, Sergey Bylokhov wrote: > Hi, Alexander. > Probably the name of this permission can be added to AWTPermissions.java? > I am not sure why some of the methods require > "canProcessApplicationEvents" permission. For example > Taskbar.getTaskbar()? I guess Desktop.getDesktop() is used a template > but it does not throw such exceptions and/or require similar permissions. > > On 30.08.16 21:58, Alexander Zvegintsev wrote: >> Hello, >> >> Please review the fix >> >> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/ >> >> for the issue >> >> https://bugs.openjdk.java.net/browse/JDK-8164536 >> >> This fix add check for canProcessApplicationEvents runtime >> permission(currently used by eawt) for Desktop and Taskbar classes. >> >> > > From semyon.sadetsky at oracle.com Wed Aug 31 08:11:40 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 31 Aug 2016 11:11:40 +0300 Subject: [9] Review request for 8163100: [hidpi] Linux: display-wise scaling factor issues In-Reply-To: <84d50f83-1819-8806-193a-77a9f273e308@oracle.com> References: <84d50f83-1819-8806-193a-77a9f273e308@oracle.com> Message-ID: <5e110aef-967e-969c-fee2-f4aa4f922846@oracle.com> On 8/30/2016 11:57 PM, Sergey Bylokhov wrote: > Why in X11GraphicsDevice.java we cannot call initScaleFactor() > directly without isUIScaleEnabled() check like we do on win/osx? The > same check is made inside this method. don't see why this check is bad, but since it is not very necessary I have removed it: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.01/ > > On 30.08.16 16:26, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8163100 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.00/ >> >> - UI scale listener is added to track system scale changes in Java. >> >> - Support for individual monitor scale is removed in case of Xinerama >> because it is not supported in native apps. >> >> - Bug with display name comparison during reading of system scale >> settings is fixed. >> >> --Semyon >> >> > > From Sergey.Bylokhov at oracle.com Wed Aug 31 11:07:08 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Aug 2016 14:07:08 +0300 Subject: [9] Review request for 8163100: [hidpi] Linux: display-wise scaling factor issues In-Reply-To: <5e110aef-967e-969c-fee2-f4aa4f922846@oracle.com> References: <84d50f83-1819-8806-193a-77a9f273e308@oracle.com> <5e110aef-967e-969c-fee2-f4aa4f922846@oracle.com> Message-ID: Looks fine. On 31.08.16 11:11, Semyon Sadetsky wrote: > On 8/30/2016 11:57 PM, Sergey Bylokhov wrote: > >> Why in X11GraphicsDevice.java we cannot call initScaleFactor() >> directly without isUIScaleEnabled() check like we do on win/osx? The >> same check is made inside this method. > don't see why this check is bad, but since it is not very necessary I > have removed it: > http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.01/ >> >> On 30.08.16 16:26, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8163100 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.00/ >>> >>> - UI scale listener is added to track system scale changes in Java. >>> >>> - Support for individual monitor scale is removed in case of Xinerama >>> because it is not supported in native apps. >>> >>> - Bug with display name comparison during reading of system scale >>> settings is fixed. >>> >>> --Semyon >>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Wed Aug 31 14:18:16 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 31 Aug 2016 17:18:16 +0300 Subject: [9] Review request for 8163101: dual-screen issue with JMenu, JPopupMenu Message-ID: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8163101 webrev: http://cr.openjdk.java.net/~ssadetsky/8163101/webrev.00/ In the 8137571 the available screen area request Toolkit.getDefaultToolkit().getScreenSize() was replaced by graphicsConfig.getBounds(); that returns a particular screen area which is not the same as the joint screen area in case of Xinerama multi-monitor configuration. Reverting the previous way fixes the issue. --Semyon From anton.tarasov at jetbrains.com Wed Aug 31 14:25:31 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Wed, 31 Aug 2016 17:25:31 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> Message-ID: <0e3b121b-6bc7-d229-f3ae-ceae827dd9a6@jetbrains.com> On 8/30/2016 7:05 PM, Semyon Sadetsky wrote: > > > On 8/30/2016 6:18 PM, Anton Tarasov wrote: >> Hi Semyon, >> >> On 8/29/2016 9:08 PM, Semyon Sadetsky wrote: >>> On 8/29/2016 8:29 PM, Anton Tarasov wrote: >>> >>>> Hi Semyon, >>>> >>>> As I wrote in JIRA, the problem is caused by the fact that a native >>>> window (for a modal dialog) is shown before the peer starts to >>>> show. (This seems strange, and you can investigate the reason, I?m >>>> not aware) >>> Maybe because NSWindow.orderFrontRegardless() is called? Why it is >>> called on that moment and why the "Regardless" version is used? >> >> Well, I suggest a one-line fix, harmless from my point of view. And >> I'm pointing to a problematic spot alongside. I'd love to know why >> modal dialogs are shown that way, but I'm afraid there was a hidden >> reason. May be it's gone, please investigate it (sorry, I don't have >> enough resources to do that at the moment). If you don't mind I'd >> push the fix in its current version... > Okay, Anton. It seems nobody of has time to investigate this. Couldn't > you, please, create a new JIRA ticket and describe the problem in it > for further investigation. Maybe you will be able to come back to this > issue in future releases. Sure, I filed it: https://bugs.openjdk.java.net/browse/JDK-8165157 Thanks, Anton. > > --Semyon >> >> Regards, >> Anton. >> >>> >>> --Semyon >>>> The problem is thus specific to OSX. >>>> >>>> Regards, >>>> Anton. >>>> >>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky >>>>> wrote: >>>>> >>>>> Hi Anton, >>>>> >>>>> is it really OS X only problem? It seems on other platforms the >>>>> peer focusability is updated in the same way. >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >>>>>> >>>>>> >>>>>> The problem is that a modal dialog can skip the activation/focus >>>>>> events on OSX. >>>>>> The fix is to cache the focusability state of the Window peer >>>>>> earlier, in its ctor. >>>>>> Please find more details in JIRA. >>>>>> >>>>>> Thanks, >>>>>> Anton. >>> >> > From semyon.sadetsky at oracle.com Wed Aug 31 14:36:30 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 31 Aug 2016 17:36:30 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <0e3b121b-6bc7-d229-f3ae-ceae827dd9a6@jetbrains.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> <0e3b121b-6bc7-d229-f3ae-ceae827dd9a6@jetbrains.com> Message-ID: <7748e8b2-a3ad-e4ec-ff3d-fd2c4bcc373b@oracle.com> +1 --Semyon On 8/31/2016 5:25 PM, Anton Tarasov wrote: > On 8/30/2016 7:05 PM, Semyon Sadetsky wrote: >> >> >> On 8/30/2016 6:18 PM, Anton Tarasov wrote: >>> Hi Semyon, >>> >>> On 8/29/2016 9:08 PM, Semyon Sadetsky wrote: >>>> On 8/29/2016 8:29 PM, Anton Tarasov wrote: >>>> >>>>> Hi Semyon, >>>>> >>>>> As I wrote in JIRA, the problem is caused by the fact that a >>>>> native window (for a modal dialog) is shown before the peer starts >>>>> to show. (This seems strange, and you can investigate the reason, >>>>> I?m not aware) >>>> Maybe because NSWindow.orderFrontRegardless() is called? Why it is >>>> called on that moment and why the "Regardless" version is used? >>> >>> Well, I suggest a one-line fix, harmless from my point of view. And >>> I'm pointing to a problematic spot alongside. I'd love to know why >>> modal dialogs are shown that way, but I'm afraid there was a hidden >>> reason. May be it's gone, please investigate it (sorry, I don't have >>> enough resources to do that at the moment). If you don't mind I'd >>> push the fix in its current version... >> Okay, Anton. It seems nobody of has time to investigate this. >> Couldn't you, please, create a new JIRA ticket and describe the >> problem in it for further investigation. Maybe you will be able to >> come back to this issue in future releases. > > Sure, I filed it: https://bugs.openjdk.java.net/browse/JDK-8165157 > > Thanks, > Anton. > >> >> --Semyon >>> >>> Regards, >>> Anton. >>> >>>> >>>> --Semyon >>>>> The problem is thus specific to OSX. >>>>> >>>>> Regards, >>>>> Anton. >>>>> >>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky >>>>>> wrote: >>>>>> >>>>>> Hi Anton, >>>>>> >>>>>> is it really OS X only problem? It seems on other platforms the >>>>>> peer focusability is updated in the same way. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the fix: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >>>>>>> >>>>>>> >>>>>>> The problem is that a modal dialog can skip the activation/focus >>>>>>> events on OSX. >>>>>>> The fix is to cache the focusability state of the Window peer >>>>>>> earlier, in its ctor. >>>>>>> Please find more details in JIRA. >>>>>>> >>>>>>> Thanks, >>>>>>> Anton. >>>> >>> >> > From Sergey.Bylokhov at oracle.com Wed Aug 31 18:04:36 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Aug 2016 21:04:36 +0300 Subject: Review request for 8160570: [mac] modal dialog can skip the activation/focus events In-Reply-To: <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com> <6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com> <04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com> <6497d165-4720-9e47-1297-448542904f28@jetbrains.com> Message-ID: <3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com> On 30.08.16 18:18, Anton Tarasov wrote: >>> As I wrote in JIRA, the problem is caused by the fact that a native >>> window (for a modal dialog) is shown before the peer starts to show. >>> (This seems strange, and you can investigate the reason, I?m not aware) >> Maybe because NSWindow.orderFrontRegardless() is called? Why it is >> called on that moment and why the "Regardless" version is used? > > Well, I suggest a one-line fix, harmless from my point of view. And I'm > pointing to a problematic spot alongside. I'd love to know why modal > dialogs are shown that way, but I'm afraid there was a hidden reason. I wonder how do you use this dialogs, because it is not possible to dispose or make them invisible. For example all tests should dispose all windows which were created in the test, and it seems impossible in the provided code, right(tested on latest jdk9)? >> --Semyon >>> The problem is thus specific to OSX. >>> >>> Regards, >>> Anton. >>> >>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky >>>> wrote: >>>> >>>> Hi Anton, >>>> >>>> is it really OS X only problem? It seems on other platforms the peer >>>> focusability is updated in the same way. >>>> >>>> --Semyon >>>> >>>> >>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote: >>>>> Hello, >>>>> >>>>> Please review the fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570 >>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0 >>>>> >>>>> >>>>> The problem is that a modal dialog can skip the activation/focus >>>>> events on OSX. >>>>> The fix is to cache the focusability state of the Window peer >>>>> earlier, in its ctor. >>>>> Please find more details in JIRA. >>>>> >>>>> Thanks, >>>>> Anton. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Aug 31 18:18:41 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Aug 2016 21:18:41 +0300 Subject: [9] Review request for 8163101: dual-screen issue with JMenu, JPopupMenu In-Reply-To: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com> References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com> Message-ID: <89f43004-f933-e609-b904-6b83dea722c6@oracle.com> On 31.08.16 17:18, Semyon Sadetsky wrote: > Toolkit.getDefaultToolkit().getScreenSize() > > was replaced by > > graphicsConfig.getBounds(); > > that returns a particular screen area which is not the same as the joint > screen area in case of Xinerama multi-monitor configuration. Can you please clarify what is the difference between two methods in this bug? Toolkit.getScreenSize() is related to the main screen only(defaul gc config), but gc.getBounds() is related to appropriate screen(and take scale factor of those screen into account). In case of xinerama we should have two GC which should have each own scales. -- Best regards, Sergey.