Re: RFR:8168316: Suppress deprecation warnings for Applet classes in java.desktop
Do we need the suppression in JavaSoundAudioClip.java as I could not
find any mention of Applet in that class?
In AppletViewer.java
shouldn't we need to add "deprecation" to
45 @SuppressWarnings("serial") // JDK implementation class Do we still need this
160 @SuppressWarnings("deprecation")
since we added
120 @SuppressWarnings({"serial", "deprecation"})
Other than that, looks good to me.
Regards
Prasanta
On 10/20/2016 1:44 AM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8168316
Webrev: http://cr.openjdk.java.net/~prr/8168316/
When applets were deprecated it seems that due to all deprecated
warning being suppressed in java.desktop many places that should
have been updated weren't
This resolves the applet ones .. as a precursor to fixing up the other
issues
that cause this global supression.
-phil
Re: [9] Review request for 8143914: Provide Mac-specific fullscreen support
I guess we can extract some of the common logic in the fix, upto other reviewers, this looks fine to me. On 25.10.16 19:25, Alexander Zvegintsev wrote: Please see the updated webrev: http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/02/ Thanks, Alexander. On 10/11/16 5:00 PM, Alexander Zvegintsev wrote: Hi Sergey, Please see the updated webrev: http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/01/ As I can observe other windows such as native dialogs doesn't have fullscreen button. On 10/2/16 5:52 PM, Sergey Bylokhov wrote: Hi, Alexander. In the fix you use eawt events which are generated by the same peer. Why not use windowWill/DidEnterFullScreen + windowWill/DidExitFullScreen? Why the fix is for the Frames only, there are some limitations for other windows, dialogs etc? On 06.09.16 17:32, Alexander Zvegintsev wrote: Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8143914 This fix adds the green FullScreen button to a resizable frames by default. Previous maximize behavior is still accessible by holding Alt while clicking on the green button. setResizable is fixed because of two reasons: Window will not be able to leave fullscreen if we remove resizable from style bits(and even if we set it again) Window will not have the green button(maximize/zoom or fullscreen) if the window was initially not resizable. -- Best regards, Sergey.
Re: [9] Review request for 8061637: GraphicsEnvironment API does not detect dynamically attached graphics device
OK but I think a code comment in an answer to Sergey's question is warranted - explaining how the "new" thread is needed because of displayChanged making a synchronous call on to the toolkit thread. Otherwise it looks quite odd on its own. Also make sure this is tested both with & without D3D. -phil. On 6/30/16, 10:21 AM, Semyon Sadetsky wrote: On 5/31/2016 10:12 PM, Phil Race wrote: I am not very familiar with this code, but why is this discussion centred around D3D? The GDI pipeline is just as "popular" on Windows due to Intel chipsets. Because we always use D3DGraphicsDevice if d3d is available. new D3DGraphicsDevice()-> getDeviceCaps()-> D3DRenderQueue.flushAndInvokeNow()-> flushBuffer()-> D3DRenderQueue.cpp->AwtToolkit::GetInstance().InvokeFunction()->::SendMessage() It may cause a deadlock if the displayChange event is handled on the Toolkit thread. --Semyon -phil. On 05/23/2016 07:36 AM, Semyon Sadetsky wrote: On 5/23/2016 5:00 PM, Sergey Bylokhov wrote: On 23.05.16 13:29, Semyon Sadetsky wrote: This will not be possible because of deadlock: the SGE update calls D3D, which synchronously send messages to the toolkit thread. Why it is a problem to call this on the toolkit thread directly? This is how D3D calls are run : sun.java2d.d3d. D3DRenderQueue#flashBuffer uses AwtToolkit::GetInstance().InvokeFunction(). --Semyon I think that XToolkit and LWToolkit should uses this logic already. On Windows communication with the graphics pipeline is designed differently. They are quite similar if not identical. I suggest to check two solutions: - displayChanged is on toolkit thread, only listeners which can call users code executed on EDT. - The main logic on the toolkit thread all listeners are on related EDT(in this case we will need to save the appcontext of the listener on addDisplayChangedListener()). --Semyon On 29.04.16 9:56, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8061637 webrev: http://cr.openjdk.java.net/~ssadetsky/8061637/webrev.00/ Display reconfiguration notification is skipped by JavaWS and the plugin under Windows. This happens because native display change event is scheduled to the main app context EDT but the last was disabled by 8004584. As result NPE is thrown on the Toolkit thread and event handling is not scheduled. The fix solution runs display event handling in a new thread if the system EDT is not available. Test would require to write native code so the bug is labeled noreg-hard. --Semyon
Re: Refiew Request For 6614519:[Doc] Description java.awt.dnd.DragSourceContext.getCursor() should be clarified
+1 --Semyon On 02.11.2016 20:07, Sergey Bylokhov wrote: Looks fine. On 02.11.16 7:44, Ambarish Rapte wrote: Hi, Please review this doc change, Webrev: http://cr.openjdk.java.net/~arapte/6614519/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-6614519 Change: /DragSourceContext/uses either of two cursors: custom or default. The /setCursor() & getCusrsor()/ APIs operate only on custom cursor. Hence the description is required to be changed. Regards, Ambarish
Re: RFR:8168316: Suppress deprecation warnings for Applet classes in java.desktop
On 20.10.16 1:14, Philip Race wrote: Well maybe but this isn't about adding deprecations it is just about of getting rid of warnings for uses of APIs that are already deprecated. ok. You are welcome to file a separate bug on that ... -phil. On 10/19/16, 2:59 PM, Sergey Bylokhov wrote: On 19.10.16 23:14, Philip Race wrote: This resolves the applet ones .. as a precursor to fixing up the other issues that cause this global supression. Probably some of related code can be deprecated as well?(like AppletAudioClip, AppletPanel,AppletViewer ,RepaintManager.addDirtyRegion(), AppletInitializer etc). -- Best regards, Sergey.
Re: Refiew Request For 6614519:[Doc] Description java.awt.dnd.DragSourceContext.getCursor() should be clarified
Looks fine. On 02.11.16 7:44, Ambarish Rapte wrote: Hi, Please review this doc change, Webrev: http://cr.openjdk.java.net/~arapte/6614519/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-6614519 Change: /DragSourceContext/uses either of two cursors: custom or default. The /setCursor() & getCusrsor()/ APIs operate only on custom cursor. Hence the description is required to be changed. Regards, Ambarish -- Best regards, Sergey.
Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
+1 Thanks, Alexander. On 11/1/16 10:59 PM, Sergey Bylokhov wrote: Looks fine. On 05.10.16 11:45, Semyon Sadetsky wrote: 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. Can you please clarify what is the difference between: tempLost.requestFocusInWindow() which was updated in the fix, and toFocus.requestFocusInWindow() which was not updated. As far as I understand the second case(when the toFocus==restoreFocusTo) is a component to which we should send ROLLBACK. If you look on the comment above the toFocus.requestFocusInWindow() line you get the case when it is called. Actually tempLost.requestFocusInWindow() is the right place to set ROLLBACK. Focus is requested with ROLLBACK cause only when tempLost==toFocus, but it is hard prove, so I'll better to add the condition: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.01/
Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot
Hi Alexander, Please review updated patch. http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.01/ Added a new public API "Image createHiDPIScreenCapture(Rectangle screenRect)". Returns an ordinary screenshot(BufferedImage) if the UI scale is 1. Returns MultiResolutionImage for HiDPI display with two resolution variants, 1. Low Resolution/base image with user input width and height, I have used interpolation algorithm for scaling , adapted from JavaFX Robot (http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc), 2. High Resolution image with scaled width and height . Regards, Prem From: Alexander Scherbatiy Sent: Thursday, October 13, 2016 3:21 PM To: Prem Balakrishnan; Sergey Bylokhov; awt-dev@openjdk.java.net Subject: Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot On 06/10/16 15:28, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8162959 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/ I have adapted the same fix as used for JavaFX Robot Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8162783"JDK-8162783. Patch: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc New Public API " BufferedImage createScreenCapture(Rectangle screenRect, boolean isHiDPI)" is added, Which will have a parameter to specify if HiDPI. It is better to a add public method which returns MultiResolution image on HiDPI display and consists of two resoltion variants - base image which has size requested by a user - high-resolution image which creates an original screen capture The proposed by your algorithm can be applied to the base image. For more details see JDK-8020618 [macosx] java.awt.Robot makes blurry screen captures on Retina Thanks, Alexandr. Regards, Prem
Re: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt
Can I get another +1 for this fix? Regards, Ajit -Original Message- From: Erik Joelsson Sent: Thursday, October 27, 2016 3:30 PM To: Ajit Ghaisas; build-...@openjdk.java.net; awt-dev@openjdk.java.net Subject: Re: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt Looks good. /Erik On 2016-10-27 11:02, Ajit Ghaisas wrote: > Hi, > > > > Fix of HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8165232"JDK-8165232 has fixed the > 'deprecated' warnings from libawt_xawt. > > Now, only removing warning suppression from makefile remains. This > webrev does it. > > > > http://cr.openjdk.java.net/~aghaisas/8160146/webrev.0/ > > > > I have run JPRT and builds are successful. > > > > Request you to review. > > > > Regards, > > Ajit > >
