Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

Hi Sergey, Le lun. 8 mars 2021 à 06:00, Sergey Bylokhov a écrit : > Hi, Laurent. > > On 04.10.2018 23:45, Laurent Bourgès wrote: > > I looks like a call to let me have a look. Maybe I could inspect what > makes LCMS slow (lerp?) ... and optimize the C code or at least

Re: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

Sergey, I tested clemens patch and sometimes, jvm hangs if I close the xwindow where the opengl surface is still rendering... Could you explain us or do you have design documents (html, pdf, wiki...) describing the awt locking scheme and its relations with x11 / opengl and other native backends

[OpenJDK 2D-Dev] Integrated: JDK-8259681 : Remove the Marlin rendering engine (single-precision)

On Thu, 14 Jan 2021 09:27:41 GMT, Laurent Bourgès wrote: > - Removed MarlinRenderingEngine and related classes > - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine > - Marlin Version set to 0.9.1.4 > > Jtreg tests [test/jdk/sun/java2d/marlin/] : OK This p

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v5]

> - Removed MarlinRenderingEngine and related classes > - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine > - Marlin Version set to 0.9.1.4 > > Jtreg tests [test/jdk/sun/java2d/marlin/] : OK Laurent Bourgès has updated the pull request incrementally with

Re: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

Hi Clemens, I read again the source code and wanted to add metrics like wait_ratio and make some new heuristics to auto tune the buffer capacity. I was also tempted to rewrite the buffer overflow strategy: swap buffer or use a larger one... Apparently you made another approach (double buffer)

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v3]

On Sun, 17 Jan 2021 09:27:03 GMT, Laurent Bourgès wrote: >> Marked as reviewed by serb (Reviewer). > > Sergey, I made the class refactoring, more clear in incremental webrev: > https://openjdk.github.io/cr/?repo=jdk=2076=02-03 > Still Approved ? Forgot to fix copyright year

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v3]

On Sat, 16 Jan 2021 21:38:32 GMT, Sergey Bylokhov wrote: >> Laurent Bourgès has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixed copyright year + removed useless interfaces (IRendererContext, >> MarlinRe

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v4]

> - Removed MarlinRenderingEngine and related classes > - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine > - Marlin Version set to 0.9.1.4 > > Jtreg tests [test/jdk/sun/java2d/marlin/] : OK Laurent Bourgès has updated the pull request incrementally with

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v2]

On Fri, 15 Jan 2021 11:28:35 GMT, Laurent Bourgès wrote: >> Marked as reviewed by serb (Reviewer). > > Sergey, I slightly modified the reviewed change: > see incremental changes: > https://openjdk.github.io/cr/?repo=jdk=2076=01-02 One more idea: should I rename all Dxxx clas

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v2]

On Fri, 15 Jan 2021 07:38:58 GMT, Sergey Bylokhov wrote: >> Laurent Bourgès has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixed invalid Stroker.CAP_BUTT reference > > Marked as reviewed by serb (Reviewer)

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v3]

> - Removed MarlinRenderingEngine and related classes > - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine > - Marlin Version set to 0.9.1.4 > > Jtreg tests [test/jdk/sun/java2d/marlin/] : OK Laurent Bourgès has updated the pull request incrementally with

Re: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

odern GL has many improvements in areas where the current pipeline is > suffering a bit (overhead of state changes for small drawing operations, > etc). > > Thanks and best regards, Clemens > -- -- Laurent Bourgès

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision)

On Thu, 14 Jan 2021 09:27:41 GMT, Laurent Bourgès wrote: > - Removed MarlinRenderingEngine and related classes > - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine > - Marlin Version set to 0.9.1.4 > > Jtreg tests [test/jdk/sun/java2d/marlin/] : OK Apparen

Re: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision) [v2]

> - Removed MarlinRenderingEngine and related classes > - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine > - Marlin Version set to 0.9.1.4 > > Jtreg tests [test/jdk/sun/java2d/marlin/] : OK Laurent Bourgès has updated the pull request incrementally with

[OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering engine (single-precision)

- Removed MarlinRenderingEngine and related classes - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine - Marlin Version set to 0.9.1.4 Jtreg tests [test/jdk/sun/java2d/marlin/] : OK - Commit messages: - restored MarlinTileGenerator - JDK-8259681: removed

[OpenJDK 2D-Dev] Integrated: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang

On Sat, 9 Jan 2021 09:05:27 GMT, Laurent Bourgès wrote: > This is my fix proposal to this bug: > - added new method strokeTo(... Region clip ...) in the abstract > RenderingEngine class > - fixed all RenderingEngine implementations in java.desktop module > - MarlinRendering

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v7]

On Tue, 12 Jan 2021 18:43:36 GMT, Phil Race wrote: >> Laurent Bourgès has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - fixed copyright year >> - removed invalid jtreg test > > src/java.des

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v7]

On Tue, 12 Jan 2021 18:40:39 GMT, Phil Race wrote: >> Laurent Bourgès has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - fixed copyright year >> - removed invalid jtreg test > > src/java.d

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang

On Sat, 9 Jan 2021 09:05:27 GMT, Laurent Bourgès wrote: > This is my fix proposal to this bug: > - added new method strokeTo(... Region clip ...) in the abstract > RenderingEngine class > - fixed all RenderingEngine implementations in java.desktop module > - MarlinRendering

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v4]

On Mon, 11 Jan 2021 06:08:15 GMT, Sergey Bylokhov wrote: >> Laurent Bourgès has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fixed RenderingEngine.strokeTo(clip) to call by default former method. >>

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v7]

> the given shape in strokeTo(clip) > - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good > performance with huge dashed shapes. > > I wrote a new test class to validate the bug fix. Laurent Bourgès has updated the pull request incrementally with two

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v4]

On Mon, 11 Jan 2021 06:09:46 GMT, Sergey Bylokhov wrote: >> Laurent Bourgès has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fixed RenderingEngine.strokeTo(clip) to call by default former method. >>

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v6]

> the given shape in strokeTo(clip) > - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good > performance with huge dashed shapes. > > I wrote a new test class to validate the bug fix. Laurent Bourgès has updated the pull request incrementally with one addition

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v5]

> the given shape in strokeTo(clip) > - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good > performance with huge dashed shapes. > > I wrote a new test class to validate the bug fix. Laurent Bourgès has updated the pull request incrementally with one addition

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v4]

> the given shape in strokeTo(clip) > - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good > performance with huge dashed shapes. > > I wrote a new test class to validate the bug fix. Laurent Bourgès has updated the pull request incrementally with one addition

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v3]

On Sun, 10 Jan 2021 11:17:49 GMT, Laurent Bourgès wrote: >> Interesting, but BufferedImage rendering may use another java2d pipeline... >> so I will check if LoopPipe.getStrokedSpans() is used by your test code. > > Moreover the bug was detected on both gdi & xr

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v3]

On Sun, 10 Jan 2021 02:20:04 GMT, Sergey Bylokhov wrote: >> Laurent Bourgès has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixed white spaces > > src/java.desktop/share/classes/sun/java2d/pipe/RenderingE

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v3]

On Sun, 10 Jan 2021 11:16:51 GMT, Laurent Bourgès wrote: >> test/jdk/sun/java2d/marlin/DrawingTest7018932.java line 42: >> >>> 40: * @run main DrawingTest7018932 >>> 41: */ >>> 42: public class DrawingTest7018932 extends JPanel { >> >>

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v3]

the > given shape in strokeTo(clip) > - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good > performance with huge dashed shapes. > > I will write a new test class in follow-up commits to validate the bug fix. Laurent Bourgès has updated the pull request

Re: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang [v2]

the > given shape in strokeTo(clip) > - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good > performance with huge dashed shapes. > > I will write a new test class in follow-up commits to validate the bug fix. Laurent Bourgès has updated the pull request

[OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with a dashed Stroke can cause Java to hang

This is my first fix proposal on this bug: - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class - fix all RenderingEngine implementations in java.desktop module - MarlinRenderingEngine now use the clip region to roughly & quickly clip the given shape in

[OpenJDK 2D-Dev] Marlin 0.9.5 with experimental pure-java alpha blending

Hi, For 3 months I worked on an improved alpha blending method in the Marlin renderer project (on github): https://github.com/bourgesl/marlin-renderer/tree/unsafe-dev It is implemented as a pure-java experimental code that rewrite alpha compositing operations (SRC_OVER) to perform

Re: [OpenJDK 2D-Dev] Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested.

Congratulations ! I suppose it was an intense task. Does metal support correct color blending ? I mean not the basic srgb mixing but gamma corrected at least. FYI I am implementing a new experimental color blender in pure java for the future Marlin renderer to achieve higher quality like gimp

Re: [OpenJDK 2D-Dev] RFR[14]: JDK-8230728 : Thin stroked shapes are not rendered if affine transform has flip bit

Thanks, I pushed: https://hg.openjdk.java.net/jdk/client/rev/7f55aad34ac4 Laurent Le mar. 10 sept. 2019 à 07:47, Jayathirth Rao a écrit : > +1. > > Thanks, > Jay > > On 10-Sep-2019, at 3:18 AM, Phil Race wrote: > > Approved. > > -phil. > > On 9/6/19 2:

Re: [OpenJDK 2D-Dev] RFR[14]: JDK-8230728 : Thin stroked shapes are not rendered if affine transform has flip bit

Hi Phil, Is this fix trivial enough to have only one reviewer ? So I can push asap. Laurent Le lun. 9 sept. 2019 à 23:50, Phil Race a écrit : > Approved. > > -phil. > > On 9/6/19 2:15 PM, Laurent Bourgès wrote: > > Hi, > > Please review this bug fix for the Marlin

[OpenJDK 2D-Dev] RFR[14]: JDK-8230728 : Thin stroked shapes are not rendered if affine transform has flip bit

Hi, Please review this bug fix for the Marlin renderer (present in Pisces code since JDK 6?): JBS: https://bugs.openjdk.java.net/browse/JDK-8230728 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8230728.0/ This patch fixes a NaN handling in userSpaceLineWidth() when the affine

Re: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region

Kevin & Philip, Thank you for your reviews, I pushed the fix: http://hg.openjdk.java.net/jdk/client/rev/13178f7e75d5 Laurent Le mer. 7 août 2019 à 01:30, Kevin Rushforth a écrit : > Looks good. > > +1 > > -- Kevin > > On 8/6/2019 12:28 AM, Laurent Bourgès wrote: >

Re: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region

Ping: Could someone do a second review ? Laurent Le ven. 2 août 2019 à 17:01, Laurent Bourgès a écrit : > Thanks Philip, > > I am waiting for another approval, > Cheers, > Laurent > > Le ven. 2 août 2019 à 00:13, Philip Race a > écrit : > >> +1 from me. Looks t

Re: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region

Thanks Philip, I am waiting for another approval, Cheers, Laurent Le ven. 2 août 2019 à 00:13, Philip Race a écrit : > +1 from me. Looks the same as the FX fix modulo some moving things around. > > -phil. > > On 7/29/19, 12:56 AM, Laurent Bourgès wrote: > > Hi, > >

[OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region

Hi, Please review this bug fix for the Marlin renderer (introduced in JDK11.0.2): JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ This patch is very close to MarlinFX patch integrated last week in OpenJFX 14, see

Re: [OpenJDK 2D-Dev] [13] Review Request: 8216592 Drop of sun.awt.AWTSecurityManager class

Hi Phil, Few questions about this patch. I wonder if IcedTeaWeb will be broken by such change removing the support of multiple AppContexts in FontManager. I would have prefered keeping maybeMultiAppContext() relying on a system property than removing all the internal mechanism, that could be

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

hould postpone it to the next version. > Just send the changes when they are ready, if the review fails > to take place at the right time, then the fix will be > moved to the jdk13. > > On 20/11/2018 00:28, Laurent Bourgès wrote: > > As OpenJDK12 RDP1 is coming soon, I propose thi

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

e at the right time, then the fix will be > moved to the jdk13. > > On 20/11/2018 00:28, Laurent Bourgès wrote: > > As OpenJDK12 RDP1 is coming soon, I propose this plan: > > - integrate this basic fix in ShapeSpanIterator.c code to use stdlib > sort (mergesort on linux) &g

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

to Marlin sort & Marlin nonAA renderer integration in OpenJDK 13 Will you have time to review 2 small patchs on time ? Cheers, Laurent Le mar. 23 oct. 2018 à 22:37, Laurent Bourgès a écrit : > Phil, > I quickly modified the final update & sort loop to: > - move sort in another bl

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

t; On 23/10/2018 13:37, Laurent Bourgès wrote: > > Phil, > > I quickly modified the final update & sort loop to: > > - move sort in another block > > - use qsort() using a new comparator sortSegmentsByCurX > > > > This improves performance in PolyLineTest b

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

segmentTable[new] = seg; } cur = lo; } Cheers, Laurent Le mar. 23 oct. 2018 à 08:30, Laurent Bourgès a écrit : > Phil, > Yesterday I started hacking ShapeSpanIterator.c to add stats: the last > stage (sort by x0) is the bottleneck. > In this case every sort t

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

