Re: [OpenJDK 2D-Dev] RFR: 8273375: Remove redundant 'new String' calls after concatenation in java.desktop

On Fri, 3 Sep 2021 07:53:21 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created `String` object. There is > no need it wrap it in another `new String` call. > Such calls are confusing and produce warnings in IDE. Without them code is > easier to read. Link this PR

Re: [OpenJDK 2D-Dev] RFR: 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper

On Mon, 23 Aug 2021 22:05:13 GMT, Daniel Gredler wrote: > During the recent JEP 381 removal of Solaris code, a few Solaris-specific > constants and private methods were left behind in > sun.font.TrueTypeGlyphMapper. This PR removes these unused odds and ends. Marked as reviewed by jdv

Re: [OpenJDK 2D-Dev] RFR: 8262751: RenderPipelineState assertion error in J2DDemo [v2]

On Wed, 25 Aug 2021 18:10:54 GMT, Alexey Ushakov wrote: >> Provide correct pipeline state for MTLPaint after reset > > Alexey Ushakov has updated the pull request incrementally with one additional > commit since the last revision: > > 8262751: RenderPipelineState assertion error in J2DDemo >

Re: [OpenJDK 2D-Dev] RFR: 8262751: RenderPipelineState assertion error in J2DDemo

On Wed, 25 Aug 2021 05:41:03 GMT, Jayathirth D V wrote: >> Provide correct pipeline state for MTLPaint after reset > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m line 971: > >> 969: [encoder setRenderPipelineState:pipelineState]; >&g

Re: [OpenJDK 2D-Dev] RFR: 8262751: RenderPipelineState assertion error in J2DDemo

On Mon, 23 Aug 2021 19:30:35 GMT, Alexey Ushakov wrote: > Provide correct pipeline state for MTLPaint after reset I have given all test run on metal pipeline. I will add my observation once it is done. - PR: https://git.openjdk.java.net/jdk/pull/5227

Re: [OpenJDK 2D-Dev] RFR: 8262751: RenderPipelineState assertion error in J2DDemo

On Mon, 23 Aug 2021 19:30:35 GMT, Alexey Ushakov wrote: > Provide correct pipeline state for MTLPaint after reset src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m line 971: > 969: [encoder setRenderPipelineState:pipelineState]; > 970: } else { > 971: //

[OpenJDK 2D-Dev] Integrated: 8270893: IndexOutOfBoundsException while reading large TIFF file

On Tue, 20 Jul 2021 06:25:22 GMT, Jayathirth D V wrote: > We are incorrectly passing source offset to ImageInputStream.readFully() > which is getting used on destination buffer. streamPos maintained in each > implementation of stream maintain's appropriate source offset whil

Re: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while reading large TIFF file [v2]

On Tue, 3 Aug 2021 19:03:59 GMT, Sergey Bylokhov wrote: > Thank you! look fine. > BTW Looks like stream.readFully(unit, 0, sz) can be simplified to the > stream.readFully(unit)? Thanks for the review. Yes we can simplify readFully(), looks like we have other instances of similar usage of

Re: [OpenJDK 2D-Dev] RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for > "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be

Re: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while reading large TIFF file [v2]

JBS. All test run is green. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Added regression test - Changes: - all: https://git.openjdk.java.net/jdk/pull/4836/files - new: https://git.openjdk.java.net/jdk/pull/48

Re: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while reading large TIFF file

On Sat, 24 Jul 2021 03:17:11 GMT, Sergey Bylokhov wrote: >> We are incorrectly passing source offset to ImageInputStream.readFully() >> which is getting used on destination buffer. streamPos maintained in each >> implementation of stream maintain's appropriate source offset while reading >>

Re: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while reading large TIFF file

On Tue, 20 Jul 2021 06:25:22 GMT, Jayathirth D V wrote: > We are incorrectly passing source offset to ImageInputStream.readFully() > which is getting used on destination buffer. streamPos maintained in each > implementation of stream maintain's appropriate source offset whil

Re: [OpenJDK 2D-Dev] RFR: 8270893: IndexOutOfBoundsException while reading large TIFF file

On Wed, 21 Jul 2021 22:15:35 GMT, Phil Race wrote: > > Is it possible to create a testcase for this fix? Probably this regression > > should be fixed in jdk17? > > FWIW the fixer had already written : > "Also to hit this code we need stream/file with at-least 1MB of IFD data, > that's why

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3]

