Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov wrote: > > We need to use appropriate encoder(where scissor is set) to honour clip in > > copyArea. > > It is quite interesting that blitting with or without clipping does not have > any difference. thank you for confirmation. but probably our perf tests are > not good enough. Exactly i suspect we are not hitting threshold of GPU computing in our tests. If we hit GPU threshold with larger clip bounds i expect performance to be on higher side after the fix. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 05:02:24 GMT, Jayathirth D V wrote: > We need to use appropriate encoder(where scissor is set) to honour clip in > copyArea. It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 03:51:29 GMT, Sergey Bylokhov wrote: > > I am not getting what do you mean by 'new "round trip" '. Please elaborate. > > Regarding performance metrics i have captured the details in the bug and > > there is no degradation. > > The new code path which takes care of the clip, if there is no degradation > means that we get it for free? Before this change we used to get blitEncoder from same commandbuffer(and same CommandQueue) as we are doing now. And then commit the commandbuffer, so from computational perspective we are not holding or doing anything extra in new implementation. We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. Since we are not seeing any difference in performance numbers (especially in swingmark where we do lot of scrolling/copyArea) we are basically getting clipping in copyArea without any degradation. Also in Netbeans i have done good amount scrolling test and i dont see any degradation. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 02:56:48 GMT, Jayathirth D V wrote: > I am not getting what do you mean by 'new "round trip" '. Please elaborate. > Regarding performance metrics i have captured the details in the bug and > there is no degradation. The new code path which takes care of the clip, if there is no degradation means that we get it for free? - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Fri, 2 Apr 2021 22:43:36 GMT, Sergey Bylokhov wrote: > Just curious how this new "round trip" will affect the performance when the > clip is set and when not? is it cheap? I am not getting what do you mean by 'new "round trip" '. Please elaborate. Regarding performance metrics i have captured the details in the bug and there is no degradation. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Thu, 1 Apr 2021 15:50:50 GMT, Prasanta Sadhukhan wrote: >> Jayathirth D V has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Refactor code to use drawTex2Tex > > Marked as reviewed by psadhukhan (Reviewer). Just curious how this new "round trip" will affect the performance when the clip is set and when not? is it cheap? - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v3]
> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line > spec clean up but > it didn't take a lot of looking to realize there were many more > inconsistencies between spec and implementation. > I've spent a lot of time on what is just small number of factory methods in > Raster because there are so > many possible exceptions and in some cases they rely on other API they call > to generate exceptions and > these may have not been documented or documented acc. to some long lost > behavior. > I've mostly tried to ONLY change spec. But I couldn't help myself when some > checks were missed that > ended up with bizarre and dubious behavior - throwing > NegativeArrayIndexException which just about > always has to be an internal bug ! > > The supplied test passes on JDK 16 as well as this code, because the > (relatively) small number of > cases where JDK 16 threw NegativeArrayIndexException are caught and allowed > only for releases < 17 > So where you see those in the test it corresponds to the behavioral changes > from NegativeArrayIndexException > to IllegalArgumentException. > JCK conformance tests still pass so they must not test those conditions. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8255800: Raster creation methods need some specification clean up - Changes: - all: https://git.openjdk.java.net/jdk/pull/3223/files - new: https://git.openjdk.java.net/jdk/pull/3223/files/85148fd5..ba2ab76c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3223=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3223=01-02 Stats: 29 lines in 2 files changed: 27 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3223.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3223/head:pull/3223 PR: https://git.openjdk.java.net/jdk/pull/3223
Re: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v2]
On Fri, 2 Apr 2021 21:03:30 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8255800: Raster creation methods need some specification clean up > > Marked as reviewed by serb (Reviewer). I updated the fix with some additional checks. This is implementation only - doesn't affect the spec clarification. The problem was that without these new upfront checks for overflow of width+location.x, then on systems without enough memory/swap you'd get an OOME before you got to the place where overflow was checked. - PR: https://git.openjdk.java.net/jdk/pull/3223
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev wrote: > Fix updated after first round of review. src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 260: > 258: > 259:/** > 260: * Icon for a file, directory, or folder as it would be displayed in *Returns an icon* for a file… src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 276: > 274: * > 275: * @param f a File object > 276: * @param size width and height of the icon in pixels Pixels could be ambiguous now. Usually, Swing deals with user's space. That is 16×16 icon should actually be 32×32 if the scale factor of the current display is 200%. Yes, this issue is somewhat irrelevant because the method returns multi-resolution icon. However, the terminology used must be unambiguous and clear; for consistency with other Swing API, it should be in terms of user's space coordinates, *virtual pixels*. - PR: https://git.openjdk.java.net/jdk/pull/2875
Re: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v2]
On Thu, 1 Apr 2021 20:27:37 GMT, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line >> spec clean up but >> it didn't take a lot of looking to realize there were many more >> inconsistencies between spec and implementation. >> I've spent a lot of time on what is just small number of factory methods in >> Raster because there are so >> many possible exceptions and in some cases they rely on other API they call >> to generate exceptions and >> these may have not been documented or documented acc. to some long lost >> behavior. >> I've mostly tried to ONLY change spec. But I couldn't help myself when some >> checks were missed that >> ended up with bizarre and dubious behavior - throwing >> NegativeArrayIndexException which just about >> always has to be an internal bug ! >> >> The supplied test passes on JDK 16 as well as this code, because the >> (relatively) small number of >> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed >> only for releases < 17 >> So where you see those in the test it corresponds to the behavioral changes >> from NegativeArrayIndexException >> to IllegalArgumentException. >> JCK conformance tests still pass so they must not test those conditions. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8255800: Raster creation methods need some specification clean up Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3223
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v3]
> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. > MTLLayer.h header cleanup. Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8258788: incorrect response to change in window insets [lanai] Corrected copyrights - Changes: - all: https://git.openjdk.java.net/jdk/pull/3308/files - new: https://git.openjdk.java.net/jdk/pull/3308/files/cfe15982..52fc75e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3308=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3308=01-02 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v2]
On Fri, 2 Apr 2021 11:44:52 GMT, Alexey Ushakov wrote: >> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT >> property. MTLLayer.h header cleanup. > > Alexey Ushakov has updated the pull request incrementally with one additional > commit since the last revision: > > 8258788: incorrect response to change in window insets [lanai] > > Added regression test test/jdk/java/awt/Window/FullWindowContentTest/FullWindowContentRenderTest.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. Tests should not have the "Classpath" exception. - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v2]
> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. > MTLLayer.h header cleanup. Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8258788: incorrect response to change in window insets [lanai] Added regression test - Changes: - all: https://git.openjdk.java.net/jdk/pull/3308/files - new: https://git.openjdk.java.net/jdk/pull/3308/files/afab7f43..cfe15982 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3308=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3308=00-01 Stats: 165 lines in 1 file changed: 165 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Thu, 1 Apr 2021 15:15:32 GMT, Sergey Bylokhov wrote: > Is it possible to automatically test it? Yes, just added the test. - PR: https://git.openjdk.java.net/jdk/pull/3308