erse engineering/studying the code is what we'd have to do if that were > the approach to be taken here. > > -phil. > > On 10/12/18, 2:18 AM, Laurent Bourgès wrote: > > Phil, > I looked at the hostpot in > src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c (7

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

*/* Then make sure the segment is sorted by x0 */ for (new = cur; new > lo; new--) {segmentData *seg2 = segmentTable[new - 1];if (seg2->curx <= x0) {break;} segmentTable[new] = seg2;}* segmentTab

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

Phil, It reminds me I have rewritten in Marlin renderer the crossing sort at every scanline. Pisces was using a trivial insertion sort but it became very slow when the crossing count is large. I adopted a special merge sort as crossings are mostly ordered: big win. What sort algo is in action in

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

a écrit : > On 10/10/2018 11:15 AM, Laurent Bourgès wrote: > > It looks awesome & promising. > > Thank you, Laurent, for looking into it so quickly! > > > PS: It is better to send plain text (long) email than sending external > > links (github). > &

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

ind too much if it's a 'hair-line'? > > By the way, my actual application doesn't have 65000 lines but it > draws 3 graphs with about 3000 points, which makes it noticeably slow > when resizing the Window. I suppose I should look into cutting down > the number of points somehow... > > Pete > -- -- Laurent Bourgès

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

net/~lbourges/png/freetype_lcd_filter_jdk11_vs_jdk12.png <http://www.google.com/url?q=http%3A%2F%2Fcr.openjdk.java.net%2F~lbourges%2Fpng%2Ffreetype_lcd_filter_jdk11_vs_jdk12.png=D=1=AFQjCNE0CAjfIZwQddrqcTNkQcg0sg4bOw> Hope it helps, Laurent Le jeu. 11 oct. 2018 à 08:02, Laurent Bourgès a écrit : > Hi j

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

ins the system property "java.runtime.version" > so you can see which is which. > > I do appreciate your help on this. It looks like it's coming down to > Intel's graphics driver, do you agree? > > Pete > -- -- Laurent Bourgès

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

Hi john, I can sponsor you, preparing an official webrev in openjdk 12, as phil asked for. Laurent Le lun. 8 oct. 2018 à 22:24, John Neffenger a écrit : > Now that we fixed a font problem in JavaFX [1], let's fix the same > problem in Java. I would like your feedback on the Request for >

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

Hi john, It looks awesome & promising. Phil, what do you think ? PS: It is better to send plain text (long) email than sending external links (github). Laurent Le lun. 8 oct. 2018 à 22:24, John Neffenger a écrit : > Now that we fixed a font problem in JavaFX [1], let's fix the same >

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

Peter, What is the corresponding bug ? > > Peter, what is your hardware & OS info ? > It's an Intel core i7-8750H, 8GB RAM, intel UHD 630 graphics > Windows 10 Pro 1803 build 17134.320 > > Note that Java 8 is still 'fast' so there must be some difference > between 8 & 11. > > I saw that on Java

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

enJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) > > openjdk version "1.8.0-adoptopenjdk" > OpenJDK Runtime Environment (build > 1.8.0-adoptopenjdk-_2018_05_19_00_59-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > -- -- Laurent Bourgès

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

there is no quick or easy solution. >> >> FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because of the >> MT performance >> issue, but as we now converge Oracle JDK & OpenJDK that was a non-starter >> and it was >> removed along with ot

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

: > > I might be losing it, but I am 99% sure that LCMS is the color conversion > engine in 8. > KCMS was there only for backup. You'd have to know the magic flag to get > it and > no one has said anything to the effect that they are using it. > > -phil. > > On 10/

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

; Best regards > Daniel > > On Wed, Oct 3, 2018 at 7:51 PM Laurent Bourgès > wrote: > >> Very good job, phil. >> >> I will try your CCONV test on my linux machine to see if it is platform >> dependent ... or hw ? >> >> Laurent >> >&g

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

Very good job, phil. I will try your CCONV test on my linux machine to see if it is platform dependent ... or hw ? Laurent Le mer. 3 oct. 2018 à 19:19, Philip Race a écrit : > > > On 10/3/18, 1:15 AM, Laurent Bourgès wrote: > > Phil, > > If you look at the given pdf file

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

So I am left to suppose that pdfbox really is doing something different in > 8 vs 11. > Or that this not the real problem. What do others see ? > > I've attached the program. The 1Mb color profile file can be got from the > pdfbox sources. > > -phil. > > > On 10/2/18, 9:35 AM, La

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

Hi Daniel, > > Let's not compare apples and oranges. What I can see it takes the same > route and behave similarly. > I agree, I did not take enough time to get accurate profiles, sorry. > If you look at > http://uhash.com/java_reg/Call_Tree_java_8.html >

Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

Hi, FYI I will run profilers on this test case to compare Oracle JDK8 vs OpenJDK11... Will then give you my analysis. Cheers, Laurent Le mer. 26 sept. 2018 à 23:51, Philip Race a écrit : > Interesting and I assume that it was somewhat less in JD8u ? > Off the top of my head that is one thing

Re: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors

Hi, Can I have a second review, please ? I would like to make a jdk11 updates fix request asap... Laurent Le jeu. 6 sept. 2018 à 09:31, Laurent Bourgès a écrit : > Phil, > Thanks for your review. > > Le jeu. 6 sept. 2018 à 01:39, Philip Race a > écrit : > >> This l

Re: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors

Another reviewer, please ? Le jeu. 6 sept. 2018 à 18:59, Phil Race a écrit : > > > On 09/06/2018 12:31 AM, Laurent Bourgès wrote: > > Phil, > Thanks for your review. > > Le jeu. 6 sept. 2018 à 01:39, Philip Race a > écrit : > >> This looks good to me. >&g

Re: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors

Phil, Thanks for your review. Le jeu. 6 sept. 2018 à 01:39, Philip Race a écrit : > This looks good to me. > I've run all our automated tests + done some manual testing > as well as building on all platforms and reviewing the source changes. > Do you have more closed-source tests that could be

[OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors

Please review this bug fix for the Marlin renderer (introduced in 10): JBS: https://bugs.openjdk.java.net/browse/JDK-8210335 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8210335.0/ Changes: - clipping rectangle is adjusted to take into account the inverse transform (scale/shear) -

Re: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application

Thanks Phil & Sergey for your reviews. I will push tomorrow morning (FR)... Thanks Kevin for submitting the jfx11 bug. FYI I am finalizing marlinFX 0.9.1 patch too (ClipShapeTest adapted) Laurent Le 7 mai 2018 9:20 PM, "Sergey Bylokhov" a écrit : Looks fine. On

Re: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application

Phil, Le dim. 6 mai 2018 à 01:11, Philip Race a écrit : > Looks fine to me. Did you run the rendering related regression tests ? > I ran all tests in sun/java2d/marlin. What other tests should I run ? This fix is very low risk as it fixes only the dash array usage. > >

[OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application

Sergey, Please review this simple fix to the Dasher problem: JBS: https://bugs.openjdk.java.net/browse/JDK-8202580 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8202580.0/ Changes: - (D)Dasher.init: the given dash array is dirty as MarlinRenderingEngine got it from XxxArrayCache

Re: [OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out

Do I need another approval ? Or it is enough to push this test only fix. Laurent Le mar. 3 avr. 2018 à 23:26, Sergey Bylokhov <sergey.bylok...@oracle.com> a écrit : > Looks fine. > > On 30/03/2018 13:09, Laurent Bourgès wrote: > > Phil, > > Here is the ClipShapeTest

[OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out

Phil, Here is the ClipShapeTest change to fix timeout issue JBS: https://bugs.openjdk.java.net/browse/JDK-8200526 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8200526.0/ I increased the timeout to 300s per test. I did a jtreg run on my machine (slowed down to 2Ghz) and it passed

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

re a few TODO's I see but they seem to be more about later clean up or optimisation > so are probably all OK. > > I added few new TODO that I hope to fix later (nothing critical). > So I am OK to push, and if you clean up any of the above first I don't need > to see a new

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Hi, Sorry to insist but I would like to get feedback on this Marlin patch soon before going forward on tile-size tuning in java2d accelerated pipelines. Laurent 2018-03-21 22:56 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Hi, > > Here is the updated

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

rent 2018-03-21 21:44 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Sergey, > > Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov <sergey.bylok...@oracle.com> > a écrit : > >> On 13/03/2018 17:04, Sergey Bylokhov wrote: >> >>> I have starte

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Sergey, Le mer. 14 mars 2018 à 17:14, Sergey Bylokhov a écrit : > On 13/03/2018 17:04, Sergey Bylokhov wrote: > >> I have started to look to this review, will run some closed tests and >> send a feedback soon. >> > > No issues found so far, +1. Thanks for your

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

llow-up issues (d3d, ogl, gdi...) as it requires lots of testing. I prefer having Marlin 0.9.1 patch accepted asap. Laurent Le 8 mars 2018 23:57, "Sergey Bylokhov" <sergey.bylok...@oracle.com> a écrit : > On 08/03/2018 14:02, Laurent Bourgès wrote: > >> I suppose the

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Sergey, Le 8 mars 2018 21:21, "Sergey Bylokhov" <sergey.bylok...@oracle.com> a écrit : On 06/03/2018 00:38, Laurent Bourgès wrote: > Yes d3d/ogl are defered rendering so using RenderQueue buffering has costs > (1 extra mask copy + command arguments). I wonder how to impro

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Hi Clemens, I finally got my hands on a 10-year old NVidia GPU (8800GTS) and can > confirm Laurent's findings. > The proprietary nvidia driver is awesome for the MaskBlit workload, > for x11perf -shmput10 it is 32x faster > than my kaveri APU solution (despite it has to copy data via PCIe). >

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Hi Sergey, Good to get feedback from java2d team ! I am investing a lot of my own time on improving java2d with the Marlin renderer & other optimizations (like these ones) so I expect more involvement from the openjdk 2d community ... to help me testing, commenting, reviewing patches and I

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Phil, As promised, I made Marlin 0.9.1 benchmarks on windows & linux to compare d3d, opengl & xrender backends on the same machine: I5 + nvidia 1070. (I will test on mac OS X soon, if needed) First Marlin 0.9.1 patch works well: no crash or bug with larger tiles 128x64 even if d3d / opengl uses

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

(discussion, skills) ? Laurent Le 15 févr. 2018 6:30 PM, "Laurent Bourgès" <bourges.laur...@gmail.com> a écrit : > Hi, > > Please review this large patch providing Marlin 0.9.1 for JDK 11: > > JBS: to be created asap > webrev: http://cr.openjdk.java.net/~lbourges/mar

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Hi Clemens, Sorry this is a long email giving my feedback on your xrender efforts. After achieving huge speedups with Marlin Laurent Bourgès recently > proposed increasing the AA tile size of MaskBlit/MaskFill operations. > The 128x64 tiles size should help the Xrender pipeline

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

Eisserer" <linuxhi...@gmail.com> a écrit : > Hi, > > After achieving huge speedups with Marlin Laurent Bourgès recently > proposed increasing the AA tile size of MaskBlit/MaskFill operations. > The 128x64 tiles size should help the Xrender pipeline a lot for > larger aa sh

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Phil, Will you have some time soon to have a look ? It fixes dashing performance definitively and dash error accumulation too. Laurent Le 15 févr. 2018 6:30 PM, "Laurent Bourgès" <bourges.laur...@gmail.com> a écrit : > Hi, > > Please review this large patch providin

[OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

Hi, Please review this large patch providing Marlin 0.9.1 for JDK 11: JBS: to be created asap webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.0/ Changes: - *ArrayCache: removed clean flag and usage of jdk.internal.UNSAFE. allocateUninitializedArray() - (D)Curve: added support for

Re: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager does not increase double buffer after attaching a device with higher resolution

Hi, I am not an official reviewer. I just noted you left a stdout statement that should be removed or commented out (trace). You fix seems trivial Laurent Le 12 févr. 2018 09:14, "Alexey Ushakov" a écrit : > Hello, > > Here is the fix of the RepaintManager that

Re: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip

losed > tests for jdk_desktop group. No new issues were found, so it looks fine to > me. > > On 05/12/2017 06:30, Laurent Bourgès wrote: > >> Hi again, >> >> Here is a new webrev fixing the ClipShapeTest: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-81

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

with my full baseline run against which to compare > so I've > re-run just the test failures that seem like they might go anywhere need > this code. > and they were pre-existing. > > -phil. > > > On 11/16/17, 3:01 PM, Laurent Bourgès wrote: > > Phil, > > Here is

Re: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip

led at runtime ! On JDK10 + patch, it passes: sun/java2d/marlin/ClipShapeTest.java Passed. Execution successful PS: Could anyone review the patch ? before RDP1 deadline ? Regards, Laurent 2017-12-04 23:35 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Hi Sergey, >

Re: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip

ble success condition would be: clipping gain > 10 or 50. Regards, Laurent Le 4 déc. 2017 11:11 PM, "Sergey Bylokhov" <sergey.bylok...@oracle.com> a écrit : Hi, Laurent. On 29/11/2017 14:30, Laurent Bourgès wrote: > - added new ClipShapeTest (jtreg) that checks all possib

[OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip

rsion: updated version to "marlin-0.8.2-Unsafe-OpenJDK" - added new ClipShapeTest (jtreg) that checks all possible combinations of (cap / join) for random polyline (Stroker) and polygons (Filler) comparing image outputs rendered with clipping enabled vs disabled Thanks for your time, Cheers, Laurent Bourgès

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Sergey, > > You can generate a number of images using a few threads when the flag is >> on then switch it off and compares results. The test should not draw >> different(on/off) modes in parallel but it can draw t

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

Hi Sergey, Le 14 nov. 2017 11:38 PM, "Sergey Bylokhov" <sergey.bylok...@oracle.com> a écrit : Hi, Laurent. On 14/11/2017 14:03, Laurent Bourgès wrote: > PS: I added the new ClipShapeTests with special jtreg tags: what is the > default timeout ? The complete tests are slo

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

Phil, Here is the new webrev against up-to-date jdk forrest (2D) + tested with jtreg (marlin package) that provides latest Marlin 0.8.2 including the new path clipping filter (Stroker & Filler): http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.0/ I will create a new bug (as the

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

I said 'medium' as the code is quite simple to read but the new CG algorithms to ignore / discard useless path elements are cool but not obvious. Please tell me if you have time and if you prefer a combined (JDK / JFX) webrev or start with 2D or JFX. Cheers, Laurent 2017-09-07 8:52 GMT+02:00 Laure

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

te simple to read but the new CG algorithms to ignore / discard useless path elements are cool but not obvious. Please tell me if you have time and if you prefer a combined (JDK / JFX) webrev or start with 2D or JFX. Cheers, Laurent 2017-09-07 8:52 GMT+02:00 Laurent Bourgès <bourges.laur.

Re: [OpenJDK 2D-Dev] JavaOne slides about Marlin/FX renderer

Hi, Please join me in my efforts improving either Java2D or JavaFX (performance, quality, better 3D support in JFX) by contributing to the Marlin project or sponsoring me working for the java community (OpenJDK & OpenJFX). Here are important clarifications, that represents my point of view (see

[OpenJDK 2D-Dev] Client group consolidation ?

Hi, I wonder what is the current status of the Client consolidation gathering former openjdk groups 2d, awt, sound... and maybe openjfx ? I remember that Phil Race proposed such a big change but as these groups are fragmented with only few active members, I think it is worth to merge them to

  1   2   3   >