On Mon, 5 Jul 2021 15:51:46 GMT, Alexey Ushakov wrote: >> The latest version of this PR re-introduces >> [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547) > >> The latest version of this PR re-introduces >> [JDK-8243547](https://bugs.openjdk.java.net/browse/JDK-8243547) > >

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v2]

On Wed, 23 Jun 2021 12:15:03 GMT, Alexey Ushakov wrote: >> Implemented blit via compute kernel > > Alexey Ushakov has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR.

[OpenJDK 2D-Dev] [jdk17] Integrated: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

On Tue, 29 Jun 2021 17:34:00 GMT, Jayathirth D V wrote: > Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in > Metal. > In this test case we are hitting an invalid condition because of which we > exit from MTLLayer.blitTexture(), but we are

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog [v2]

On Wed, 30 Jun 2021 14:37:31 GMT, Jayathirth D V wrote: >> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in >> Metal. >> In this test case we are hitting an invalid condition because of which we >> exit from MTLLayer.blitTexture(),

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog [v2]

callback to run in loop. Fix is to stop > CVDisplayLink when we return without completing final blit operation in > MTLLayer.blitTexture(). > > Sanity and performance analysis is green. More details in JBS. Jayathirth D V has updated the pull request incrementally with one additi

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

On Wed, 30 Jun 2021 11:36:18 GMT, Ajit Ghaisas wrote: >> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in >> Metal. >> In this test case we are hitting an invalid condition because of which we >> exit from MTLLayer.blitTexture(), but we are not stopping the

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

On Tue, 29 Jun 2021 23:28:44 GMT, Sergey Bylokhov wrote: > Please confirm that mach5 is green. @mrserb Yes CI test run is green. Test link in JBS. - PR: https://git.openjdk.java.net/jdk17/pull/175

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

On Wed, 30 Jun 2021 04:29:56 GMT, Sergey Bylokhov wrote: >> At this point if we exit, we just return and unlock MTLRenderQueue for >> backbuffer rendering. And when it is done we again start CVDisplayLink in >> MTLRenderQueue which in turn calls setNeedsDisplay to get callback to >>

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

On Wed, 30 Jun 2021 04:29:56 GMT, Sergey Bylokhov wrote: >> At this point if we exit, we just return and unlock MTLRenderQueue for >> backbuffer rendering. And when it is done we again start CVDisplayLink in >> MTLRenderQueue which in turn calls setNeedsDisplay to get callback to >>

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

On Tue, 29 Jun 2021 23:31:33 GMT, Sergey Bylokhov wrote: >> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in >> Metal. >> In this test case we are hitting an invalid condition because of which we >> exit from MTLLayer.blitTexture(), but we are not stopping the

[OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal. In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop.

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov wrote: > Implemented blit via compute kernel With this patch shaped windows with translucent/color background are showing only black background. In manual JCK shaped window test also this difference in behaviour is seen. This behaviour

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

On Thu, 17 Jun 2021 07:06:24 GMT, Jayathirth D V wrote: >> Implemented blit via compute kernel > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136: > >> 134: NSUInteger w = computePipelineState.threadExecutionWidth; >> 135: &g

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

On Wed, 16 Jun 2021 11:57:01 GMT, Jayathirth D V wrote: >> @jayathirthrao @aghaisas please let me know if I can push this change into >> JDK17 repository > > @avu i have given all test run. I will get back to you once it is done. Automated jtreg/JCK test run is green. --

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov wrote: > Implemented blit via compute kernel src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136: > 134: NSUInteger w = computePipelineState.threadExecutionWidth; > 135: > 136: // Workaround for some

Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

On Wed, 16 Jun 2021 10:34:50 GMT, Alexey Ushakov wrote: >> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159: >> >>> 157: [computeEncoder endEncoding]; >>> 158: [cb commit]; >>> 159: #endif >> >> This is better than changing the background color, but

Re: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows artifacts on Swing Menu with Java L [v2]

On Mon, 7 Jun 2021 12:03:35 GMT, Ajit Ghaisas wrote: >> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 >> demo is run with uiScale=1.0. >> >> **Issue :** >> SwingSet2 Demo - As reported in JBS description >> J2DDemo - As reported in a comment on JBS >> >> **Root

Re: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows artifacts on Swing Menu with Java L

On Fri, 4 Jun 2021 11:14:46 GMT, Ajit Ghaisas wrote: > This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 > demo is run with uiScale=1.0. > > **Issue :** > SwingSet2 Demo - As reported in JBS description > J2DDemo - As reported in a comment on JBS > > **Root Cause :**

Re: [OpenJDK 2D-Dev] RFR: 8250658: Performance of ClipFlatOval Renderperf test is very low

On Fri, 7 May 2021 22:29:53 GMT, Alexey Ushakov wrote: > Implemented indirect rendering (via stencil texture attachment) to stencil > texture Its good that we have removed intermediate stencil blit operations using this approach. LGTM. jtreg/JCK all test run is fine. J2DDemo, SwingSet2,

[OpenJDK 2D-Dev] Integrated: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline

On Tue, 4 May 2021 11:02:40 GMT, Jayathirth D V wrote: > We have many if else conditions to select OpenGL/Metal pipeline objects. > Apart from initialization phase we should not fetch these objects everytime > checking whether we are using OpenGL/Metal pipeline. This pull request has

Re: [OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline [v2]

On Mon, 10 May 2021 10:14:40 GMT, Jayathirth D V wrote: >> You can add a new abstract method to the parent class: getRenderQueue(), and >> override it in subclasses to call MTLRenderQueue/OGL.getInstance(); In this >> way, you can push to the parent more methods by cal

Re: [OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline [v2]

On Fri, 7 May 2021 19:44:31 GMT, Sergey Bylokhov wrote: >> In dispose() we call validate which internally calls corresponding >> RenderQueue's of OpenGL/Metal, thats why it is not moved to CFLayer. >> For other getters since initialization of peer was happening in individual >>

Re: [OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline [v2]

On Wed, 5 May 2021 07:37:23 GMT, Jayathirth D V wrote: >> We have many if else conditions to select OpenGL/Metal pipeline objects. >> Apart from initialization phase we should not fetch these objects everytime >> checking whether we are using OpenGL/Metal pipeline. >

[OpenJDK 2D-Dev] Integrated: 8252758: Lanai: Optimize index calculation while copying glyphs

On Wed, 5 May 2021 13:50:47 GMT, Jayathirth D V wrote: > Loop optimization while copying glyph content. > J2DDemo, SwingSet2 and Font2DTest are green. This pull request has now been integrated. Changeset: 2438498a Author:Jayathirth D V URL: https://git.openjdk.java.net/jdk/

Re: [OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline [v2]

On Wed, 5 May 2021 02:34:52 GMT, Sergey Bylokhov wrote: >> Jayathirth D V has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Move peer and getters to CFLayer > > src/java.desktop/macosx/classes/sun/java2

Re: [OpenJDK 2D-Dev] RFR: 8262392: Update Mesa 3-D Headers to version 21.0.3

On Tue, 4 May 2021 14:24:22 GMT, Phil Race wrote: > Upgrades OpenGL header files to the latest Mesa project ones. > Build+test looks fine. Marked as reviewed by jdv (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3854

Re: [OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline

On Tue, 4 May 2021 17:51:24 GMT, Phil Race wrote: > LGTM. Is there anything not covered by this fix ? Hi Phil, We still have some if else checks in initialization paths like CPlatformView.initialize(), CPlatformEmbeddedFrame and static access of RenderQueue methods like LWCToolkit.sync().

Re: [OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline

On Tue, 4 May 2021 11:02:40 GMT, Jayathirth D V wrote: > We have many if else conditions to select OpenGL/Metal pipeline objects. > Apart from initialization phase we should not fetch these objects everytime > checking whether we are using OpenGL/Metal pipeline. jtreg/JCK all test run

[OpenJDK 2D-Dev] RFR: 8226384: Implement a better logic to switch between OpenGL and Metal pipeline

We have many if else conditions to select OpenGL/Metal pipeline objects. Apart from initialization phase we should not fetch these objects everytime checking whether we are using OpenGL/Metal pipeline. - Commit messages: - 8226384: Implement a better logic to switch between OpenGL

Re: [OpenJDK 2D-Dev] RFR: 8266040: Lanai: Incorrect calculations of clipping boundaries

On Wed, 28 Apr 2021 10:55:48 GMT, Alexey Ushakov wrote: > Adjust initial clipping values to correctly calculate shape clip boundary LGTM. jtreg and JCK all test run is fine. J2DDemo and SwingSet2 looks good. Ran RenderPerfTest and saw improvement in ClipFlatOval/ClipFlatOvalAA from ~10FPS to

Re: [OpenJDK 2D-Dev] RFR: 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java

On Thu, 29 Apr 2021 07:57:17 GMT, Prasanta Sadhukhan wrote: > It seems the newly deproblemlisted test > DrawRotatedStringUsingRotatedFont.java which is paasing in windows,linux-x64 > and macos-x64 is failing in newly added linux-aarch64 systems. > Problemlisting the test for now as it is font

Re: [OpenJDK 2D-Dev] RFR: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 [v3]

On Wed, 7 Apr 2021 19:00:17 GMT, Denis Konoplev wrote: >> There was no code to check num of work items in compute shader. >> Also, I've replaced four similar shaders. > > Denis Konoplev has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: [OpenJDK 2D-Dev] RFR: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS

On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote: > This PR makes Metal as the default Java2D rendering pipeline for macOS. > > Note : from JBS description : > The plan of record has always been that for JDK 17 the new Metal pipeline > will be OFF by default and must be explicitly enabled

Re: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1

On Wed, 7 Apr 2021 05:24:30 GMT, Denis Konoplev wrote: > Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. > > It's safe since we copy tile from the image with memcpy. > > // copy src pixels inside src bounds to buff > for (int row = 0; row < sh; row++) { >

Re: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo

On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste > error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by jdv (Reviewer). - PR:

Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]

On Tue, 6 Apr 2021 20:38:57 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is >> assigned a new empty array without invalidating old services which were in >> the array before. >> >> The old print services should be invalidated. > > Alexey

Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]

On Tue, 6 Apr 2021 12:51:47 GMT, Alexey Ushakov wrote: > > @avu Test passes without fix also. > > @jayathirthrao Could you provide the details about your configuration along > > with parameters passed to jtreg ? @avu I am running test in 13 inch Macbook Early 2015 with integrated Intel Iris

Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]

On Tue, 6 Apr 2021 12:03:14 GMT, Jayathirth D V wrote: > > > Is it possible to automatically test it? > > > > > > Yes, just added the test. > > @avu Test passes without fix also. @aghaisas Please verify the regression test behavior from your en

Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]

On Fri, 2 Apr 2021 11:41:12 GMT, Alexey Ushakov wrote: > > Is it possible to automatically test it? > > Yes, just added the test. @avu Test passes without fix also. - PR: https://git.openjdk.java.net/jdk/pull/3308

Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]

On Tue, 6 Apr 2021 12:03:14 GMT, Jayathirth D V wrote: >>> Is it possible to automatically test it? >> >> Yes, just added the test. > >> > Is it possible to automatically test it? >> >> Yes, just added the test. > > @avu Test passes wi

[OpenJDK 2D-Dev] Integrated: 8264475: CopyArea ignores clip state in metal rendering pipeline

On Wed, 31 Mar 2021 07:27:45 GMT, Jayathirth D V wrote: > In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state > information because of which we ignore clip parameters set in rect clip and > shape clip. We need to query and use encoders from EncoderManager

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: >>> > 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

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

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,

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

Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]

> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state > information because of which we ignore clip parameters set in rect clip and > shape clip. We need to query and use encoders from EncoderManager to honour > clip states in copyArea. Jayathirth D V

Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v3]

On Thu, 1 Apr 2021 06:58:27 GMT, Prasanta Sadhukhan wrote: >> Jayathirth D V has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Comment update > > src/java.desktop/macosx/native/libawt_lwawt/java2d/me

Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2]

On Thu, 1 Apr 2021 13:28:48 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is >> assigned a new empty array without invalidating old services which were in >> the array before. >> >> The old print services should be invalidated. > > Alexey

Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers

On Thu, 1 Apr 2021 12:57:44 GMT, Jayathirth D V wrote: >> Is it not right? >> I admit I don't understand what you mean by _map_ here. >> >> When the code is written like it was: >> if ((printServices[j] instanceof Win32PrintService) && &g

Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers

On Thu, 1 Apr 2021 12:05:30 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java >> line 159: >> >>> 157: for (int j=0; j < printServices.length; j++) { >>> 158: if ((printServices[j] instanceof Win32PrintService)

Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers

On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov wrote: > When `getAllPrinterNames()` returns null, the list of `printServices` is > assigned a new empty array without invalidating old services which were in > the array before. > > The old print services should be invalidated.

Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers

On Wed, 24 Mar 2021 20:44:26 GMT, Alexey Ivanov wrote: >> Since this is windows specific code, I am not sure if system will not have >> any printers. I guess by default, Microsoft XPS Document Writer, Microsoft >> Print-to-PDF, Fax are present in printers list. That is the reason we do not >>

Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v3]

> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state > information because of which we ignore clip parameters set in rect clip and > shape clip. We need to query and use encoders from EncoderManager to honour > clip states in copyArea. Jayathirth D V

Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline

On Wed, 31 Mar 2021 12:39:49 GMT, Ajit Ghaisas wrote: > I tested this fix. No regressions were observed. > > Using MTLBlitCommandEncoder is intuitive when metal resource copying needs to > be done. > I suggest to add a comment (may be as a method description or in code where > we do the

Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v2]

> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state > information because of which we ignore clip parameters set in rect clip and > shape clip. We need to query and use encoders from EncoderManager to honour > clip states in copyArea. Jayathirth D V

[OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline

In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. - Commit messages: -

Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline

On Wed, 31 Mar 2021 07:27:45 GMT, Jayathirth D V wrote: > In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state > information because of which we ignore clip parameters set in rect clip and > shape clip. We need to query and use encoders from EncoderManager

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

> On 12-Mar-2021, at 10:30 AM, Sergey Bylokhov wrote: > > On Fri, 12 Mar 2021 00:09:54 GMT, Kevin Rushforth wrote: > >>> Ajit Ghaisas has updated the pull request with a new target base due to a >>> merge or a rebase. The incremental webrev excludes the unrelated changes >>> brought in by

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

> On 12-Mar-2021, at 9:29 AM, Scott Palmer wrote: > > >> On Mar 11, 2021, at 9:53 PM, Sergey Bylokhov wrote: >> >> On Fri, 12 Mar 2021 02:29:04 GMT, Jayathirth D V wrote: >> >>>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSur

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

On Fri, 12 Mar 2021 00:42:35 GMT, Sergey Bylokhov wrote: >> Ajit Ghaisas has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 47 additional >>

Re: [OpenJDK 2D-Dev] RFR: 8261170: Upgrade to freetype 2.10.4

On Wed, 24 Feb 2021 18:34:31 GMT, Phil Race wrote: > This upgrades JDK (Java2D) from using freetype 2.10.2 to 2.10.4. > A minor upgrade but there's been some refactoring of include files so most > files are touched. > Testing looks good. Marked as reviewed by jdv (Reviewer). -

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v4]

On Thu, 11 Feb 2021 05:41:15 GMT, Ajit Ghaisas wrote: >> According to Xcode Instruments leak profile, there are 2 minor memory leaks >> in the Metal rendering pipeline: >> >> `#1 Malloc 80 Bytes 1 0x7fde0d4247b0 80 Byteslibjava.dylib >> getStringUTF8` >>0

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

On Mon, 8 Feb 2021 18:05:02 GMT, Gerard Ziemski wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Lanai PR#175 - 8261304 - aghaisas > > src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java line 97: >

Re: [OpenJDK 2D-Dev] RFR: 8260380: Upgrade to LittleCMS 2.12

On Tue, 9 Feb 2021 22:52:04 GMT, Phil Race wrote: > Minor upgrade from LCMS 2.11 -> 2.12 > Automated tests pass, 2D demo also looks good. Marked as reviewed by jdv (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2490

Re: [OpenJDK 2D-Dev] RFR: 6206189: Graphics2D.clip specifies incorrectly that a 'null' is a valid value for this method

On Tue, 9 Feb 2021 12:54:26 GMT, Prasanta Sadhukhan wrote: >> The spec says "s - the Shape to be intersected with the current Clip" so I >> assume it means there should be a current clip set, so that is why I have >> used setClip to "set" a clip. So, setClip() should be there as far I see. >

Re: [OpenJDK 2D-Dev] RFR: 8198343: Test java/awt/print/PrinterJob/TestPgfmtSetMPA.java may fail w/o printer

On Wed, 3 Feb 2021 05:41:23 GMT, Prasanta Sadhukhan wrote: > This test require a printer to test its objective, so printer existence check > is added. Marked as reviewed by jdv (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2370

Re: [OpenJDK 2D-Dev] RFR: 8255043: Incorrectly styled copyright text

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The chenge is trivial: > - /** >

Re: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments

On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even >

Re: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments

On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even >

Re: [OpenJDK 2D-Dev] RFR: 8251123: doclint warnings about missing javadoc tags and comments

On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote: > We have a number of missing javadoc tags and comments in the desktop module. > Most of the missing comments are related to the serialized form. > > The fix: > - Adds missing comments to the non-static/non-transient fields(even >

Re: [OpenJDK 2D-Dev] RFR: 8252199: Reimplement support of Type 1 fonts without MappedByteBuffer

On Fri, 18 Sep 2020 20:23:25 GMT, Phil Race wrote: > I changed it to read the file into a ByteBuffer to avoid the problem that we > can't control when NIO free's the mmaped > buffer. This is a problem for leaking tmp Type1 font files when using > createFont and I thought maybe we could just >

[OpenJDK 2D-Dev] Integrated: 8252100: NumberOverflow in class MemoryCache

On Tue, 15 Sep 2020 13:49:19 GMT, Jayathirth D V wrote: > Number overflow in javax/imageio/stream/MemoryCache.java > I tried to reproduce the issue but was not able to create stream or > BufferedImage of such a large size because of array > size limitations. Submitter has mentione

Re: [OpenJDK 2D-Dev] RFR: 8253206: Enforce whitespace checking for additional source files

On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git > jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix > for >

Re: [OpenJDK 2D-Dev] RFR: 8252070: Some platform-specific BLIT optimizations are not effective

On Thu, 10 Sep 2020 22:47:53 GMT, Sergey Bylokhov wrote: > Some of our code assumes that the native system(XRender, D3D, OGL) makes some > effective optimizations, but in some cases, we can do better. > > One of the areas for improvement is direct blitting. If the source is much > bigger than

Re: [OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache

On Wed, 16 Sep 2020 01:18:00 GMT, Sergey Bylokhov wrote: >> If pos is big enough you could still theoretically have overflow, but this >> is still better. > > You can try to create such images using some separate tools, BTW I have found > one here(32768 × 32768): >

[OpenJDK 2D-Dev] RFR: 8252100: NumberOverflow in class MemoryCache

Number overflow in javax/imageio/stream/MemoryCache.java I tried to reproduce the issue but was not able to create stream or BufferedImage of such a large size because of array size limitations. Submitter has mentioned simple fix for overflow which has solved his issue. I have verified the fix

Re: [OpenJDK 2D-Dev] RFR: 8252817: Cleanup the classes in the java.awt.color package

On Sat, 5 Sep 2020 21:32:42 GMT, Sergey Bylokhov wrote: > - Class declarations reformat > - Docs cleanup Looks good to me. - Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/22

Re: [OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11

+1. Thanks, Jay > On 30-Aug-2020, at 6:09 AM, Sergey Bylokhov > wrote: > > Looks fine. > > On 28.08.2020 07:42, Philip Race wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8245400 >> Webrev : http://cr.openjdk.java.net/~prr/8245400/ >> A rotuine 3rd party library upgrade. >> All

Re: [OpenJDK 2D-Dev] [16] RFR JDK-8243674: Remove language tag length limit for iTXt chunk in PNGImageReader

ed > IIOException(remainingLen < 0) by the test? > > On 29.07.2020 02:41, Jayathirth D v wrote: >> Hello All, >> Please review the following fix for JDK 16: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8243674 >> Webrev : http://cr.openjdk.java.net/~jdv/824

Re: [OpenJDK 2D-Dev] RFR: 8166038 BufferedImage methods getTileGridXOffset() and getTileGridYOffset() return a non 0 value for sub images

+1. Thanks, Jay > On 28-Jul-2020, at 9:56 AM, Sergey Bylokhov > wrote: > > The new version of the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166038 > Fix: http://cr.openjdk.java.net/~serb/8166038/webrev.02 > > In the new version, the test was updated based on the feedback. > >

[OpenJDK 2D-Dev] [16] RFR JDK-8243674: Remove language tag length limit for iTXt chunk in PNGImageReader

Hello All, Please review the following fix for JDK 16: Bug : https://bugs.openjdk.java.net/browse/JDK-8243674 Webrev : http://cr.openjdk.java.net/~jdv/8243674/webrev.00/ Issue : We have

Re: [OpenJDK 2D-Dev] RFR: 8250755 Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java

Thanks for the cleanup. +1. Thanks, Jay > On 29-Jul-2020, at 2:28 PM, Sergey Bylokhov > wrote: > > Hello. > Please review the fix for jdk/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250755 > Fix: http://cr.openjdk.java.net/~serb/8250755/webrev.00 > > The test in question

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

e? Thanks, Jay -Original Message- From: Yasumasa Suenaga Sent: Thursday, July 23, 2020 5:41 PM To: Jayathirth D v Cc: 2d-dev <2d-dev@openjdk.java.net>; awt-...@openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

Hi, I tried reproducing the issue in my Windows 10 machine with UTF-8 encoding and test file mentioned in the bug, I don’t see any crash. Am I missing something? Also I think this should be in awt-dev so adding the mailing list. Thanks, Jay > On 20-Jul-2020, at 12:59 PM, Yasumasa Suenaga

Re: [OpenJDK 2D-Dev] RFR JDK-8246742: ServiceUI.printDialog does not support properties dialog

g(..), then in that case > no printer job will be created, so properties dialog can be disabled for that > use-case. > > Modified webrev: http://cr.openjdk.java.net/~psadhukhan/8246742/webrev.1/ > <http://cr.openjdk.java.net/~psadhukhan/8246742/webrev.1/> > > Regards &g

Re: [OpenJDK 2D-Dev] RFR JDK-8246742: ServiceUI.printDialog does not support properties dialog

ava#l793 > > <http://hg.openjdk.java.net/jdk/client/file/fabf11c3a8ca/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l793> > So, if we cannot show the dialog using that mechanism, we can enable/disable > the button itself beforehand using that check. > >

  1   2   3   4   5   >