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

[Laurent Bourgès]

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 tune gcc
> options.
>
> Did you have a chance to look at it? =)
>

No, I agreed with phil, it is more a LCMS optimization task, for anybody
involved in this project.

I could have a look since, but no time nor motivation, sorry.

This ticket is closeable or stalled until someone rewrites LCMS to be more
efficient.

Cheers,
Laurent

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

[Laurent Bourgès]

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 ?

Thanks,
Laurent

Le lun. 18 janv. 2021 à 23:52, Sergey Bylokhov 
a écrit :

> On 18.01.2021 04:41, Clemens Eisserer wrote:
> > So sure, for GPU limited cases this won't help a lot - however, typical
> java2d is usually CPU limited with tons of very small primitives and many
> state changes in between.
>
> It does not affect so much the xrender which do the same CPU related
> steps, but this speeds up so !much! OGL if executed in parallel.
> I think the benchmark is cheating here, it does not call XSync nor glflush
> for each operation, so it just checks the speed of pushing the data to the
> buffer, and not measured the actual rendering for both pipelines, unlike
> the software-based rendering.
>
>
> --
> Best regards, Sergey.
>

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

[Laurent Bourgès]

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 pull request has now been integrated.

Changeset: 61292be7
Author:Laurent Bourgès 
URL:   https://git.openjdk.java.net/jdk/commit/61292be7
Stats: 9839 lines in 28 files changed: 53 ins; 8694 del; 1092 mod

8259681: Remove the Marlin rendering engine (single-precision)

Reviewed-by: serb

-

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

> - 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 one additional 
commit since the last revision:

  fixed copyright year again

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/80428a96..8818d050

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2076=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2076=03-04

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

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) to reduce the wait
latency in awt threads... and allow gl thread to run concurently: excellent
!

Le dim. 17 janv. 2021 à 13:11, Clemens Eisserer  a
écrit :

> Hi Sergey,
>
> > The design is a little bit different, the XRender pipeline:
> >   - Many threads which call draw operations and sends them to the XServer
> >   - The XSerever decode the the draw operation and push the commands to
> the "opengl buffer"
> >   - Some video driver code which decode the ogl buffer and actually draw
> something
> > The OGL pipeline
> >   - Many threads call draw operations, and save them in the internal
> RenderQueue buffer
> >   - One RenderQueue thread decode the the draw operation and push the
> commands to the "opengl buffer"
> >   - Some video driver code which decode the ogl buffer and actually draw
> something
>
> So in both cases producers (application threads) and the consumer are
> decoupled via some kind of queue (unix domain socket for x11, in-memory
> queue for the renderqueue) and in theory could operate concurrently.
>
> > I am not sure that it work that way, the only way to block the queuing
> thread is to call "flushNow()", for other cases it should not be blocked.
> > The OGLRenderQueue thread however could became blocked every 100ms.
>
> Since there is only one RenderQueue+Buffer, the entire queue has to be
> locked while the commands are processed by the RenderQueue-Thread (via the
> AWT lock held by the thread which is implicitly calling flushNow triggered
> by a full buffer).
> This serverly limits parallelism - you can either process commands
> (RenderQueue thread) or queue new commands (AWT threads) but not both at
> the same time.
> This lead me to the original question - whether this was a necessity
> caused by structural requirements/limitations or whether it simply hasn't
> been thought through / implemented.
>
> I did some prototyping of a double-buffered renderqueue (no other changes)
> over the weekend and results are really promising (1x1 fillRect to measure
> pipeline-overhead, 20x20 aa oval to get an impression data-heavy buffer
> interaction):
>
> Test(graphics.render.tests.fillRect) averaged 1.4837645794468326E7
> pixels/sec
>with !antialias, to VolatileImg(), ident, SrcOver, single, width1, 1x1,
> !clip, bounce, Default, !xormode, !alphacolor, !extraalpha
> Test(graphics.render.tests.fillOval) averaged 3.896264839428713E7
> pixels/sec
>with !alphacolor, SrcOver, 20x20, Default, antialias, bounce, !xormode,
> to VolatileImg(), !clip, width1, !extraalpha, single, ident
>
> whereas the original JDK with OGL yielded:
>
> Test(graphics.render.tests.fillRect) averaged 5061909.644344761 pixels/sec
>with single, 1x1, SrcOver, !extraalpha, bounce, Default, !xormode, to
> VolatileImg(), ident, !alphacolor, width1, !antialias, !clip
> Test(graphics.render.tests.fillOval) averaged 1.0837940280832347E7
> pixels/sec
>with single, 20x20, SrcOver, !extraalpha, bounce, Default, !xormode, to
> VolatileImg(), ident, !alphacolor, width1, antialias, !clip
>
> and with XRender:
> Test(graphics.render.tests.fillRect) averaged 2.5252814688096754E7
> pixels/sec
>with ident, to VolatileImg(), 1x1, !clip, !extraalpha, width1,
> !alphacolor, Default, single, bounce, !antialias, !xormode, SrcOver
> All test results:
> Test(graphics.render.tests.fillOval) averaged 2.53725229244114E7 pixels/sec
>with ident, to VolatileImg(), 20x20, !clip, !extraalpha, width1,
> !alphacolor, Default, single, bounce, antialias, !xormode, SrcOver
>

Could you share your patch to let me study it and try improving it ?

Cheers,
Laurent

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

[Laurent Bourgès]

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 on renamed classes, sorry

-

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

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, 
>> MarlinRenderer)
>
> 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 ?

-

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

> - 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 one additional 
commit since the last revision:

  renamed Dxx classes to their original names

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/ebcd0cd3..80428a96

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2076=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2076=02-03

  Stats: 165 lines in 12 files changed: 0 ins; 0 del; 165 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

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 classes to xxx to make code more obvious, readable ?

However, renaming DMarlinRenderingEngine to MarlinRenderingEngine may lead 
confusion with previous versions and may be a compatibility issue ? so I would 
prefer keeping DMarlinRenderingEngine now.

What do you think ?

-

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

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).

Sergey, I slightly modified the reviewed change:
see incremental changes: 
https://openjdk.github.io/cr/?repo=jdk=2076=01-02

-

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

> - 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 one additional 
commit since the last revision:

  fixed copyright year + removed useless interfaces (IRendererContext, 
MarlinRenderer)

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/14660d92..ebcd0cd3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2076=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2076=01-02

  Stats: 88 lines in 7 files changed: 0 ins; 75 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

Hi Clemens,

It reminds me our discussion few years ago, when I experimented opengl on
linux and tuned the OGLRenderQueue for the Marlin renderer, see:
-
https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/pipe/RenderQueue.java
-
https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/opengl/OGLRenderQueue.java

1. These changes mainly consists in increasing internal queue buffer from
32K to 1 Mb (based on my own performance tests).
Ideally an heuristic (data volume per second) could help estimating the
appropriate queue capacity needed to automatically optimize the producer
writing / consumer reading speed.

I like your idea to have multiple queue producer but a single consumer
means a single Surface destination at 1 time ?
How to do parallel rendering on different surfaces (ogl context switch) ?

2. As the Marlin renderer supports large tiles (up to 256x256), it is very
easy to adjust Marlin tiles at runtime for performance:
-Dsun.java2d.renderer.log=true
-Dsun.java2d.renderer.tileSize_log2=5
-Dsun.java2d.renderer.tileWidth_log2=5

By default, 5 means 2^5 = 32.
Just set larger values: -Dsun.java2d.renderer.tileSize_log2=6
-Dsun.java2d.renderer.tileWidth_log2=6

Finally your proposal is amazing and I could join you in your efforts, if
we publicly work on the same repository (github.com ?)

Cheers,
Happy New Year,

Laurent


Le ven. 15 janv. 2021 à 09:35, Clemens Eisserer  a
écrit :

> Hi,
>
> With solid OpenGL support on Linux being ubiquitous these days and the
> XRender pipeline being a bit of a dead-end (works quite well except
> MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the
> state/performance of the OpenGL pipeline.
> Specifically why it performs sometimes worse compared to XRender, despite
> almost all XRender implementations are running on top of OpenGL these days
> anyway (except proprietary nvidia).
>
> 1. One area where XRender is having an advantage is implicit parallelism.
> While Java is producing X11 protocol, the XServer can concurrently perform
> the drawing operations running on a different core.
> Therefore when running some Swing benchmarks with xrender enabled I see
> java consuming 100% of one core, while the XServer consumes ~50% of another
> one.
> With the OpenGL pipeline on the other hand, just one core is fully loaded
> - despite a similar design (one flusher thread calling into OpenGL, and one
> or more independent threads queuing drawing operations into a buffer).
>
> The reason seems to be the OGLRenderQueue has just one buffer, so either
> the flusher thread is active or a queuing thread but not both.
> I wonder, have there been attempts made to introduce double-buffering here
> and have producers (awt threads) and consumer (queue flusher thread)
> running concurrently here?
>
> 2. Especially MaskFill did perform quite poor in my tests, because drivers
> are typically not optimized for tiny texture uploads (32x32 coverage masks).
> Just stubbing out the subTex2D call improved framerate of one benchmark
> from 100fps to 300fps.
> I have done some prototyping uploading coverage masks via
> Shader_Storage_Buffer_Object, but that requires
> ARB_shader_storage_buffer_object (GL 4.3) as well glBufferStorage (4.4), so
> effectivly OpenGL-4.4.
> On the pro side of this approach composition peaked at about 10GB/s with
> 64x64 mask tiles.
>
> Which leads me to the next question:
> The pipeline currently is written in rather ancient OpenGL-2.x style.
> Once the need to support old OSX versions is gone, the OpenGL pipeline
> would not be enabled be default on any platform.
> Once this is the case, would it be feasable to clean up the code by making
> use of modern GL and by leaving legacy platforms behind?
> Modern 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)

[Laurent Bourgès]

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

Apparently windows x64 build failed: no C compiler found !

-

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

> - 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 one additional 
commit since the last revision:

  fixed invalid Stroker.CAP_BUTT reference

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/806a9053..14660d92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2076=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2076=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

- 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 MarlinRenderingEngine and related classes

Changes: https://git.openjdk.java.net/jdk/pull/2076/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2076=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259681
  Stats: 8573 lines in 15 files changed: 0 ins; 8566 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

PR: https://git.openjdk.java.net/jdk/pull/2076

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

[Laurent Bourgès]

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
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip 
> 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.

This pull request has now been integrated.

Changeset: e4df2098
Author:Laurent Bourgès 
URL:   https://git.openjdk.java.net/jdk/commit/e4df2098
Stats: 345 lines in 7 files changed: 307 ins; 1 del; 37 mod

7018932: Drawing very large coordinates with a dashed Stroke can cause Java to 
hang

Reviewed-by: serb, prr

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java
>  line 902:
> 
>> 900: 
>> 901: // clip rectangle (ymin, ymax, xmin, xmax) including padding:
>> 902: final double[] clipRectPad = new double[4];
> 
> are all the changes to double needed for this ? Or just preparation for 
> removing the float pipeline ?

These change are just enough to make MarlinRenderingEngine (float) pass the new 
test.
Later we will propose to remove the float pipeline.

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java line 45:
> 
>> 43:  */
>> 44: public abstract class SpanShapeRenderer implements ShapeDrawPipe {
>> 45: 
> 
> I suppose this is just clean up when you happened to notice it wasn't used/

Exactly.

> test/jdk/sun/java2d/marlin/StrokedLinePerf.java line 37:
> 
>> 35:  * @bug 7018932
>> 36:  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled 
>> by Marlin renderer)
>> 37:  * @run main/othervm/timeout=10 
>> -Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine StrokedLinePerf
> 
> I hope 10 seconds is enough for a stable test .. not connecting to the 
> windowing system so maybe.

Each render ops take up to 100ms max on my machine, so the test runs in 0.5s on 
my machine.

Would you prefer 30s ? 
Timeout is mandatory to detect test failure = hanging ...

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip 
> 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.

Sergey, is it good now ?
I ran jtreg: OK.

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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.
>>   Fixed CurveClipSplitter (float) to use double-precision for higher
>>   accuracy.
>>   Improved StrokedLineTest to use only bufferedimage rendering.
>
> src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java
>  line 902:
> 
>> 900: 
>> 901: // clip rectangle (ymin, ymax, xmin, xmax) including padding:
>> 902: final double[] clipRectPad = new double[4];
> 
> It does not seem related to this fix? Or an updated test uncovered this?

This fix in Marlin (float) renderer is needed as this numerical precision issue 
was triggered by the StrokedLinePerf using the MarlinRenderingEngine. It is 
very similar to DTransformingPathConsumer2D (but reuse was not trivial).

I propose to remove the MarlinRenderingEngine (single-precision) in a follow-up 
issue ... to simplify the maintenance.

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

> 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
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip 
> 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 additional 
commits since the last revision:

 - fixed copyright year
 - removed invalid jtreg test

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/0592f191..f5dea906

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2013=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2013=05-06

  Stats: 7 lines in 7 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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.
>>   Fixed CurveClipSplitter (float) to use double-precision for higher
>>   accuracy.
>>   Improved StrokedLineTest to use only bufferedimage rendering.
>
> test/jdk/sun/java2d/marlin/StrokedLinePerf.java line 37:
> 
>> 35:  * @bug 7018932
>> 36:  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled 
>> by Marlin renderer)
>> 37:  * @run main DrawingTest7018932
> 
> typo DrawingTest7018932 -> StrokedLinePerf

Removed invalid test

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

> 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
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip 
> 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 additional 
commit since the last revision:

  fixed typo BasicSroke to BasicStroke

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/02cc2cb1..0592f191

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2013=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2013=04-05

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

> 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
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip 
> 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 additional 
commit since the last revision:

  Removed comments in LoopPipe.java

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/3ae23d94..02cc2cb1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2013=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2013=03-04

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

> 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
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip 
> 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 additional 
commit since the last revision:

  Fixed RenderingEngine.strokeTo(clip) to call by default former method.
  Fixed CurveClipSplitter (float) to use double-precision for higher
  accuracy.
  Improved StrokedLineTest to use only bufferedimage rendering.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/4df9ab38..3ae23d94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2013=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2013=02-03

  Stats: 216 lines in 4 files changed: 74 ins; 112 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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 & xrender native pipelines...

Confirmed:
* useAA=true:
sun.java2d.marlin.MarlinRenderingEngine.getAATileGenerator(java.awt.geom.Line2D$Double,
 AffineTransform[[1.0, 0.0, 0.0], [0.0, 1.0, 0.0]], Region[[0, 0 => 400, 400]], 
java.awt.BasicStroke@110e1781, wide, normalized)
* useAA=false:
sun.java2d.marlin.MarlinRenderingEngine.strokeTo(java.awt.geom.Line2D$Double, 
AffineTransform[[1.0, 0.0, 0.0], [0.0, 1.0, 0.0]], Region[[0, 0 => 400, 400]], 
java.awt.BasicStroke@110e1781, wide, normalized, non-AA, 
sun.java2d.pipe.ShapeSpanIterator)

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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/RenderingEngine.java line 257:
> 
>> 255:  * @since 17
>> 256:  */
>> 257: public abstract void strokeTo(Shape src,
> 
> I think we need to clarify the backward compatibility of this change.
>  - If we would like to support the old marlin version via 
> "-Dsun.java2d.renderer" option in jdk17 then adding the new abstract method 
> to this interface breaks this possibility. To support that this method should 
> be made default and call the old strokeTo method.
>  - If support for the old marlin library is not necessary then we could drop 
> the old method from this interface(but preserve it in the 
> MarlinRenderingEngine to have the same marlin codebase), it won't be used 
> anyway.

I like the first proposal: use default class method as RE is an abstract class.

> src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java line 273:
> 
>> 271: (sg2d.strokeHint != SunHints.INTVAL_STROKE_PURE);
>> 272: 
>> 273: // No clipping (pre-jdk17)
> 
> This code is not a part of the marlin, so exists only in the jdk17. Do we 
> need these commented lines here?

Will remove the comment

> test/jdk/sun/java2d/marlin/DrawingTest7018932.java line 42:
> 
>> 40:  * @run main DrawingTest7018932
>> 41:  */
>> 42: public class DrawingTest7018932 extends JPanel {
> 
> This will work only in the headful environment, I suggest something like this:
> /*
>  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
> 
> import java.awt.BasicStroke;
> import java.awt.Graphics2D;
> import java.awt.RenderingHints;
> import java.awt.Stroke;
> import java.awt.geom.Line2D;
> import java.awt.image.BufferedImage;
> 
> import static java.awt.image.BufferedImage.TYPE_INT_ARGB_PRE;
> 
> /*
>  * @test
>  * @bug 7018932
>  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by 
> Marlin renderer)
>  */
> public final class StrokedLinePerf {
> 
> public static void main(String[] args) {
> BufferedImage bi = new BufferedImage(400, 400, TYPE_INT_ARGB_PRE);
> test(bi, true);
> test(bi, false);
> }
> 
> private static void test(BufferedImage bi, boolean useAA) {
> Graphics2D g2d = bi.createGraphics();
> long start = System.nanoTime();
> 
> if (useAA) {
> g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
> RenderingHints.VALUE_ANTIALIAS_ON);
> } else {
> g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
> RenderingHints.VALUE_ANTIALIAS_OFF);
> }
> 
> Stroke stroke = new BasicStroke(2.0f, 1, 0, 1.0f, new float[]{0.0f, 
> 4.0f}, 0.0f);
> g2d.setStroke(stroke);
> 
> //Large values to trigger crash / infinite loop.
> g2d.draw(new Line2D.Double(4.0, 1.794369841E9, 567.0, 
> -2.147483648E9));
> 
> System.out.println("Test duration= " + (1e-6 * (System.nanoTime() - 
> start)) + " ms.");
> g2d.dispose();
> }
> }

Interesting, but BufferedImage rendering may use another java2d pipeline... so 
I will check if LoopPipe.getStrokedSpans() is used by your test code.

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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 {
>> 
>> This will work only in the headful environment, I suggest something like 
>> this:
>> /*
>>  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>  * questions.
>>  */
>> 
>> import java.awt.BasicStroke;
>> import java.awt.Graphics2D;
>> import java.awt.RenderingHints;
>> import java.awt.Stroke;
>> import java.awt.geom.Line2D;
>> import java.awt.image.BufferedImage;
>> 
>> import static java.awt.image.BufferedImage.TYPE_INT_ARGB_PRE;
>> 
>> /*
>>  * @test
>>  * @bug 7018932
>>  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by 
>> Marlin renderer)
>>  */
>> public final class StrokedLinePerf {
>> 
>> public static void main(String[] args) {
>> BufferedImage bi = new BufferedImage(400, 400, TYPE_INT_ARGB_PRE);
>> test(bi, true);
>> test(bi, false);
>> }
>> 
>> private static void test(BufferedImage bi, boolean useAA) {
>> Graphics2D g2d = bi.createGraphics();
>> long start = System.nanoTime();
>> 
>> if (useAA) {
>> g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
>> RenderingHints.VALUE_ANTIALIAS_ON);
>> } else {
>> g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
>> RenderingHints.VALUE_ANTIALIAS_OFF);
>> }
>> 
>> Stroke stroke = new BasicStroke(2.0f, 1, 0, 1.0f, new float[]{0.0f, 
>> 4.0f}, 0.0f);
>> g2d.setStroke(stroke);
>> 
>> //Large values to trigger crash / infinite loop.
>> g2d.draw(new Line2D.Double(4.0, 1.794369841E9, 567.0, 
>> -2.147483648E9));
>> 
>> System.out.println("Test duration= " + (1e-6 * (System.nanoTime() - 
>> start)) + " ms.");
>> g2d.dispose();
>> }
>> }
>
> 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 & xrender native pipelines...

-

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

> 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 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 incrementally with one additional 
commit since the last revision:

  fixed white spaces

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/5785f866..4df9ab38

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2013=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2013=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

> 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 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 incrementally with one additional 
commit since the last revision:

  fixed RenderingEngine.Tracer impl + added DrawingTest7018932 test

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/4d04b85d..5785f866

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2013=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2013=00-01

  Stats: 134 lines in 2 files changed: 134 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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

-

Commit messages:
 - fixed whitespaces
 - jdk-7018932.0

Changes: https://git.openjdk.java.net/jdk/pull/2013/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2013=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-7018932
  Stats: 225 lines in 5 files changed: 219 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

PR: https://git.openjdk.java.net/jdk/pull/2013

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

[Laurent Bourgès]

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 gamma-correction (sRGB
profile) before/after any pixel operation to properly mix colors in RGB
linear space.

As dark shades looks then lighter, in particular for font or thin shapes
(black over white), I implemented several correction algorithms based on
luminance & contrast correction that adjusts alpha values.

It is tricky as the ideal correction would require enlarging stroke width
or polygon fills... but it would change coverage algebra= overlaps... that
may need API enhancements at least. I forgave this direction as no simple &
automatic solution exists.
Finally I have 3 compositor modes: linear / hybrid / perceptual.

See the latest Marlin renderer 0.9.5 EA release notes:
https://github.com/bourgesl/marlin-renderer/releases/tag/v0_9_5_0_EA_b2

Visual comparison:
https://bourgesl.github.io/gamma-correction/GRID_FONT.final/index.html

It is only working up to now on buffered images (off-screen INT_ARGB) but
the performance (java + unsafe) is now as good as the former C software
loops.

I wonder if:
- there is any interest in improving java2d color handling in 2020 ? it is
a behaviour change that must be discussed first.
- how to proceed for a possible OpenJDK integration? Use java code like my
hack or fix C macros / loops to use this new approach / maths ?
- How to fix accelerated pipelines (opengl, directx, metal) too ?
- who would help me ?

Any comment or feedback on this topic ?

Thanks,
Laurent

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

[Laurent Bourgès]

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 2.10, skia
(firefox, android) does...

Cheers,
Laurent

Le ven. 15 mai 2020 à 00:20, Philip Race  a écrit :

> The first EA build of Project Lanai is available at
> https://jdk.java.net/lanai/
>
> This is a new Java2D graphics pipeline for macOS.
>
> It can run the usual client demos, such as SwingSet2 and J2Ddemo,
> and even a large app like an IDE, although not without glitches.
> The EA download page has a link to the list of known, open bugs you can
> consult.
>
> It is a first EA build and there is plenty of work still to be done
> and we have doubtless not tested every situation nor do we have
> every piece of mac hardware out there, so there will be unreported
> issues too.
>
> Please try it, and provide feedback to the lanai-...@openjdk.java.net
> mailing list.
>
> Make sure you specify -Dsun.java2d.metal=true  !!
>
> -phil.
>
>
>
>
>
>

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

[Laurent Bourgès]

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:15 PM, Laurent Bourgès wrote:
>
> 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
> transform determinant is negative (flip bit is ON)
>
> Changes:
> - MarlinRenderingEngine: use abs(at.getDeterminant()) to ensure positive
> value before using sqrt
> - FlipBitTest: new jtreg test reproducing the original problem drawing a
> thin ellipse with a flipped transform
>
> Cheers,
> Laurent
>
>
>
>

-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

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 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
> transform determinant is negative (flip bit is ON)
>
> Changes:
> - MarlinRenderingEngine: use abs(at.getDeterminant()) to ensure positive
> value before using sqrt
> - FlipBitTest: new jtreg test reproducing the original problem drawing a
> thin ellipse with a flipped transform
>
> Cheers,
> Laurent
>
>
>

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

[Laurent Bourgès]

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
transform determinant is negative (flip bit is ON)

Changes:
- MarlinRenderingEngine: use abs(at.getDeterminant()) to ensure positive
value before using sqrt
- FlipBitTest: new jtreg test reproducing the original problem drawing a
thin ellipse with a flipped transform

Cheers,
Laurent

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

[Laurent Bourgès]

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:
>
> 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 the same as the FX fix modulo some moving things
>>> around.
>>>
>>> -phil.
>>>
>>> On 7/29/19, 12:56 AM, Laurent Bourgès wrote:
>>> > 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/
>>> > <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8228711.0/>
>>> >
>>> > This patch is very close to MarlinFX patch integrated last week in
>>> > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789
>>> >
>>> > Changes:
>>> > - Stroker: fixed closePath() to preserve last position and its outcode
>>> > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to
>>> > preserve last position and its outcode
>>> > - Dasher: better precision handling (comparison float value with
>>> epsilon)
>>> > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to
>>> > avoid false positives on long stroked curves (quad / cubic) + lowered
>>> > thresholds
>>> >
>>> > Cheers,
>>> > Laurent
>>>
>>
>>
>> --
>> --
>> Laurent Bourgès
>>
>
>

-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

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 the same as the FX fix modulo some moving things around.
>>
>> -phil.
>>
>> On 7/29/19, 12:56 AM, Laurent Bourgès wrote:
>> > 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/
>> > <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8228711.0/>
>> >
>> > This patch is very close to MarlinFX patch integrated last week in
>> > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789
>> >
>> > Changes:
>> > - Stroker: fixed closePath() to preserve last position and its outcode
>> > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to
>> > preserve last position and its outcode
>> > - Dasher: better precision handling (comparison float value with
>> epsilon)
>> > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to
>> > avoid false positives on long stroked curves (quad / cubic) + lowered
>> > thresholds
>> >
>> > Cheers,
>> > Laurent
>>
>
>
> --
> --
> Laurent Bourgès
>

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

[Laurent Bourgès]

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,
> >
> > 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/
> > <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8228711.0/>
> >
> > This patch is very close to MarlinFX patch integrated last week in
> > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789
> >
> > Changes:
> > - Stroker: fixed closePath() to preserve last position and its outcode
> > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to
> > preserve last position and its outcode
> > - Dasher: better precision handling (comparison float value with epsilon)
> > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to
> > avoid false positives on long stroked curves (quad / cubic) + lowered
> > thresholds
> >
> > Cheers,
> > Laurent
>


-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

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 https://bugs.openjdk.java.net/browse/JDK-8226789

Changes:
- Stroker: fixed closePath() to preserve last position and its outcode
- TransformingPathConsumer2D: fixed PathClipFilter.closePath() to preserve
last position and its outcode
- Dasher: better precision handling (comparison float value with epsilon)
- ClipShapeTest: use preliminary curve subdivision (length > 50px) to avoid
false positives on long stroked curves (quad / cubic) + lowered thresholds

Cheers,
Laurent

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

[Laurent Bourgès]

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 maintained
externally but would mean having a forked openjdk to keep this specific
code.

What are the possible side effects if this change is applied on application
using multiple AppContexts ?

Laurent

Le mer. 30 janv. 2019 à 21:56, Phil Race  a écrit :

> The synopsis - which I rephrased for better English, turns out to still
> not represent most of what is happening here. The synopsis would
> make one think this is mostly about removing an unused abstract class
> and the font changes are a foot note to that. In fact this is MOSTLY
> about removing per-appcontext code in the font code - code which
> just asked for an appcontext and had no direct relationship with the
> AWTSecurityManager class except to check for it in a one time call as a
> cheap way
> of knowing we needed to be prepared to check for multiple contexts.
> If you are removing AWTSecurityManager, the logical thing would be
> to find another way to see if it is multiple appcontexts, not remove all
> the code
> that handles such a case.
> In other words there is an extrapolation here from "AWTSecurityManager is
> gone"
> to "multiple appcontexts are gone" which happens to be true, but does not
> logically follow.
>
> So I thought I was reviewing one thing and it turns out to be quite
> different
> and better summarised as :
> "Remove multiple appcontext support from the font code because
> AWTSecurityManager is being removed"
> The removal of AWTSecurityManager is < 10% of this change ..
>
> Alternatively everything changed in the font code could have been handled
> with this :-
>
> private static boolean maybeMultiAppContext() {
> // Do we have multiple app contexts any more ?
> // Or do we need a new way to check for multiple app contexts ?
> // If not, can we remove this code + its downstream dependencies too in a 
> separate fix ?
> return false;
> }
>
>
> Are there any tests that are also obsoleted ?
>
> I am approving this change (modulo the answer about tests) since the end 
> result will
> be the same but personally I would have split it into an AWT bug and a 2D bug 
> each
> with an appropriate synopsis.
>
> -phil.
>
> On 1/15/19 11:49 AM, Sergey Bylokhov wrote:
>
> Hello.
> Please review the fix for jdk 13.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8216592
> Webrev: http://cr.openjdk.java.net/~serb/8216592/webrev.01
>
> The AWTSecurityManager class is an abstract class which provided
> the AppContext objects through SecurityManager extensions. The plugin
> provided a concrete implementation of this class. Since plugin was
> removed the AWTSecurityManager itself can be removed as well.
>
> Since we currently never set AWTSecurityManager some of our checks like:
> "sm instanceof sun.awt.AWTSecurityManager"
> are always "false". And I dropped the code which uses such
> checks(mostly in the SunFontManager)
>
>
>
>

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

[Laurent Bourgès]

Hi Phil,

> I proposed 2 small fixes for jdk12... still to be done, as better
> solutions are not yet ready and I am completely overbusy on testing Java
> Sorting algorithms.
>
> Maybe I will give up fixing the native renderer, for these reasons:
> - stdlib qsort implementation and performance (bentley qsort 93 or merge
> sort on linux) is platform dependent, so it may take time to validate its
> behaviour (small vs large arrays, not really random, closer to almost
> sorted data)
>
>
> I don't think we should use anyC++  stdlib:: code here if that is what you
> mean.
>

No I proposed to use stdlib (C) qsort(... cmp) as it is done in the same
class to sort initially edges, i.e. see my previous diff => ~1s time.
I prefer focusing on integrating Marlin nonAA (like jfx) to get rid of this
native code, than fixing C code, except such simple change.


>
> Any small improvements we can make by having a better sort in our sources
> would
> be better.
> If they aren't ready for 12, no problem. 13 is around the corner ..
>

Yes, I know, but if you have time, I can propose a very simple Marlin patch
to improve a bit its sorting performance in such extreme case: ~0.5s to
0.22s !


> - AA rendering is now the common case where the Marlin renderer is active
> & fast enough.
>
> Would you accept enabling antialiasing by default in jdk12 ?
> Up to now, RenderingHint.ANTIALIASING_DEFAULT means ANTIALIASING_OFF.
>
>
> That is a big change and I do not think we should do it.
>

Yes it is a one-liner but it can have large impacts, so I agree it should
be discussed in CSR ... so maybe in 13 ?

Cheers,
Laurent



Several users faced performance issues with the native renderer (hidpi,
complex shapes, clipping dashed shapes) where the Marlin renderer performs
far better.

Finally I can now focus on a trivial Marlin patch to tune its sort
algorithm selection...

Cheers,
Laurent

Le jeu. 22 nov. 2018 à 00:04, Sergey Bylokhov 
a écrit :

> Hi, Laurent.
>
> I do not think that we should 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 this plan:
> > - integrate this basic fix in ShapeSpanIterator.c code to use stdlib
> sort (mergesort on linux)
> > - integrate a very simple patch in Marlin renderer to disable insertion
> sort for large arrays: 0.5s to 0.25s, few LOC
> > - postpone my changes to Marlin sort & Marlin nonAA renderer integration
> in OpenJDK 13
> >
> > Will you have time to review 2 small patchs on time ?
>
>

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

[Laurent Bourgès]

Hi sergey,

I proposed 2 small fixes for jdk12... still to be done, as better solutions
are not yet ready and I am completely overbusy on testing Java Sorting
algorithms.

Maybe I will give up fixing the native renderer, for these reasons:
- stdlib qsort implementation and performance (bentley qsort 93 or merge
sort on linux) is platform dependent, so it may take time to validate its
behaviour (small vs large arrays, not really random, closer to almost
sorted data)
- AA rendering is now the common case where the Marlin renderer is active &
fast enough.

Would you accept enabling antialiasing by default in jdk12 ?
Up to now, RenderingHint.ANTIALIASING_DEFAULT means ANTIALIASING_OFF.

Several users faced performance issues with the native renderer (hidpi,
complex shapes, clipping dashed shapes) where the Marlin renderer performs
far better.

Finally I can now focus on a trivial Marlin patch to tune its sort
algorithm selection...

Cheers,
Laurent

Le jeu. 22 nov. 2018 à 00:04, Sergey Bylokhov 
a écrit :

> Hi, Laurent.
>
> I do not think that we should 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 this plan:
> > - integrate this basic fix in ShapeSpanIterator.c code to use stdlib
> sort (mergesort on linux)
> > - integrate a very simple patch in Marlin renderer to disable insertion
> sort for large arrays: 0.5s to 0.25s, few LOC
> > - postpone my changes to Marlin sort & Marlin nonAA renderer integration
> in OpenJDK 13
> >
> > Will you have time to review 2 small patchs on time ?
>
>

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

[Laurent Bourgès]

Hi,
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)
- integrate a very simple patch in Marlin renderer to disable insertion
sort for large arrays: 0.5s to 0.25s, few LOC
- postpone my changes 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 block
> - use qsort() using a new comparator sortSegmentsByCurX
>
> This improves performance in PolyLineTest by 3 times: ~1s vs 3.5s !
> Apparently qsort() is not optimal (comparator can not be inlined by c) so
> it may explain why Marlin (0x0 sampling) is still 2 times faster with its
> custom merge-sort (in-place).
>
> Any idea to improve C sort ?
> Is it good enough ?
>
> - USE_QSORT_X: 1
> oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
> INFOS: Paint Time: 1,081s
> INFOS: Paint Time: 1,058s
> INFOS: Paint Time: 1,067s
>
> - USE_QSORT_X: 0
> oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
> INFOS: Paint Time: 3,318s
> INFOS: Paint Time: 3,258s
> INFOS: Paint Time: 3,273s
>
> Patch:
> diff -r 297450fcab26
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> ---
> a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> Tue Oct 16 23:21:05 2018 +0530
> +++
> b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> Tue Oct 23 22:31:00 2018 +0200
> @@ -1243,6 +1243,18 @@
>  }
>  }
>
> +/* LBO: enable (1) / disable (0) qsort on curx */
> +#define USE_QSORT_X (0)
> +
> +static int CDECL
> +sortSegmentsByCurX(const void *elem1, const void *elem2)
> +{
> +jint x1 = (*(segmentData **)elem1)->curx;
> +jint x2 = (*(segmentData **)elem2)->curx;
> +
> +return (x1 - x2);
> +}
> +
>  static jboolean
>  ShapeSINextSpan(void *state, jint spanbox[])
>  {
> @@ -1378,16 +1390,28 @@
>  seg->curx = x0;
>  seg->cury = y0;
>  seg->error = err;
> +}
>
> -/* 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;
> +if (USE_QSORT_X && (hi - lo) > 100)
> +{
> +/* use quick sort on [lo - hi] range */
> +qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
> +sortSegmentsByCurX);
> +} else {
> +for (cur = lo; cur < hi; cur++) {
> +seg = segmentTable[cur];
> +x0 = seg->curx;
> +
> +/* 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;
>  }
> -segmentTable[new] = seg2;
> +segmentTable[new] = seg;
>  }
> -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 takes up to 15ms per pixel row !
>>
>> I will see if I can adapt Marlin's MergeSort.java to C to have an
>> efficient sort in-place.
>> Do you know if libawt has already an efficient sort instead of porting
>> mine ?
>>
>> PS: "To save the planet, make software more efficient" is my quote of the
>> day !
>>
>> Cheers,
>> Laurent
>>
>

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

[Laurent Bourgès]

Sergey,

Le mer. 24 oct. 2018 à 23:50, Sergey Bylokhov 
a écrit :

> I have no comments about the current proposal(results is good), but is
> that really necessary to have this implementation in native code?
>

1. I read the academic papers "Sort Race", 2016 and I will experiment their
best merge6 sort in Marlin to optimize even better the sort of crossings
(x).

It reports that linux qsort() is instezd a mergesort (sedgewick), not
optimal for ordered/reversed runs, as java Timsort does: stdlib is up to 2
times slower (worst case).

See https://arxiv.org/abs/1609.04471

2. My goal consists in fixing the worst case here, as demonstrated by this
case. I may port my MergeSort to C if interested.

Later we could get rid of this native nln-AA pipeline if we switch to
Marlin NonAA renderer like OpenJFX.

I suppose a JEP or RFE is required, isnt it ?

Cheers,
Laurent


> 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 by 3 times: ~1s vs 3.5s !
> > Apparently qsort() is not optimal (comparator can not be inlined by c)
> so it may explain why Marlin (0x0 sampling) is still 2 times faster with
> its custom merge-sort (in-place).
> >
> > Any idea to improve C sort ?
> > Is it good enough ?
> >
> > - USE_QSORT_X: 1
> > oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
> > INFOS: Paint Time: 1,081s
> > INFOS: Paint Time: 1,058s
> > INFOS: Paint Time: 1,067s
> >
> > - USE_QSORT_X: 0
> > oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
> > INFOS: Paint Time: 3,318s
> > INFOS: Paint Time: 3,258s
> > INFOS: Paint Time: 3,273s
> >
> > Patch:
> > diff -r 297450fcab26
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> > ---
> a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> Tue Oct 16 23:21:05 2018 +0530
> > +++
> b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> Tue Oct 23 22:31:00 2018 +0200
> > @@ -1243,6 +1243,18 @@
> >   }
> >   }
> >
> > +/* LBO: enable (1) / disable (0) qsort on curx */
> > +#define USE_QSORT_X (0)
> > +
> > +static int CDECL
> > +sortSegmentsByCurX(const void *elem1, const void *elem2)
> > +{
> > +jint x1 = (*(segmentData **)elem1)->curx;
> > +jint x2 = (*(segmentData **)elem2)->curx;
> > +
> > +return (x1 - x2);
> > +}
> > +
> >   static jboolean
> >   ShapeSINextSpan(void *state, jint spanbox[])
> >   {
> > @@ -1378,16 +1390,28 @@
> >   seg->curx = x0;
> >   seg->cury = y0;
> >   seg->error = err;
> > +}
> >
> > -/* 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;
> > +if (USE_QSORT_X && (hi - lo) > 100)
> > +{
> > +/* use quick sort on [lo - hi] range */
> > +qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
> > +sortSegmentsByCurX);
> > +} else {
> > +for (cur = lo; cur < hi; cur++) {
> > +seg = segmentTable[cur];
> > +x0 = seg->curx;
> > +
> > +/* 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;
> >   }
> > -segmentTable[new] = seg2;
> > +segmentTable[new] = seg;
> >   }
> > -segmentTable[new] = seg;
> >   }
> >   cur = lo;
> >   }
> >
> > Cheers,
> > Laurent
> >
> > Le mar. 23 oct. 2018 à 08:30, Laurent Bourgès  <mailto:bourges.laur...@gmail.com>> 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 takes up to 15ms per pixel row !
> >
> > I will see if I can adapt Marlin's MergeSort.java to C to have an
> efficient sort in-place.
> > Do you know if libawt has already an efficient sort instead of
> porting mine ?
> >
> > PS: "To save the planet, make software more efficient" is my quote
> of the day !
> >
> > Cheers,
> > Laurent
> >
>
>
> --
> Best regards, Sergey.
>

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

[Laurent Bourgès]

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 by 3 times: ~1s vs 3.5s !
Apparently qsort() is not optimal (comparator can not be inlined by c) so
it may explain why Marlin (0x0 sampling) is still 2 times faster with its
custom merge-sort (in-place).

Any idea to improve C sort ?
Is it good enough ?

- USE_QSORT_X: 1
oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
INFOS: Paint Time: 1,081s
INFOS: Paint Time: 1,058s
INFOS: Paint Time: 1,067s

- USE_QSORT_X: 0
oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
INFOS: Paint Time: 3,318s
INFOS: Paint Time: 3,258s
INFOS: Paint Time: 3,273s

Patch:
diff -r 297450fcab26
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
---
a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
Tue Oct 16 23:21:05 2018 +0530
+++
b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
Tue Oct 23 22:31:00 2018 +0200
@@ -1243,6 +1243,18 @@
 }
 }

+/* LBO: enable (1) / disable (0) qsort on curx */
+#define USE_QSORT_X (0)
+
+static int CDECL
+sortSegmentsByCurX(const void *elem1, const void *elem2)
+{
+jint x1 = (*(segmentData **)elem1)->curx;
+jint x2 = (*(segmentData **)elem2)->curx;
+
+return (x1 - x2);
+}
+
 static jboolean
 ShapeSINextSpan(void *state, jint spanbox[])
 {
@@ -1378,16 +1390,28 @@
 seg->curx = x0;
 seg->cury = y0;
 seg->error = err;
+}

-/* 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;
+if (USE_QSORT_X && (hi - lo) > 100)
+{
+/* use quick sort on [lo - hi] range */
+qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
+sortSegmentsByCurX);
+} else {
+for (cur = lo; cur < hi; cur++) {
+seg = segmentTable[cur];
+x0 = seg->curx;
+
+/* 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;
 }
-segmentTable[new] = seg2;
+segmentTable[new] = seg;
 }
-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 takes up to 15ms per pixel row !
>
> I will see if I can adapt Marlin's MergeSort.java to C to have an
> efficient sort in-place.
> Do you know if libawt has already an efficient sort instead of porting
> mine ?
>
> PS: "To save the planet, make software more efficient" is my quote of the
> day !
>
> Cheers,
> Laurent
>

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

[Laurent Bourgès]

Phil,
Yesterday I started hacking ShapeSpanIterator.c to add stats: the last
stage (sort by x0) is the bottleneck.
In this case every sort takes up to 15ms per pixel row !

I will see if I can adapt Marlin's MergeSort.java to C to have an efficient
sort in-place.
Do you know if libawt has already an efficient sort instead of porting mine
?

PS: "To save the planet, make software more efficient" is my quote of the
day !

Cheers,
Laurent

Le ven. 12 oct. 2018 à 16:37, Philip Race  a écrit :

> If there are no comments in the source, then there is no documentation :-(
> Reverse 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 (75%
> cpu time) and its sort algorithm looks like an insertion sort ...
> If you could give me some explanations (or documentation), I could try
> optimizing this method.
>
> Do you know if it uses an Active Edge Table (AET) or it traverses all
> segments every time ?
> i.e. segmentTable contains only ACTIVE segments or all ?
>
>

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

[Laurent Bourgès]

Phil,
I looked at the hostpot in
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c (75%
cpu time) and its sort algorithm looks like an insertion sort ...
If you could give me some explanations (or documentation), I could try
optimizing this method.

Do you know if it uses an Active Edge Table (AET) or it traverses all
segments every time ?
i.e. segmentTable contains only ACTIVE segments or all ?

static jboolean
ShapeSINextSpan(void *state, jint spanbox[])
{
pathData *pd = (pathData *)state;
int lo, cur, new, hi;
int num = pd->numSegments;
jint x0, x1, y0, err;
jint loy;
int ret = JNI_FALSE;
segmentData **segmentTable;
segmentData *seg;

if (pd->state != STATE_SPAN_STARTED) {
if (!initSegmentTable(pd)) {
/* REMIND: - throw exception? */
pd->lowSegment = num;
return JNI_FALSE;
}
}

lo = pd->lowSegment;
cur = pd->curSegment;
hi = pd->hiSegment;
num = pd->numSegments;
loy = pd->loy;
segmentTable = pd->segmentTable;

while (lo < num) {
if (cur < hi) {
seg = segmentTable[cur];
x0 = seg->curx;
if (x0 >= pd->hix) {
cur = hi;
continue;
}
if (x0 < pd->lox) {
x0 = pd->lox;
}

if (pd->evenodd) {
cur += 2;
if (cur <= hi) {
x1 = segmentTable[cur - 1]->curx;
} else {
x1 = pd->hix;
}
} else {
int wind = seg->windDir;
cur++;

while (JNI_TRUE) {
if (cur >= hi) {
x1 = pd->hix;
break;
}
seg = segmentTable[cur++];
wind += seg->windDir;
if (wind == 0) {
x1 = seg->curx;
break;
}
}
}

if (x1 > pd->hix) {
x1 = pd->hix;
}
if (x1 <= x0) {
continue;
}
spanbox[0] = x0;
spanbox[1] = loy;
spanbox[2] = x1;
spanbox[3] = loy + 1;
ret = JNI_TRUE;
break;
}

if (++loy >= pd->hiy) {
lo = cur = hi = num;
break;
}

/* Go through active segments and toss which end "above" loy */
cur = new = hi;
while (--cur >= lo) {
seg = segmentTable[cur];
if (seg->lasty > loy) {
segmentTable[--new] = seg;
}
}

lo = new;
if (lo == hi && lo < num) {
/* The current list of segments is empty so we need to
 * jump to the beginning of the next set of segments.
 * Since the segments are not clipped to the output
 * area we need to make sure we don't jump "backwards"
 */
seg = segmentTable[lo];
if (loy < seg->cury) {
loy = seg->cury;
}
}

/* Go through new segments and accept any which start "above" loy */
while (hi < num && segmentTable[hi]->cury <= loy) {
hi++;
}

/* Update and sort the active segments by x0 */
for (cur = lo; cur < hi; cur++) {
seg = segmentTable[cur];

/* First update the x0, y0 of the segment */
x0 = seg->curx;
y0 = seg->cury;
err = seg->error;
if (++y0 == loy) {
x0 += seg->bumpx;
err += seg->bumperr;
x0 -= (err >> 31);
err &= ERRSTEP_MAX;
} else {
jlong steps = loy;
steps -= y0 - 1;
y0 = loy;
x0 += (jint) (steps * seg->bumpx);
steps = err + (steps * seg->bumperr);
x0 += (jint) (steps >> 31);
err = ((jint) steps) & ERRSTEP_MAX;
}
seg->curx = x0;
seg->cury = y0;
seg->error = err;








*/* 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;}*
    segmentTable[new] = seg;
}
cur = lo;
}

pd->lowSegment = lo;
pd->hiSegment = hi;
pd->curSegment = cur;
pd->loy = loy;
return ret;
}

Cheers,
Laurent

Le ven

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

[Laurent Bourgès]

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 drawPolyLine ?

Cheers,
Laurent

Le ven. 12 oct. 2018 à 01:15, Phil Race  a écrit :

>
> In my previous email I was asking only about the "older" system,
> precisely because as you confirm below, I wanted to know that
> it was operating on an unscaled graphics.
>
> It is being triggered by the scale. If you add :
> graphics.scale(1.25, 1.25)
> in your application and run on 8 you'll see the window size is
> not changed but the contents are and the test now runs slowly
> like the JDK 9+ case.
>
> I think most primitives (text, images, fills, gradients, untransformed
> rectangle drawing) will be only slightly slower. The same if
> you were drawing anti-aliased lines - they are going to be slow already
> by comparison.
>
> A few similar primitives (drawArc, drawOval, drawPolygon ..) may be
> similarly
> affected but drawPolyLine even has dedicated loops for single pixel wide
> lines
> so may be the most affected when these loops can't be used.
>
> So this is a kind of worse case difference. Untransformed, aliased lines
> are super fast.
> Once you do anything like add anti-aliasing or a transform, they get
> slower.
>
> Note: hidpi does not mean that acceleration is "turned off", rather that
> some operations can no longer be sent to the accelerated pipeline, either
> it doesn't support that mode, or we haven't implemented the necessary code
> to invoke it for that mode.
>
> In Peter's case on Intel there will be no acceleration, since we do not
> enable D3D
> on Intel graphics cards. But on my system the time is identical whether
> I use D3D or not.
>
> But there is something else going on here too.
> Peter's test use 2^16 line segments.
>
> On my windows system at 1.25 scale, this takes 55 seconds to run.
> But 2^15 line segments completes in 10 seconds.
> So 2 x the no. of lines takes approx 5 times as long to run ..
>
> I have a modified version of Peter's program which breaks the polyline
> array
> into subarrays which get passed to multiple calls to drawPolyline.
> It misses joining the last point in ARR[N] to the first point in
> ARR[N+1] but
> I think that should not make much difference but if someone wants to use
> that in a real app they'll need to handle it.
>
> What I see is that using the smaller arrays makes a big difference.
>
> So instead of 60 seconds to draw one 65,536 element polyline, to
> draw 64 polylines of 1,024 elements takes just 1.1 seconds.
> Still not 0.05 but better.
>  From what I can see it is being turned into a huge GeneralPath and
> rendered as a Shape. Multiple smaller shapes perform better.
> Perhaps we can add a loop that is specific to polygons that will handle
> this better, but that isn't likely to be jumped on .. and obviously
> it will never be *as* fast as narrow lines.
>
> -phil.
>
>
>
> On 10/11/2018 04:26 AM, Peter Hull wrote:
> > Hi Laurent,
> > Thanks for the detailed explanation. I quickly checked on the older
> > Windows system and the Java 11 window was the same size as the Java 8
> > one, implying no scaling was going on (I guess just because it has a
> > lower resolution monitor) - so that confirms your hypothesis.
> >
> > If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> > matter if the window is a bit small. However I believe some higher end
> > systems have much higher scaling factors (2x, 3x?). Is there a general
> > way to specify a 1px line regardless of scaling, because in my case I
> > don't mind 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
>
>

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

[Laurent Bourgès]

John,

Sorry but attachments are rejected if larger than 100 kb, then your email
is being moderated.

You should put resources online, preferably on openjdk.java.net.

Maybe just send text and your diff only and keep images as link on github.

Laurent

Le jeu. 11 oct. 2018 à 19:56, John Neffenger  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).
>
> Thanks for the tip. Right, Web pages and repositories can be deleted, so
> here it is, for the record ...
>
> The symptoms of the problem are the same as in the link below, but they
> appear in AWT and Swing applications instead of JavaFX applications.
>
>JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
>https://bugs.openjdk.java.net/browse/JDK-8188810
>
> The description of the problem on the Java side follows.
>
> Synopsis: Reduce color fringes in FreeType subpixel rendering
>
> The text in Java applications often has severe color fringes when using
> OpenJDK on Ubuntu and other Debian-based distributions because the JDK
> fails to set the LCD filter. Adding two lines of code to the file
> freetypeScaler.c fixed the problem in my tests, without any regression
> errors for other Linux distributions. The patch is attached to this
> message as the file freetypeScaler.diff.
>
> There are some alternatives to setting the filter:
>
>• Bundle the FreeType library by default and always use the new
> Harmony subpixel rendering technique. This option removes the
> uncertainty in the library at the expense of an additional 4.6 megabytes
> to the installed size — an increase of less than one percent. OpenJDK 12
> even includes the latest FreeType 2.9.1, a newer version than the one
> found on most systems.
>
>• Wait another year and see what changes are made to FreeType, if
> any, when the ClearType patents expire. This option, though, doesn’t
> solve the problem that users of Ubuntu and other Debian-based
> distributions have now.
>
> The problem originates in decisions made by the developers of FreeType,
> Debian, Fedora, and OpenJDK concerning the Microsoft ClearType patents [1].
>
>• In 2007, FreeType 2.3.0 added a compiler configuration macro to the
> file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If defined,
> the FreeType library includes patented ClearType techniques in its
> subpixel rendering.
>
>  But there’s a catch. When the ClearType methods are enabled, the
> subpixel rendering is not filtered, which results in severe color
> fringes. Clients of the FreeType library must make an explicit call to
> the function FT_Library_SetLcdFilter to apply color filtering. The
> filter was disabled by default, explained one of its authors, “to avoid
> major surprises to existing clients, including libXft and Cairo which
> already perform some wacky color filtering on top of FreeType.”
>
>• In 2009, Debian created a patch to FreeType 2.3.9, named
> enable-subpixel-rendering.patch, that defines the macro and enables
> ClearType-style rendering. The change log states, “This is considered no
> more or less evil than the bytecode interpreter which we also enable.”
> Ubuntu, based on Debian, applies the patch as well. Fedora created the
> same patch in 2007, named freetype-2.3.0-enable-spr.patch, but does not
> apply the patch by default.
>
>• In 2017, FreeType 2.8.1 included a new subpixel rendering
> technique, called Harmony, that is nearly identical in output to the
> ClearType technique but uses a different algorithm, avoiding the
> patents. FreeType now uses Harmony subpixel rendering when the ClearType
> methods are disabled, with no need for clients to set the LCD filter.
> (This would have been a good time for Debian to remove its subpixel
> rendering patch.) The latest Fedora Workstation 28 runs FreeType 2.8.0,
> which does not include Harmony.
>
>• In 2019, the Microsoft ClearType patents expire.
>
> So now we have two variants of the FreeType library: one that requires a
> function call to set the LCD filter in Ubuntu and other distributions
> based on Debian, and another that doesn’t require the function call in
> Red Hat Enterprise Linux, Oracle Linux, and other distributions based on
> Fedora.
>
> To demonstrate the problem, I built four versions of the JDK from the
> latest OpenJDK sources. I built a version that uses the system FreeType
> library and another that uses the bundled FreeType library. Then I
> changed the OpenJDK code to set the default LCD filter and built the two
> versions again. The four builds were named:
>
> 

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

[Laurent Bourgès]

Hi,

One last thing about Marlin renderer:
it is available since OpenJDK9 and you can tune its subpixels to let say
1x1 ie 1 pixel: -Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0

I ran again the 'slow' test on linux ~ 0.5s:
- 4x faster than Marlin AA defaults
- 6.5x faster than AWT C code (HiDPI)
- still 16x slower than accelerated pipeline (xrender)

OpenJDK Runtime Environment 18.9 (build 11+28)
JAVA_OPTS: -DuseAA=true -Dsun.java2d.uiScale=2.5
-Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0
Java: 11 11+28
oct. 11, 2018 2:36:12 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,747s
oct. 11, 2018 2:36:12 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,553s
oct. 11, 2018 2:36:13 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,559s
oct. 11, 2018 2:36:13 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,55s

Of course, you should enable antialiasing:

 @Override
 protected void paintComponent(Graphics g) {
 super.paintComponent(g);
 Graphics2D graphics = (Graphics2D) g;
+   if (USE_AA) {
+
graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
+   }

PS: In OpenJFX, noAA rendering is using a specific Marlin renderer instance
(1x1 sampling) so it could be applied to Java2D noAA too.

Cheers,
Laurent

Le jeu. 11 oct. 2018 à 13:27, Peter Hull  a écrit :

> Hi Laurent,
> Thanks for the detailed explanation. I quickly checked on the older
> Windows system and the Java 11 window was the same size as the Java 8
> one, implying no scaling was going on (I guess just because it has a
> lower resolution monitor) - so that confirms your hypothesis.
>
> If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> matter if the window is a bit small. However I believe some higher end
> systems have much higher scaling factors (2x, 3x?). Is there a general
> way to specify a 1px line regardless of scaling, because in my case I
> don't mind 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

[Laurent Bourgès]

Hi John & Phil,

I propose the following patch against jdk/client (openjdk12):
diff -r ac510fd737eb
src/java.desktop/share/native/libfontmanager/freetypeScaler.c
--- a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c Thu
Oct 11 14:19:36 2018 +0530
+++ b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c Thu
Oct 11 13:47:04 2018 +0200
@@ -38,6 +38,7 @@
 #include FT_SIZES_H
 #include FT_OUTLINE_H
 #include FT_SYNTHESIS_H
+#include FT_LCD_FILTER_H

 #include "fontscaler.h"

@@ -316,6 +317,8 @@
 free(scalerInfo);
 return 0;
 }
+/* enable LCD filter */
+FT_Library_SetLcdFilter(scalerInfo->library, FT_LCD_FILTER_DEFAULT);

 return ptr_to_jlong(scalerInfo);
 }

I tested it against OpenJDK11 and it fixed the problem of color fringes on
my ubuntu 18.4 (see screenshot):
http://cr.openjdk.java.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 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
>> Enhancement described below:
>>
>> OpenJDK FreeType Font Fix
>> https://github.com/jgneff/openjdk-freetype
>>
>> Thank you,
>> John
>>
>> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>>
>

-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

he approx size on this) and the other is
> with -Dsun.java2d.uiScale=1.0.
> The window title contains 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

[Laurent Bourgès]

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
> Enhancement described below:
>
> OpenJDK FreeType Font Fix
> https://github.com/jgneff/openjdk-freetype
>
> Thank you,
> John
>
> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>

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

[Laurent Bourgès]

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
> problem in Java. I would like your feedback on the Request for
> Enhancement described below:
>
> OpenJDK FreeType Font Fix
> https://github.com/jgneff/openjdk-freetype
>
> Thank you,
> John
>
> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>

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

[Laurent Bourgès]

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 11, the window size was bigger. I assume this is
> due to the HiDPI support added in Java 9 (my display scaling is set to
> 125%, which is the 'recommended' setting)
>
> Are there any options I can pass to java.exe which would turn off
> scaling - that might help to narrow down the problem.
>

I think it is -Djava2d.ui.scale=1.0 AFAIR.


> By the way, I tried it on a Mac, it was also 'fast', so it just seems
> to be Windows at the moment. I would appreciate it if someone else on
> Windows could check it out.
>

I can run tests in windows but i5+ discrete nvidia card.

You should run java2d in verbose mode to see if your intel gpu is not
supported by jdk11.
 It could then use software rendering as fallback and explain the slowdown.

Cheers,
Laurent

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

[Laurent Bourgès]

   frame.setVisible(true);
+}
+});
 }
-
+
 }

Le mar. 9 oct. 2018 à 15:29, Peter Hull  a écrit :

> I posted this message first on Java Discuss and was asked to file a Java
> bug. It was also suggested I post it here for discussion.
>
> I've recently started using Java 11 and noticed that drawPolyline is
> much slower on my PC than it was on Java 8.
> Example, simplified code:
> @Override
> protected void paintComponent(Graphics g) {
> super.paintComponent(g);
> Graphics2D graphics = (Graphics2D) g;
> long starttime = System.nanoTime();
> graphics.drawPolyline(xs, ys, xs.length);
> long endtime = System.nanoTime();
> Logger.getLogger(this.getClass().getName()).log(Level.INFO,
> "Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9);
> }
> where xs[] and ys[] are large (65536 points) integer arrays. On Java 8 I
> get a paint time of 0.025s and on Java 11 it is 25s, i.e. factor of 1000.
>
> This may be related to JEP263 (HiDPI)
>
> I've got a recent Core i7 processor with Intel graphics, running Windows
> 10.
>
> With VisualVM I can see that all the time goes in drawPolyline, I can't
> get any more detail than that.
>
> I have done some experimentation with RenderingHints but nothing makes the
> JDK11 go as fast as JDK8.
>
> Is there anything else I can try to either improve matters or to provide a
> clearer idea of why there is such a difference?
>
> I have a self-contained NetBeans project if anyone wants to try to see
> they can reproduce this.
> https://github.com/pedro-w/PolylineTest.git
>
> Thanks,
> Peter
>
>
> Versions:
> openjdk version "11" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 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

[Laurent Bourgès]

Phil,

Le ven. 5 oct. 2018 à 08:06, Philip Race  a écrit :

> Yep .. I vaguely remembered that we had such a report but would also have
> had to hunt to locate it.
>
> So we have the probable reason but not the solution.
>
> FWIW I think it would be a fun project for a LCMS developer ...
>

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 tune gcc options.
I would not make MT in lcms as it can affect MT in java.
Maybe PDFImage could convert tiles instead of the all image ?

Anyway I will publish my lknux perf report showing time spent in kcms /
lcms asap.

PS: I tested OpenJDK8 and perf is on par with OpenJDK9.

Laurent



> On 10/4/18, 10:47 PM, Daniel Persson wrote:
>
> Hi Phil.
>
> Well it seems like you've been in this discussion before
>
> https://bugs.openjdk.java.net/browse/JDK-8041125
>
> Wasn't aware that PDFBox PDF2Image used the Kcms Provider per default.
> You may close this issue as we have figured out the reason.
>
> Best regards
> Daniel
>
> On Fri, Oct 5, 2018 at 7:27 AM Philip Race  wrote:
>
>>
>>
>> On 10/4/18, 10:22 PM, Daniel Persson wrote:
>>
>> Hi Laurent
>>
>> Well that seems like a reasonable assumption.
>>
>> https://github.com/kalaspuffar/ColorConvTest/blob/master/KCMSTest.md
>>
>> The test with a "blank" image has a 1 seconds difference.
>>
>> And the test with an image from the PDF in question have a 52 seconds
>> difference.
>>
>>
>> I tried playing with different image data but I didn't see a sensitivity
>> to that.
>> Maybe I needed to try something more complex.
>>
>>
>> So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
>> Does this provider make a worse result on the image?
>>
>> It is not open source. It cannot be part of OpenJDK. Ever.
>> And see my other email for the other reasons.
>> So 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 other closed source components.
>>
>> -phil.
>>
>> Best regards
>> Daniel
>>
>>
>>
>>
>> On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourgès 
>> wrote:
>>
>>> Phil,
>>> I just gg a bit and got the PDFImage source:
>>>
>>> public static void main( String[] args ) throws IOException
>>> 79 {
>>> 80 try
>>> 81 {
>>> 82 // force KCMS (faster than LCMS) if available
>>> 83 Class.forName("sun.java2d.cmm.kcms.KcmsServiceProvider");
>>> 84 System.setProperty("sun.java2d.cmm",
>>> "sun.java2d.cmm.kcms.KcmsServiceProvider");
>>> 85 }
>>> 86 catch (ClassNotFoundException e)
>>> 87 {
>>> 88 LOG.debug("KCMS service not found - using LCMS", e);
>>> 89 }
>>> 90
>>>
>>>
>>> https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFToImage.java?revision=1829374=markup
>>>
>>> That's all folks !
>>>
>>> Le ven. 5 oct. 2018 à 01:00, Philip Race  a
>>> écrit :
>>>
>>>> Yep. LCMS is the default in 8u.
>>>>
>>>> And although KCMS is a lot faster  on my CConv test ...
>>>>
>>>> ~/jdk8u181/bin/java CConv
>>>> 13289
>>>>
>>>>  ~/jdk8u181/bin/java
>>>> -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider CConv
>>>> 5131
>>>>
>>>>
>>>> It makes no difference on the pdf conversion :
>>>>
>>>> ~/jdk8u181/bin/java -jar pdfbox-app-2.0.11.jar PDFToImage  -time
>>>> test.pdf Rendered 1 page in 4985ms
>>>>
>>>> ~/jdk8u181/bin/java
>>>> -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider -jar
>>>> pdfbox-app-2.0.11.jar PDFToImage  -time test.pdf
>>>> Rendered 1 page in 4723ms
>>>>
>>>>
>>>> Note: KCMS maybe faster on CConv but it has no support for modern ICC
>>>> profiles
>>>> and I haven't checked if it is even applying the pdfbox one properly.
>>>> But it does have support to split a job into concurrent tasks for
>>>> sub-images
>>>> which can help on the larger images like 

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

[Laurent Bourgès]

Phil,
I just gg a bit and got the PDFImage source:

public static void main( String[] args ) throws IOException
79 {
80 try
81 {
82 // force KCMS (faster than LCMS) if available
83 Class.forName("sun.java2d.cmm.kcms.KcmsServiceProvider");
84 System.setProperty("sun.java2d.cmm",
"sun.java2d.cmm.kcms.KcmsServiceProvider");
85 }
86 catch (ClassNotFoundException e)
87 {
88 LOG.debug("KCMS service not found - using LCMS", e);
89 }
90

https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFToImage.java?revision=1829374=markup

That's all folks !

Le ven. 5 oct. 2018 à 01:00, Philip Race  a écrit :

> Yep. LCMS is the default in 8u.
>
> And although KCMS is a lot faster  on my CConv test ...
>
> ~/jdk8u181/bin/java CConv
> 13289
>
>  ~/jdk8u181/bin/java
> -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider CConv
> 5131
>
>
> It makes no difference on the pdf conversion :
>
> ~/jdk8u181/bin/java -jar pdfbox-app-2.0.11.jar PDFToImage  -time test.pdf
> Rendered 1 page in 4985ms
>
> ~/jdk8u181/bin/java
> -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider -jar
> pdfbox-app-2.0.11.jar PDFToImage  -time test.pdf
> Rendered 1 page in 4723ms
>
>
> Note: KCMS maybe faster on CConv but it has no support for modern ICC
> profiles
> and I haven't checked if it is even applying the pdfbox one properly.
> But it does have support to split a job into concurrent tasks for
> sub-images
> which can help on the larger images like the one I am using in CConv.
>
> -phil.
>
> On 10/4/18, 2:24 PM, Philip Race wrote:
>
> 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/4/18, 11:33 AM, Laurent Bourgès wrote:
>
> Phil,
> I wondered if ang RenderingHint defaults changed since 8...
>
> Moreover I started playing with linux perf + jit agent and it is easy than
> before wigh oprofile + jvmtiagent.
>
> I noticed that OracleJDK8 uses KCMS and OpenJDK11 uses LCMS for color
> conversion as does OpenJDK8, that could explain the performance gap.
>
> Finally PDFImage test is run only once so the overhead may come from
> warmup (jit, g1)...
>
> More later,
> Laurent
>
> Le jeu. 4 oct. 2018 à 20:03, Phil Race  a écrit :
>
>>
>>
>> On 10/03/2018 11:58 PM, Laurent Bourgès wrote:
>>
>> Hi,
>> I will get the code and add debugging logs: env & system properties and
>> java2d RenderingHints.
>>
>>
>> The code in pdfbox passes null for the hints. So there should be no
>> difference attributable to that.
>>
>> -phil.
>>
>>
>> I suspect these hints are different or have a noticiable impact: color
>> interpolation & rendering quality.
>>
>> I suppose the backend corresponds to software loops but some 2d
>> operations can be accelerated ?
>>
>> Anyway I will push any change in the code.
>>
>> PS: I can run linux perf to profile both java & native code
>>
>> Cheers,
>> Laurent
>>
>> Le jeu. 4 oct. 2018 à 07:50, Daniel Persson  a
>> écrit :
>>
>>> Hi Philip and Laurent.
>>>
>>> I've talked with Tilman and Andreas from the PDFBox team and they see
>>> similar connections to the ColorConvertOp filter but wanted to try with one
>>> of the images of the PDF as a raster.
>>>
>>> As we try different things I thought it good for collaboration to create
>>> a repository with the code so all can contribute.
>>>
>>> https://github.com/kalaspuffar/ColorConvTest
>>>
>>> I've run the 3 different tests on my Machine (Thinkpad P51s) with custom
>>> Gentoo installed, if important to the conversation.
>>>
>>> I tried to invite you all as collaborators to this repository if you
>>> think this is a bad Idea let me know.
>>>
>>> Best regards
>>> Daniel
>>>
>>> On Wed, Oct 3, 2018 at 7:51 PM Laurent Bourgès <
>>> bourges.laur...@gmail.com> 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
>>>>
>>>> Le mer. 3 oct. 2018 à 19:19, Philip Race  a
>>>> écrit :
>>>>
>>>>&g

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

[Laurent Bourgès]

Hi,
I will get the code and add debugging logs: env & system properties and
java2d RenderingHints.

I suspect these hints are different or have a noticiable impact: color
interpolation & rendering quality.

I suppose the backend corresponds to software loops but some 2d operations
can be accelerated ?

Anyway I will push any change in the code.

PS: I can run linux perf to profile both java & native code

Cheers,
Laurent

Le jeu. 4 oct. 2018 à 07:50, Daniel Persson  a
écrit :

> Hi Philip and Laurent.
>
> I've talked with Tilman and Andreas from the PDFBox team and they see
> similar connections to the ColorConvertOp filter but wanted to try with one
> of the images of the PDF as a raster.
>
> As we try different things I thought it good for collaboration to create a
> repository with the code so all can contribute.
>
> https://github.com/kalaspuffar/ColorConvTest
>
> I've run the 3 different tests on my Machine (Thinkpad P51s) with custom
> Gentoo installed, if important to the conversation.
>
> I tried to invite you all as collaborators to this repository if you think
> this is a bad Idea let me know.
>
> 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
>>
>> 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, it has large images that exceed 2k so
>>> such ones may be more costly to convert.
>>>
>>>
>>> FWIW the one I profiled was by far the largest at 2577x1540.
>>> The rest are more like 100x100, 200x200 or 500x500 - all approximations.
>>>
>>>
>>> As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause
>>> more ColorConvertOp filter operations ... if color profiles are different.
>>>
>>>
>>> That doesn't seem likely and in fact since I  instrumented
>>> ColorConvertOp in 8 & 11,  I know exactly how many times it was invoked
>>> by pdfbox, (11 times in both cases) and that all the image data is the
>>> same. SRC and DEST are the same types etc.
>>>
>>> Also the version of LCMS is the same in 8 and 11 (v2.9).
>>>
>>> -phil
>>>
>>>
>>> Anyway this performance is not related to Marlin renderer, so I can not
>>> help much except in its diagnostic.
>>>
>>> Cheers,
>>> Laurent
>>>
>>> Le mar. 2 oct. 2018 à 23:35, Philip Race  a
>>> écrit :
>>>
>>>> I've spent some time examining what pdfbox is passing to ColorConvertOp
>>>> It is called about 10 or 11 times in this test with images typically
>>>> 1-2K in each dimension.
>>>> The input image is a Custom BufferedImage which uses an ICC_ColorSpace
>>>> constructed
>>>> from a color profile file that is embedded in pdfbox which is an open
>>>> source equivalent
>>>> of what Acrobat uses. It has a 4 component raster and is opaque
>>>>
>>>> This is filtered into a 3 component standard INT_RGB ColorModel.
>>>>
>>>> I've distilled this down into a small program which has an copy of the
>>>> method
>>>> that is defined in pdfbox and is invoking the supposedly slow
>>>> ColorConvertOp.
>>>>
>>>> So I believe this is all exactly what is happening in pdfbox.
>>>>
>>>> What I find is that it is actually much faster on JDK11 than JDK 8.
>>>>
>>>> prrubuntu:~$ ~/jdk-11/bin/java CConv
>>>> 4881
>>>> prrubuntu:~$ ~/jdk8u181/bin/java CConv
>>>> 12529
>>>>
>>>>
>>>> I can't say why that would be but the results are clear.
>>>> 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, Laurent Bourgès wrote:
>>>>
>>>> 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
>>>>> http://uhash.com/java_reg/Call_Tree_java_11.html
>>>>>
>>>>> You can see that ConvertOp.filter takes 1.5s longer on Java 11.
>>>>>
>>>>
>>>> I confirm: 1.8s vs 300ms.
>>>>
>>>> Philip, do you know what could have change in this 2d area ?
>>>>
>>>> I imagine ColorConvertOp delegates to native code so color profile
>>>> (ICC) or hidpi support may have an impact here (or just compiler options
>>>> may be different) ...
>>>>
>>>> If needed, I could profile native code using oprofile / perf.
>>>>
>>>> Laurent
>>>>
>>>>

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

[Laurent Bourgès]

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, it has large images that exceed 2k so
> such ones may be more costly to convert.
>
>
> FWIW the one I profiled was by far the largest at 2577x1540.
> The rest are more like 100x100, 200x200 or 500x500 - all approximations.
>
>
> As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause
> more ColorConvertOp filter operations ... if color profiles are different.
>
>
> That doesn't seem likely and in fact since I  instrumented ColorConvertOp
> in 8 & 11,  I know exactly how many times it was invoked
> by pdfbox, (11 times in both cases) and that all the image data is the
> same. SRC and DEST are the same types etc.
>
> Also the version of LCMS is the same in 8 and 11 (v2.9).
>
> -phil
>
>
> Anyway this performance is not related to Marlin renderer, so I can not
> help much except in its diagnostic.
>
> Cheers,
> Laurent
>
> Le mar. 2 oct. 2018 à 23:35, Philip Race  a
> écrit :
>
>> I've spent some time examining what pdfbox is passing to ColorConvertOp
>> It is called about 10 or 11 times in this test with images typically 1-2K
>> in each dimension.
>> The input image is a Custom BufferedImage which uses an ICC_ColorSpace
>> constructed
>> from a color profile file that is embedded in pdfbox which is an open
>> source equivalent
>> of what Acrobat uses. It has a 4 component raster and is opaque
>>
>> This is filtered into a 3 component standard INT_RGB ColorModel.
>>
>> I've distilled this down into a small program which has an copy of the
>> method
>> that is defined in pdfbox and is invoking the supposedly slow
>> ColorConvertOp.
>>
>> So I believe this is all exactly what is happening in pdfbox.
>>
>> What I find is that it is actually much faster on JDK11 than JDK 8.
>>
>> prrubuntu:~$ ~/jdk-11/bin/java CConv
>> 4881
>> prrubuntu:~$ ~/jdk8u181/bin/java CConv
>> 12529
>>
>>
>> I can't say why that would be but the results are clear.
>> 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, Laurent Bourgès wrote:
>>
>> 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
>>> http://uhash.com/java_reg/Call_Tree_java_11.html
>>>
>>> You can see that ConvertOp.filter takes 1.5s longer on Java 11.
>>>
>>
>> I confirm: 1.8s vs 300ms.
>>
>> Philip, do you know what could have change in this 2d area ?
>>
>> I imagine ColorConvertOp delegates to native code so color profile (ICC)
>> or hidpi support may have an impact here (or just compiler options may be
>> different) ...
>>
>> If needed, I could profile native code using oprofile / perf.
>>
>> Laurent
>>
>>

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

[Laurent Bourgès]

Phil,

If you look at the given pdf file, it has large images that exceed 2k so
such ones may be more costly to convert.

As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause
more ColorConvertOp filter operations ... if color profiles are different.

Anyway this performance is not related to Marlin renderer, so I can not
help much except in its diagnostic.

Cheers,
Laurent

Le mar. 2 oct. 2018 à 23:35, Philip Race  a écrit :

> I've spent some time examining what pdfbox is passing to ColorConvertOp
> It is called about 10 or 11 times in this test with images typically 1-2K
> in each dimension.
> The input image is a Custom BufferedImage which uses an ICC_ColorSpace
> constructed
> from a color profile file that is embedded in pdfbox which is an open
> source equivalent
> of what Acrobat uses. It has a 4 component raster and is opaque
>
> This is filtered into a 3 component standard INT_RGB ColorModel.
>
> I've distilled this down into a small program which has an copy of the
> method
> that is defined in pdfbox and is invoking the supposedly slow
> ColorConvertOp.
>
> So I believe this is all exactly what is happening in pdfbox.
>
> What I find is that it is actually much faster on JDK11 than JDK 8.
>
> prrubuntu:~$ ~/jdk-11/bin/java CConv
> 4881
> prrubuntu:~$ ~/jdk8u181/bin/java CConv
> 12529
>
>
> I can't say why that would be but the results are clear.
> 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, Laurent Bourgès wrote:
>
> 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
>> http://uhash.com/java_reg/Call_Tree_java_11.html
>>
>> You can see that ConvertOp.filter takes 1.5s longer on Java 11.
>>
>
> I confirm: 1.8s vs 300ms.
>
> Philip, do you know what could have change in this 2d area ?
>
> I imagine ColorConvertOp delegates to native code so color profile (ICC)
> or hidpi support may have an impact here (or just compiler options may be
> different) ...
>
> If needed, I could profile native code using oprofile / perf.
>
> Laurent
>
>

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

[Laurent Bourgès]

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
> http://uhash.com/java_reg/Call_Tree_java_11.html
>
> You can see that ConvertOp.filter takes 1.5s longer on Java 11.
>

I confirm: 1.8s vs 300ms.

Philip, do you know what could have change in this 2d area ?

I imagine ColorConvertOp delegates to native code so color profile (ICC) or
hidpi support may have an impact here (or just compiler options may be
different) ...

If needed, I could profile native code using oprofile / perf.

Laurent

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

[Laurent Bourgès]

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 that didn't change in any big way
> since JDK 8u.
>
> Perhaps something has changed so that it is now [considered] needed
> whereas before
> it was not? So did it go from zero percent to 29% or from 10% to 29% ?
>
> But even that doesn't on it own account for everything.
> 29% of 8 seconds would be about 2.5 seconds and doesn't explain going from
> < 3 seconds to 8 seconds .. we are still missing at least 2.5 seconds ..
>
>
> -phil.
>
> On 9/26/18, 11:08 AM, Daniel Persson wrote:
>
> Hi Phil
>
> What the PDFBox team told me it could have something to do with color
> mapping.
>
> And my quick profiling shows that the code spends 29% of the time inside
> of java.awt.image.ColorConvertOp.filter on java 11
>
> But I'll open a issue.
>
> Best regards
> Daniel
>
> On Wed, Sep 26, 2018, 19:33 Phil Race  wrote:
>
>> Multiple pieces are changing across these releases.
>>
>> Is it the JPEG writing ? Is it freetype vs t2k (font performance)
>> is it harfbuzz vs icu (text layout), is it marlin vs ductus
>> (rasterization) ?
>>
>> So it is very hard to say with any certainty what the cause of the
>> difference is .. or
>> why 10 got so much better than 9  .. even if still not back to JDK 8.
>>
>> Please file a bug at java.com.
>>
>> -phil.
>>
>> On 09/25/2018 10:42 PM, Daniel Persson wrote:
>> > Hi everyone,
>> >
>> > We render a lot of images with PDFBox with Java 1.8.0 and we want to
>> > upgrade to the current OpenJDK 11 but sadly we see some performance
>> > degradation switching over to OpenJDK. Anyone have a suggestion to
>> > remedy this issue, or can explain why it is slower?
>> >
>> > Using the PDFBox app current release downloadable from
>> > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar
>> >
>> > Running the command
>> > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf
>> >
>> > We see the following result
>> >
>> > -
>> > java version "1.8.0_181"
>> > Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
>> > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>> > Rendered 1 page in 2762ms
>> > -
>> > openjdk version "9.0.4"
>> > OpenJDK Runtime Environment (build 9.0.4+11)
>> > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
>> > Rendered 1 page in 8034ms
>> > -
>> > openjdk version "10.0.2" 2018-07-17
>> > OpenJDK Runtime Environment 18.3 (build 10.0.2+13)
>> > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
>> > Rendered 1 page in 4255ms
>> > -
>> > openjdk version "11" 2018-09-25
>> > OpenJDK Runtime Environment 18.9 (build 11+28)
>> > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>> > Rendered 1 page in 4275ms
>> > -
>> > openjdk version "12-ea" 2019-03-19
>> > OpenJDK Runtime Environment 19.3 (build 12-ea+11)
>> > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode)
>> > Rendered 1 page in 4399ms
>> >
>> > The pdf file used in this example can be downloaded from
>> >
>> https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing
>> >
>> > Best regards
>> > Daniel
>>
>>

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

[Laurent Bourgès]

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 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 opened in OpenJDK ?
>
>>
>>  >  PS: What is the process to ask for backport to JDK11 updates ?
>>
>> If you think this important enough to backport, then this is the process :
>>
>> http://openjdk.java.net/projects/jdk-updates/approval.html
>
>
> I fixed these bugs as I was contacted on the Marlin mailing list by an end
> user testing the migration of its Map viewer app from jdk8 to OpenJDK11.
>
> I made this patch as small as possible that is compatible with OpenJDK
> 11/12 and is well tested: low risk.
> For 12, I will propose a more important patch later to upgrade to Marlin
> 0.9.3
>
> As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it
> is worth fixing it in 11 too.
>
> Any other opinion ?
>
> PS: I will fix OpenJFX 11/12 soon
>
> Cheers,
> Laurent
>

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

[Laurent Bourgès]

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.
>> 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 opened in OpenJDK ?
>
>
>
> I ran the closed source tests not because there were critical tests there
> so much
> as it would be stupid not to when it is easier than not running them :-)
>
> There are still many client closed source test that could be open sourced
> although
> only a tiny fraction might be applicable here. We open source these as we
> find time ..
>
>
>
>>  >  PS: What is the process to ask for backport to JDK11 updates ?
>>
>> If you think this important enough to backport, then this is the process :
>>
>> http://openjdk.java.net/projects/jdk-updates/approval.html
>
>
> I fixed these bugs as I was contacted on the Marlin mailing list by an end
> user testing the migration of its Map viewer app from jdk8 to OpenJDK11.
>
> I made this patch as small as possible that is compatible with OpenJDK
> 11/12 and is well tested: low risk.
> For 12, I will propose a more important patch later to upgrade to Marlin
> 0.9.3
>
> As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it
> is worth fixing it in 11 too.
>
> Any other opinion ?
>
>
> I am fine with it. But it is the 11 updates maintainers who need to
> approve.
>
> -phil.
>
>
> PS: I will fix OpenJFX 11/12 soon
>
> Cheers,
> Laurent
>
>
>

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

[Laurent Bourgès]

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 opened in OpenJDK ?

>
>  >  PS: What is the process to ask for backport to JDK11 updates ?
>
> If you think this important enough to backport, then this is the process :
>
> http://openjdk.java.net/projects/jdk-updates/approval.html


I fixed these bugs as I was contacted on the Marlin mailing list by an end
user testing the migration of its Map viewer app from jdk8 to OpenJDK11.

I made this patch as small as possible that is compatible with OpenJDK
11/12 and is well tested: low risk.
For 12, I will propose a more important patch later to upgrade to Marlin
0.9.3

As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it is
worth fixing it in 11 too.

Any other opinion ?

PS: I will fix OpenJFX 11/12 soon

Cheers,
Laurent

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

[Laurent Bourgès]

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)
- MarlinRenderingEngine: prepare once the clip with small margin + renderer
offset
- TransformingPathConsumer2D:
- missing min < max in adjustClipScale() if scale < 0
   - compute mean inverse scale factor to be used in CurveClipSplitter to
perform proper length checks to avoid too many subdivision

PS: What is the process to ask for backport to JDK11 updates ?

Cheers,
Laurent

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

[Laurent Bourgès]

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 07/05/2018 09:39, Philip Race wrote:
>> Sergey, what do you think ?

We can request a backport after the push to jdk11, if no new issues will
be found.



-- 
Best regards, Sergey.

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

[Laurent Bourgès]

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.

>
> I am not sure if a backport to 10 will be approved under the new
> guidelines :
>
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-April/000102.html


Agreed, it is not P1 but the reporter mentioned his swing app was hanging
in some case at startup so this bug causes some stability problems.

It depends on your opinions if it is worth to be fixed asap or not.
Sergey, what do you think ?

Laurent

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

[Laurent Bourgès]

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 (Unsafe.allocateUninitializedArray) when calling
copyDashArray(). The fix consists in using the correct part [0; dashLen[ as
it was the case in jdk9
- added test that detects wrong dashed rectangle: jtreg fails on jdk10/11
without patch

Notes:
- the thread may hang in init() if the dirty part contains negative values
(normalization loop never exits), but it is very difficult to reproduce and
test.
- My Apologies: I introduced the bug in dec 2016 when I merged MarlinFX /
Marlin2D.


Finally, the proposed fix should be backported to JDK10 and also to OpenJFX
10/11. I can propose a patch to OpenJFX11 soon.

Could somebody else manage the backport process (JDK-update 10, OpenJFX10) ?

Regards,
Laurent

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

[Laurent Bourgès]

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 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
> > successfully although the ClipShapeTest finished in 1200s in total:
> >
> > grep elapsed ClipShapeTest.jtr
> > elapsed=1209067 0\:20\:09.067
> > elapsed time (seconds): 1.131
> > elapsed time (seconds): 1.129
> > elapsed time (seconds): 70.291
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 244.185
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 127.729
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 187.525
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 60.818
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 200.825
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 126.312
> > elapsed time (seconds): 0.0
> > elapsed time (seconds): 190.248
> >
> >
> > Regards,
> > Laurent
>
>
> --
> Best regards, Sergey.
>

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

[Laurent Bourgès]

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
successfully although the ClipShapeTest finished in 1200s in total:

grep elapsed ClipShapeTest.jtr
elapsed=1209067 0\:20\:09.067
elapsed time (seconds): 1.131
elapsed time (seconds): 1.129
elapsed time (seconds): 70.291
elapsed time (seconds): 0.0
elapsed time (seconds): 244.185
elapsed time (seconds): 0.0
elapsed time (seconds): 127.729
elapsed time (seconds): 0.0
elapsed time (seconds): 187.525
elapsed time (seconds): 0.0
elapsed time (seconds): 60.818
elapsed time (seconds): 0.0
elapsed time (seconds): 200.825
elapsed time (seconds): 0.0
elapsed time (seconds): 126.312
elapsed time (seconds): 0.0
elapsed time (seconds): 190.248


Regards,
Laurent

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

[Laurent Bourgès]

Hi Phil,

Thank you a lot for your review and your time on this long & complex review.

2018-03-26 22:50 GMT+02:00 Philip Race <philip.r...@oracle.com>:

> Hi Laurent,
>
> It took me I at least 5 tries to get all the way through this.
>
>
I agree it was a complex patch (clipping) with many other small
improvements, sorry.


> I don't have any substantial comments, just a few clean up questions.
>
>
> What is this in Curve.java + DCurve.java ?
>
> Even if derivatives are totally useless for lines, I removed the condition
to reset these values anyway.

> +if (false) {+dax = 0.0d;+day = 0.0d;+
> dbx = 0.0d;+dby = 0.0d;+}
>
> In Renderer.java, should the commented line be removed ?
>
> +&& ((Math.abs(ddx) + Math.abs(ddy) * _SCALE_DY) <= 
> _INC_BND+// && (Math.abs(ddx + dddx) + Math.abs(ddy + 
> dddy) * _SCALE_DY) <= _INC_BND
>
> A similar pattern occurs a little later in the same file.
>
> +//|| (Math.abs(ddx + dddx) + Math.abs(ddy + dddy) * 
> _SCALE_DY) >= _DEC_BND
>
> Fixed (removed lines)


> +static final float LEN_TH = 
> MarlinProperties.getSubdividerMinLength();
>
> You really meant to name it LEN_TH and not LENGTH ?
>
> That was deliberate, I wanted to shorten LENGTH_THRESHOLD => LEN_TH, not
LENGTH.

There are 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 webrev.
>
> Thank you again,

Laurent


>
> On 3/23/18, 2:03 PM, Laurent Bourgès wrote:
>
> 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 webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/
>>
>> Changes in MarlinProperties only:
>> - getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default = 5
>> (log2)
>>
>> I hope it is good for now as tile settings are the same as in jdk9/10.
>>
>> Regards,
>> Laurent
>>
>>
>> 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 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 vote.
>>> I need another approval I suppose ?
>>>
>>> I will prepare another review asap reverting only tile size changes as
>>> using large tiles has performance drop on d3d & ogl that needs more work.
>>> It can be done later in follow-up issues.
>>>
>>> Phil do you agree the proposed plan ?
>>>
>>> Laurent
>>>
>>
>>
>

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

[Laurent Bourgès]

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 webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/
>
> Changes in MarlinProperties only:
> - getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default = 5
> (log2)
>
> I hope it is good for now as tile settings are the same as in jdk9/10.
>
> Regards,
> Laurent
>
>
> 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 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 vote.
>> I need another approval I suppose ?
>>
>> I will prepare another review asap reverting only tile size changes as
>> using large tiles has performance drop on d3d & ogl that needs more work.
>> It can be done later in follow-up issues.
>>
>> Phil do you agree the proposed plan ?
>>
>> Laurent
>>
>
>

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

[Laurent Bourgès]

Hi,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.1/

Changes in MarlinProperties only:
- getTileSize_Log2() & getTileWidth_Log2(); 32x32 tiles ie default = 5
(log2)

I hope it is good for now as tile settings are the same as in jdk9/10.

Regards,
Laurent

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 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 vote.
> I need another approval I suppose ?
>
> I will prepare another review asap reverting only tile size changes as
> using large tiles has performance drop on d3d & ogl that needs more work.
> It can be done later in follow-up issues.
>
> Phil do you agree the proposed plan ?
>
> Laurent
>

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

[Laurent Bourgès]

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 vote.
I need another approval I suppose ?

I will prepare another review asap reverting only tile size changes as
using large tiles has performance drop on d3d & ogl that needs more work.
It can be done later in follow-up issues.

Phil do you agree the proposed plan ?

Laurent

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

[Laurent Bourgès]

Hi Sergey & Phil,

Could you review the submitted marlin webrev soon ?

I will revert the tile size change in MarlinProperties (6,7 => 5,5) to
avoid any problem for now: 2 lines fix.

As proposed before, supporting larger tiles in 2d pipelines needs many
small tuning and can be done in follow-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 queue is drained too quickly on my fast gpu and is too
>> small to feed the gpu... maybe I am wron
>>
> Profiling will help here. on macOS you can user Instruments which can
> profile cpu and gpu.
>
> Definitely it is more related to awt... and propose to postpone using
>> large tiles on other platforms than linux for the moment.
>>
>> How is it enabled ? Using sun.java2d.d3d=false ?
>>
>
> Yes "sun.java2d.d3d=false" or it can be selected automatically if d3d
> pipeline is unsupported (or video card is blacklisted).
>
>
> --
> Best regards, Sergey.
>

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

[Laurent Bourgès]

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 improve such
> buffer queue to have less synchronization overhead induced by flushNow(),
> and why increasing the buffer improved so much the performance (less JNI
> overhead, more threads ?)
>

It is unclear the reason of speedup, it can be possible that you just fill
the render queue and then calculate some performance numbers before
something was drawn to the destination.

I suppose the queue is drained too quickly on my fast gpu and is too small
to feed the gpu... maybe I am wrong.

I could try adding Toolkit.synch() to ensure rendering ops are finished. I
will have a look to j2dbench source code to better understand. Finally I
have to run j2dbench on windows to have other certified numbers...

Definitely it is more related to awt... and propose to postpone using large
tiles on other platforms than linux for the moment.


I will not test gdi nor x11 as nowadays the officially supported pipelines
> are xrender (linux), opengl (mac) & d3d (windows).
>

If I not missed then by default gdi is used on the Intel HD(which is quite
common).


How is it enabled ? Using sun.java2d.d3d=false ?

Thanks for your help,
Laurent

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

[Laurent Bourgès]

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).
>

Yes APU are very slow compared to discrete cards.

> Finally, J2DBench results do not show any gain on tested cases.
>
> The good news is that actually the Java-process seems to be CPU limited,
> while the XOrg's CPU consumption is actually lower with deferred
> (well, throughput is also lower).
> So the lower throughput seems to have its origin somewhere in client code
> - and is not caused by the fact that deferred is actually uploading
> more pixels to the GPU.
> -> Profiling ;)
>

I have an open source license for Yourkit Profiler, I could try getting
profiles.
I usually use oprofile or perf on linux as it supports java JIT code and
show real cpu counters either on java or native code.

After thinking at your new approach, I think the overhead on nvidia card
comes from the extra mask copies (10%) into the buffer for defered
rendering.
My tests on D3D/OGL pipelines showed buffering gpu commands imply mask
copies into the buffer that is later converted into gpu textures (2 copies)
~ 10%


>
> Does anybody know good statistical profiles these days?
> I have netbeans a try (worked well in the past) but it seems broken,
> VisualVM reports all time is spent in SunGraphics2D.fill/draw without
> providing
> any further details regarding the call stack. Any recommendations?
>

You should change default netbeans settings to monitor ALL classes
(including jdk), not only your code. It works.
Oprofile (or perf) gives more accurate metrics (and now overhead as it is a
kernel access to cpu counters)

However even with tuning, chances are small regressions for
> nvidia+proprietary driver
> (not the open-source one shipped with linux distributions by default)
> will remain.
>

That sounds good for me (10% is low) and your approach gives large gains
for lots of small shapes (up to 50%) so the compromise is OK.
Maybe some extra tuning could reduce the overhead (and we should run
J2DBench intensively with all possible settings), but it will be costly in
time (too).

As large tiles seem only working well on linux xrender, I propose to only
use large tiles in Marlin for linux xrender and use small tiles for D3D /
OpenGL on all platforms.
Agreed ?



> All in all, the market share of linux desktops with nvidia gpus running
> with the
> proprietary drivers is probably limited to linux-gamers and power-users.
>

For years, I always buy a machine with nvidia card as only nvidia has good
binary drivers on linux that offer best performance (as proved here).


>
> For all other drivers, especially glamor based drivers (AMD, Intel, nvidia
> OSS),
> issuing larger PutImage requests results in huge gains.
> And I don't think the situation will change, I tried to lobby for
> improving this workoad for years, without
> a lot of success. The only architecture which was ~okish was Intel-SNA,
> which is now beeing replaced by glamor (which again is performing
> horrible).
>
> As X doesn't provide reliable ways to detect the GPU, we could:
> * tune it and live with the regression on proprietary nvidia GPUs
> * try to detect whether the system is running the proprietary nvidia
> driver (best-guess)
> disable deferred. Would it be worth the trouble?
>

No, I think it is good enough (even some code cleanup + optimization would
be good).
Maybe I should review your patch in details & optimize the mask copy code:
alignment, byte buffer copies may be improved using AVX (varhandle ?)


PS: you current patch does not support extra-alpha so this feature remains
to be implemented in the defered xrender pipeline.


> I started tuning the RenderQueue buffer (32k => 4m) and both d3d & ogl
> gets
> > better but still 10% slower.
>
> I wonder how they would perform with less agressive buffer capacity
> increase?
>

I experimented 1M but also tuned the thread wait delay but this queue seems
tricky to tune.
128x64 = 4 x 2 = 8 tiles 32x32 so the buffer should be increased by x8 at
least => 256K min.

I spent too much time on all these windows / opengl tests, so I will
postpone such tuning / patchs for now once I wrote a detailed benchmark
report (in progress) for possible future work.


> > Maybe xr suffers also from small buffer capacity (128k)...
> Unlikely, before the buffer is full we have to flush most of the time
> because the SHM upload buffer is fully occupied.
> Without deferred, the internal buffer is 16kb.
>

Maybe you should use a system property to define the buffer size in order
to tune it later (J2DBench or MapBench tests) as I did in my RenderQueue
patch.

Best regards,
Laurent

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

[Laurent Bourgès]

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 suffer from discussion lags & being
alone pushing the limits !
I know the java2d team is very small but the community is larger and java
(swing) desktop application like IDE (netbeans, eclipse or idea) are widely
used and necessary for any java development (critical).

Who would join my efforts to run tests, benchmarks ... ?


First Marlin 0.9.1 patch works well: no crash or bug with larger tiles
>> 128x64 even if d3d / opengl uses internally 32x32 texture caches.
>> Moreover xrender pipeline is the fastest compared to D3D (40% slower) or
>> opengl (>250% slower) !
>>
>
> What types of GraphicsPrimitives were tested(in terms of java2d)? I guess
> that d3d/ogl may outperform other pipelines only in case of "native" blits,
> which are used in case of draw of cashed bufferedImage(OGL texture) or
> VolatileImage(FBO) to the window/volatile image(this also depends from the
> composite type and alpha).
>


I just ran my own MapBench tool (1 thread) that performs GeneralPath draw /
fill operations (+ image clear). This tool (source code + binary releases)
is available on my github:
https://github.com/bourgesl/mapbench

MapBench either uses ARGB BufferedImages (sw loops) or VolatileImages
(d3d/ogl/xr accelerated) = maskfill only as I mainly focused on Marlin
performance (AA) as I think AA is generally used in 2018.

(J2DBench does not have proper path tests even if I worked with Jim in 2015
to add specific test cases for GeneralPath + multi-threading).

Finally, I was surprised to see that performance differs so much on the
same hardware (dual boot) between pipelines. Moreover, windows is a major
platform and I supposed java2d d3d pipelines was highly tuned for such
major use case. Of couse, that means there are still many things to improve
in 2018 (fast GPU) for the overall java community benefit.



> In other cases it will be slower since it use an additional layer -
> RenderQueue, it would be good to compare xrender and gdi/X11.
>

Yes d3d/ogl are defered rendering so using RenderQueue buffering has costs
(1 extra mask copy + command arguments). I wonder how to improve such
buffer queue to have less synchronization overhead induced by flushNow(),
and why increasing the buffer improved so much the performance (less JNI
overhead, more threads ?)

I will not test gdi nor x11 as nowadays the officially supported pipelines
are xrender (linux), opengl (mac) & d3d (windows).



>
> Some unrelated question: it is interesting how xrender will work in
> Wayland.
>
>
> Note 1. OGL is not officially supported on linux. We need to check ogl
> performance on macOS where it is used as a default pipeline.
>

1. Yes I know but I wanted to evaluate if my RenderQueue buffer change
impacted positively the opengl pipeline. It improved performance on both
windows & linux by the same order.

2. It takes me a lot of my time to run benchmarks on many platforms (my own
personal machines) so I did not have time yet to test on macOS.

I would really appreciate if I or any Q people could run benchmarks on a
shared testing platform (win, linux, mac, sparc) having all sort of CPU &
GPU.
Would Oracle or adoptopenjdk allow such external access to such a platform
(to be built) ?



>
> Note 2. there are some other blit's related tiles like:
> #define OGLC_BLIT_TILE_SIZE 128
>
> Also please be care about different vendors:
> OGLC_VENDOR_INTEL/OGLC_VENDOR_ATI/OGLC_VENDOR_NVIDIA because their native
> blits are implemented differently. The reason was in a performance of some
> OGL API(maybe this code is outdated).
>

Thanks for the pointer, I will have a look. As said, I want to improve
Marlin performance first.


>
> I suggest to use some common testcases from J2DBench and SwingMark, so at
> some point later it will be possible to check other changes for possible
> regression, for example see:
> https://bugs.openjdk.java.net/browse/JDK-8059944
> Note that this fix in some cases decreased a performance by half but in
> other cases improved it by 25422.21%. You can see we can improve
> performance in one case but lose much more in another. This is why J2DBench
> is better because it can check all combinations of
> src/dst/composite/clip/size/etc..
>

Ok, I will take time to run J2DBench on my machines (with/without patch)
and share the results.


>
> Soory to insist but who could advice me and give me explanations on the
>> RenderQueue & d3d / opengl backends.
>>
>> I read JBS for RenderQueue buffering as I have several questions
>> (asynchronous queue ?)
>> How to auto-tune such buffer capacity ?
>> It seems tricky as too small or too large buffers impacts performance as
>> it depends on the GPU speed (drain the buffer).
>> Is there any design document ?
>>

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

[Laurent Bourgès]

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 internally 32x32 texture caches.
Moreover xrender pipeline is the fastest compared to D3D (40% slower) or
opengl (>250% slower) !

I will share later detailed results (plots) but raw data files are
available (see linux & win files):
https://github.com/bourgesl/bourgesl.github.io/commit/84133d54692affd1d96938a88ac4a041ec0f5e36


As previously mentioned, I increased the RenderQueue buffer (see patchs at
the end) to 4M (instead of 32K) and d3d & opengl get boosted.

Finally, I increased the cached tile sizes in OGLVertexCache.h and opengl
performance achieved xrender performance on linux:

--- /tmp/meld-tmpdLFq6S
+++
/home/graphics-rasterizer/jdk/client/src/java.desktop/share/native/common/java2d/opengl/OGLVertexCache.h
@@ -38,13 +38,13 @@
  * Constants that control the size of the texture tile cache used for
  * mask operations.
  */
-#define OGLVC_MASK_CACHE_TILE_WIDTH   32
-#define OGLVC_MASK_CACHE_TILE_HEIGHT  32
+#define OGLVC_MASK_CACHE_TILE_WIDTH   128   /* 32 */
+#define OGLVC_MASK_CACHE_TILE_HEIGHT  64/* 32 */
 #define OGLVC_MASK_CACHE_TILE_SIZE \
(OGLVC_MASK_CACHE_TILE_WIDTH * OGLVC_MASK_CACHE_TILE_HEIGHT)

-#define OGLVC_MASK_CACHE_WIDTH_IN_TILES   8
-#define OGLVC_MASK_CACHE_HEIGHT_IN_TILES  4
+#define OGLVC_MASK_CACHE_WIDTH_IN_TILES   16
+#define OGLVC_MASK_CACHE_HEIGHT_IN_TILES  8

 #define OGLVC_MASK_CACHE_WIDTH_IN_TEXELS \
(OGLVC_MASK_CACHE_TILE_WIDTH * OGLVC_MASK_CACHE_WIDTH_IN_TILES)


Thanks to Clemens, that explained me its xrender new approach and it
convinced me to tune java2d pipelines.

In conclusion, using larger tiles in Marlin 0.9.1 will allow large gains
either in d3d & opengl pipelines so I plan to propose these new fixes for
jdk11 soon.

News:
> - I modified opengl queue buffer capacity recently and got 30% better
> performance (mapbench) on linux. That could be worth for macOS: will create
> another jbs bug
> - I will work on upgrading MarlinFX to 0.9.1 soon to provide you a patch
> for openjfx 11.
>
> Who can review such patches & help me on improving java2d pipelines
> (discussion, skills) ?
>

Soory to insist but who could advice me and give me explanations on the
RenderQueue & d3d / opengl backends.

I read JBS for RenderQueue buffering as I have several questions
(asynchronous queue ?)
How to auto-tune such buffer capacity ?
It seems tricky as too small or too large buffers impacts performance as it
depends on the GPU speed (drain the buffer).
Is there any design document ?

PS: I will once again look into java2d pipelines for tile constants (32) to
see if other parts should be updated (TexturePaint ?)...
I also need help on testing such patches on many hw platforms to detect
regressions (j2dBench, MapBench...)

Cheers,
Laurent


--- /tmp/meld-tmpFaCMrF
+++
/home/graphics-rasterizer/jdk/client/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,9 +25,12 @@

 package sun.java2d.pipe;

+import java.security.AccessController;
 import java.util.HashSet;
 import java.util.Set;
+
 import sun.awt.SunToolkit;
+import sun.security.action.GetPropertyAction;

 /**
  * The RenderQueue class encapsulates a RenderBuffer on which rendering
@@ -72,20 +75,34 @@
 public abstract class RenderQueue {

 /** The size of the underlying buffer, in bytes. */
-private static final int BUFFER_SIZE = 32000;
+private static final int BUFFER_SIZE;
+
+static {
+BUFFER_SIZE = align(getInteger("sun.java2d.opengl.bufferSize",
4*1024 * 1024, 32 * 1024, 64 * 1024 * 1024), 1024);
+System.out.println("RenderQueue: sun.java2d.opengl.bufferSize =
"+BUFFER_SIZE);
+}

 /** The underlying buffer for this queue. */
-protected RenderBuffer buf;
+protected final RenderBuffer buf;

 /**
  * A Set containing hard references to Objects that must stay alive
until
  * the queue has been completely flushed.
  */
-protected Set refSet;
+protected final Set refSet;

 protected RenderQueue() {
-refSet = new HashSet<>();
+refSet = new HashSet(64); // large enough (LBO) ?
 buf = RenderBuffer.allocate(BUFFER_SIZE);
+}
+
+protected final void clear() {
+// reset the buffer position
+buf.clear();
+// clear the set of references, since we no longer need them
+refSet.clear();
 }

 /**
@@ -220,4 +237,35 @@
 buf.position(position);

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

[Laurent Bourgès]

Hi,
I have created the corresponding JBS rfe/bug:
https://bugs.openjdk.java.net/browse/JDK-8198885

Jtreg: ok
Tested on linux 64 with both xrender & opengl pipelines.

I will make tests on macOS & windows soon to ensure larger tiles are well
supported.

News:
- I modified opengl queue buffer capacity recently and got 30% better
performance (mapbench) on linux. That could be worth for macOS: will create
another jbs bug
- I will work on upgrading MarlinFX to 0.9.1 soon to provide you a patch
for openjfx 11.

Who can review such patches & help me on improving java2d pipelines
(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/marlin/marlin-091.0/
>
> Changes:
> - *ArrayCache: removed clean flag and usage of
> jdk.internal.UNSAFE.allocateUninitializedArray()
> - (D)Curve: added support for lines (curve type 4) + new methods x/y
> Points to compute intersections on clip edges
> - (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
> clipping in Dasher that uses skipLen() to compute properly the dash phase &
> state
> - (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
> fastXXXLen() to quickly estimate curve length from control points
>   moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
> determine t values corresponding to curve intersections with the clip edges
> + added subdivideLineAt() to subdivide line segments
> - (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
> enabled (2nd clipping is counter-productive) + initialize new path
> simplifier if enabled (disabled by default) + log new settings
> - (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
> accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
> - (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
> refactoring)
> - (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter
> to clip filled shapes overlapping clipping edges
> added CurveClipSplitter that subdivides curves (line, quad,
> cubic) at clip intersections (+ small padding to avoid precision issues)
> added CurveBasicMonotonizer to monotonize curves (before in
> Stroker) to make it on initial curve in Dasher (more efficient than for all
> dashes)
> - (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
> too small segments (radial distance threshold)
> - ClipShapeTest: improved test to use a small tolerance as clipped curves
> (at clip edges) has minor impact on computed offsets for stroked shapes and
> on dash positions: overall quality is improved as previously larger curves
> had more accumulated error on either dashes or stroke offsets
>
> Build & jtreg tests: OK
>
> Cheers,
> Laurent
>

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

[Laurent Bourgès]

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 a lot for
> larger aa shapes. For smaller xrender stays rather slow.
>

Thanks.
On my linux laptop (i7 + nvidia quadro), xrender is already faster than the
opengl backend (jdk11) on my MapBench tests.


> To solve this issue am currently working on batching the AA tile mask
> uploads in the xrender pipeline to improve the performance with
> antialiasing enabled.
> Batching can happen regardless of state-changes, so different shapes
> with different properties can all be uploaded in one batch.
> Furthermore that batching (resulting in larger uploads) allows for
> mask upload using XShm (shared memory), reducing the number of data
> copies and context switches.
>

First impressions:
I looked at your code and mostly understand it except how tiles are packed
in larger texture (illustration is missing, please) & fence handling.

Yesterday I looked at the OpenGL backend code and your new XRDeferedBackend
looks very closed to OGLRenderQueue (extends RenderQueue) so you may share
some code about the buffer queue ?
Moreover, OpenGL backend has a queue flusher although XRDeferedBackend has
not !

Does it mean that few buffered commands may be pending ... until the buffer
queue or texture is flushed ?

>
> It is still in prototype state with a few rough edges and a few
> corner-cases unimplemented (e.g. extra alpha with antialiasing),
> but should be able to run most workloads:
> http://93.83.133.214/webrev/
> https://sourceforge.net/p/xrender-deferred/code/ref/default/
>

I will give you later more details about your code (pseudo-review), but I
noticed that XRBackendNative uses putMaskNative (c) that seems more
efficient than the XRDeferedBackend (mask copy in java + XPutImage in c)...


>
> It is disabled by default, and can be enabled with
> -Dsun.java2d.xr.deferred=true
> Shm upload is enabled with deferred and can be disabled with:
> -Dsun.java2d.xr.shm=false
>

I merged your patch on latest jdk11 + pending marlin 0.9.1 patch and it
works well (except extra-alpha is missing).



> What would be the best way forward?
> Would this have a chance to get into OpenJDK11 for platforms with
> XCB-based Xlib implementations?
> Keeping in mind the dramatic performance increase,
> even outperforming the current OpenGL pipeline, I really hope so.
>

I made performance testing with nvidia hw (binary driver 390.12)
Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Nvidia Quadro M1000M

1/ J2DBench results (AA on all shapes with size = 20 & 250):
options: bourgesl.github.io <https://github.com/bourgesl/bourgesl.github.io>
/j2dbench
<https://github.com/bourgesl/bourgesl.github.io/tree/master/j2dbench>/
options
<https://github.com/bourgesl/bourgesl.github.io/tree/master/j2dbench/options>
/default_2018.opt

Defered off vs on: ~ 1 to 15% slower
http://bourgesl.github.io/j2dbench/xr_results/Summary_Report.html

Defered enabled: SHM off vs on: ~ 3 to 10% faster
http://bourgesl.github.io/j2dbench/xr_results_shm/Summary_Report.html

See raw data:
https://github.com/bourgesl/bourgesl.github.io/tree/master/j2dbench/

Finally, J2DBench results do not show any gain on tested cases.
SHM is slightly better on nvidia (driver supposed to disable it ?) or
XRBackend / XCB is more efficient with SHM handling.

Perspectives:
- test smaller shapes (size=1 with width=5) to increase the tile packing
factor ?
- how to pack more efficiently the tiles into larger textures (padding) in
x or XY directions ? use multiple textures (pyramid) ?
- optimize tile copies anyway or the queue flushing ?


2/ MapBench tests with -Dsun.java2d.xr.deferred=false/true:

I found 2 cases with large gains (20% to 40% faster) whereas other maps
have 10% losses:
- dc_shp_alllayers_2013-00-30-07-00-47.ser {width=1400, height=800,
commands=135213}
Test ThreadsOpsMed
Pct95AvgStdDevMinMaxFPS(med)[ms/op]
*off*: dc_shp_alllayers_2013-00-30-07-00-47.ser 114
727.411*728.847 *   727.3941.127725.197729.8331.375
*on*:  dc_shp_alllayers_2013-00-30-07-00-47.ser 123
443.919*486.207*456.22819.807   438.598486.9022.253

- test_z_625k.ser {width=1272, height=1261, commands=23345}
Test ThreadsOpsMed
Pct95AvgStdDevMinMaxFPS(med)[ms/op]
*off*: test_z_625k.ser  196
108.856*109.923*108.9150.588107.886111.7629.186
*on*:  test_z_625k.ser  1113
90.908*92.837* 91.021 1.06789.029 9

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

[Laurent Bourgès]

Hi Clemens,
As I am enjoying winter holidays, I will try your patch once at home.

It seems very promising and will try understanding changes to C code.
I will also test on my linux machines with nvidia cards (quadro 610 & 1070).

Cheers,
Laurent

Le 22 févr. 2018 8:42 AM, "Clemens 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 shapes. For smaller xrender stays rather slow.
>
> To solve this issue am currently working on batching the AA tile mask
> uploads in the xrender pipeline to improve the performance with
> antialiasing enabled.
> Batching can happen regardless of state-changes, so different shapes
> with different properties can all be uploaded in one batch.
> Furthermore that batching (resulting in larger uploads) allows for
> mask upload using XShm (shared memory), reducing the number of data
> copies and context switches.
>
> Initial results seem very promising - beating the current OpenGL
> implementation by a wide margin:
>
> J2DBench, 20x20 ellipse antialiased:
>
> XRender + deferred mask upload + XSHM:
> > Test(graphics.render.tests.fillOval) averaged
> > 3.436728470039390E7 pixels/sec
> > with width1, !clip, Default, !alphacolor, ident,
> > !extraalpha, single, !xormode, antialias, SrcOver, 20x20, bounce, to
> > VolatileImg(Opaque)
>
> XRender + deferred mask upload:
> > Test(graphics.render.tests.fillOval) averaged
> > 3.0930638830897704E7 pixels/sec
> > with width1, !clip, Default, !alphacolor, ident,
> > !extraalpha, single, !xormode, antialias, SrcOver, 20x20, bounce, to
> > VolatileImg(Opaque)
>
> OpenGL pipeline:
> >  Test(graphics.render.tests.fillOval) averaged
> > 1.3258861545909312E7 pixels/sec
> > with Default, !xormode, !extraalpha, single, bounce,
> > 20x20, to VolatileImg(Opaque), ident, !clip, !alphacolor, antialias,
> > SrcOver, width1
>
> XRender as-is:
> >   Test(graphics.render.tests.fillOval) averaged
> >  6031195.796094009 pixels/sec
> >  with !alphacolor, bounce, !extraalpha, !xormode,
> > antialias, Default, single, ident, SrcOver, 20x20, to
> > VolatileImg(Opaque), !clip, width1
>
>
> And a real-world test: MigLayout Swing Benchmark with NimbusLnf, ms
> for one iteration:
>
> XRender-Deferred + SHM:
> AMD: 850 ms
> Intel: 1300 ms
>
> OpenGL:
> AMD: 1260 ms
> Intel:  2580 ms
>
> XRender (as is):
> AMD: 2620 ms
> Intel:  4690 ms
>
> (AMD: AMD Kaveri 7650k / Intel: Intel Core i5 640M )
>
>
> It is still in prototype state with a few rough edges and a few
> corner-cases unimplemented (e.g. extra alpha with antialiasing),
> but should be able to run most workloads:
> http://93.83.133.214/webrev/
> https://sourceforge.net/p/xrender-deferred/code/ref/default/
>
> It is disabled by default, and can be enabled with
> -Dsun.java2d.xr.deferred=true
> Shm upload is enabled with deferred and can be disabled with:
> -Dsun.java2d.xr.shm=false
>
> What would be the best way forward?
> Would this have a chance to get into OpenJDK11 for platforms eith
> XCB-based Xlib implementations?
> Keeping in mind the dramatic performance increase,
> even outperforming the current OpenGL pipeline, I really hope so.
>
> Another change I would hope to see is a modification of the
> maskblit/maskfill interfaces.
> For now marlin has to rasterize into a byte[] tile, this array is
> afterwards passed to the pipeline,
> and the pipeline itself has to copy it again into some internal buffer.
> With the enhancements described above, I see this copy process already
> consuming ~5-10% of cpu cycles.
> Instead the pipeline could provide a ByteBuffer to rasterize into to
> Marlin, along with information regarding stride/width/etc.
>
> Best regards, Clemens
>
> Some background regarding the issue / implementation:
>
> Since the creation of the xrender java2d backend, I was always
> bothered how poor it performed with antialiasing enabled.
> What the xrender backend does in this situation seems not to be that
> common - the modern drivers basically stall the GPU for every single
> AA tile (currently 32x32).
>
> Pisces was so slow, xservers could consume the tiles more or less at
> the speed pisces provided it.
> However with the excellent work on Pisces's successor Marlin (big
> thanks to Laurent Bourgès), the bottleneck the xrender pipeline
> presented was more and more evident.
>
> One early 

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

[Laurent Bourgès]

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 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 lines (curve type 4) + new methods x/y
> Points to compute intersections on clip edges
> - (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
> clipping in Dasher that uses skipLen() to compute properly the dash phase &
> state
> - (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
> fastXXXLen() to quickly estimate curve length from control points
>   moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
> determine t values corresponding to curve intersections with the clip edges
> + added subdivideLineAt() to subdivide line segments
> - (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
> enabled (2nd clipping is counter-productive) + initialize new path
> simplifier if enabled (disabled by default) + log new settings
> - (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
> accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
> - (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
> refactoring)
> - (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter
> to clip filled shapes overlapping clipping edges
> added CurveClipSplitter that subdivides curves (line, quad,
> cubic) at clip intersections (+ small padding to avoid precision issues)
> added CurveBasicMonotonizer to monotonize curves (before in
> Stroker) to make it on initial curve in Dasher (more efficient than for all
> dashes)
> - (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
> too small segments (radial distance threshold)
> - ClipShapeTest: improved test to use a small tolerance as clipped curves
> (at clip edges) has minor impact on computed offsets for stroked shapes and
> on dash positions: overall quality is improved as previously larger curves
> had more accumulated error on either dashes or stroke offsets
>
> Build & jtreg tests: OK
>
> Cheers,
> Laurent
>

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

[Laurent Bourgès]

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 lines (curve type 4) + new methods x/y Points
to compute intersections on clip edges
- (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
clipping in Dasher that uses skipLen() to compute properly the dash phase &
state
- (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
fastXXXLen() to quickly estimate curve length from control points
  moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
determine t values corresponding to curve intersections with the clip edges
+ added subdivideLineAt() to subdivide line segments
- (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
enabled (2nd clipping is counter-productive) + initialize new path
simplifier if enabled (disabled by default) + log new settings
- (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
- (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
refactoring)
- (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter to
clip filled shapes overlapping clipping edges
added CurveClipSplitter that subdivides curves (line, quad,
cubic) at clip intersections (+ small padding to avoid precision issues)
added CurveBasicMonotonizer to monotonize curves (before in
Stroker) to make it on initial curve in Dasher (more efficient than for all
dashes)
- (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
too small segments (radial distance threshold)
- ClipShapeTest: improved test to use a small tolerance as clipped curves
(at clip edges) has minor impact on computed offsets for stroked shapes and
on dash positions: overall quality is improved as previously larger curves
had more accumulated error on either dashes or stroke offsets

Build & jtreg tests: OK

Cheers,
Laurent

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

[Laurent Bourgès]

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 adjust maximum double buffer
> size  after changes in the display environment. The fix is targeted for
> openjdk10 but the problem exists in previous releases. Please, have a look.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>
> Best Regards,
> Alexey
>

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

[Laurent Bourgès]

Hi,

I pushed in jdk forrest:
http://hg.openjdk.java.net/jdk/client/rev/fd7fbc929001

Thanks for your reviews, Phil & Sergey !

Laurent


2017-12-07 20:43 GMT+01:00 Sergey Bylokhov <sergey.bylok...@oracle.com>:

> I am not an expert here, I just look to the changes and run the closed
> 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-8191814.1/
>>
>> Changes:
>> - @run twice to test both Marlin variants (float / double)
>> - use Logger to get & check marlin system properties
>> ("sun.java2d.renderer.clip.runtime.enable") to ensure the test is run
>> against a Marlin renderer having the clipping features
>>
>> I tested the fixed test on JDK9 and it fails:
>> runner finished test: sun/java2d/marlin/ClipShapeTest.java
>> Failed. Execution failed: `main' threw exception:
>> java.lang.RuntimeException: Marlin clipping not enabled 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
>> <mailto:bourges.laur...@gmail.com>>:
>>
>> Hi Sergey,
>>
>> Thanks for your comment.
>>
>> This new test only validates the new clipping algorithms ie it
>> compares the rendering outputs with / without clipping enabled.
>>
>> As such algorithms are only available in Marlin 0.8.2 and the test
>> uses new system properties to enable/disable clipping, I confirm it
>> passes before (jdk9 or jdk10 before patch).
>>
>> To ensure it detects any regression, I manually inserted some bugs
>> in the clipping code, and the test failed.
>>
>> Note: I should add another test @run to check the float variant too
>> (and not only the double variant, the default in jdk10).
>>
>> Finally I could write a new performance test that would prove
>> clipping is more efficient than before.
>> Such test would fail before patch (timeout ?), but it is difficult
>> to make it robust as it depends on the hw.
>> Jim wrote a basic test in the jfx bug showing 300ms without but 2ms
>> now => gain is high.
>> A possible 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 <mailto: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 possible
>> combinations of (cap / join) for random polyline (Stroker)
>> and polygons (Filler) comparing image outputs rendered with
>> clipping enabled vs disabled
>>
>>
>> I have only one note that the test is passed before the fix, so
>> if we will regress at some point later we will not catch this.
>
>

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

[Laurent Bourgès]

Phil,

Thanks for your review.

I suppose you approved the Java2D patch for the RFR thread: [10] RFR
JDK-8191814:
http://mail.openjdk.java.net/pipermail/2d-dev/2017-November/008741.html

I will push tomorrow to jdk forrest as phil & sergey? approved 2D changes.


This RFR thread remains open for the JavaFX patch that Kevin started to
test & review.

Cheers,
Laurent

2017-12-10 18:36 GMT+01:00 Philip Race <philip.r...@oracle.com>:

> I'm giving this an OK.
> I've looked at the code, if not the maths, and run our regression test
> suite.
> I had a bit of trouble 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 an updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.1/
>
> It fixes the ClipShapeTest to run ~35s (< 2mins) on my latop: 22 test
> setups only (5000 random polygons each) that covers all aspects of the new
> clipping algorithm.
>
> I wonder if I should remove the 'slow' mode that has till @ignore:
> both tests are ignored if I run jtreg -ignore:quiet although I would like
> to only ignore the @ignore run (1/2).
>
>
> Once again, I have to create a new JBS bug for Marlin2D tomorrow then
> start a new RFR with a complete change log.
>
> Laurent
>
> 2017-11-16 10:50 GMT+01: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 the images for the same
>>> mode.
>>>
>>
>> Yes that is always possible but I do not want to spend too much time
>> improving the test to parallelize it.
>>
>> I fixed it last night and it runs only 22 test setups (1 stroke width =
>> 8px, no dashes) and takes ~ 30 seconds on my laptop (single-thread).
>> I verified that any bug in Marlin clipping is detected by this new
>> variant of the tests.
>> Will provide a new patch asap.
>>
>>
>>>
>>> Finally I will minimize the number of stroker tests: use only 1 stroke
>>>> width (=5px) and that should be enough to stay below timeout (2mins).
>>>>
>>>
>>> Note that the test can be run on some slow/virtual systems, it would be
>>> good to have some additional time.
>>>
>>> Is there any documentation about jtreg tags ?
>>>>
>>>
>>> You can find it here:
>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>
>>
>> Thanks.
>>
>> Laurent
>>
>
>
>
> --
> --
> Laurent Bourgès
>
>


-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

Hi again,

Here is a new webrev fixing the ClipShapeTest:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8191814.1/

Changes:
- @run twice to test both Marlin variants (float / double)
- use Logger to get & check marlin system properties
("sun.java2d.renderer.clip.runtime.enable") to ensure the test is run
against a Marlin renderer having the clipping features

I tested the fixed test on JDK9 and it fails:
runner finished test: sun/java2d/marlin/ClipShapeTest.java
Failed. Execution failed: `main' threw exception:
java.lang.RuntimeException: Marlin clipping not enabled 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,
>
> Thanks for your comment.
>
> This new test only validates the new clipping algorithms ie it compares
> the rendering outputs with / without clipping enabled.
>
> As such algorithms are only available in Marlin 0.8.2 and the test uses
> new system properties to enable/disable clipping, I confirm it passes
> before (jdk9 or jdk10 before patch).
>
> To ensure it detects any regression, I manually inserted some bugs in the
> clipping code, and the test failed.
>
> Note: I should add another test @run to check the float variant too (and
> not only the double variant, the default in jdk10).
>
> Finally I could write a new performance test that would prove clipping is
> more efficient than before.
> Such test would fail before patch (timeout ?), but it is difficult to make
> it robust as it depends on the hw.
> Jim wrote a basic test in the jfx bug showing 300ms without but 2ms now =>
> gain is high.
> A possible 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 possible combinations
>> of (cap / join) for random polyline (Stroker) and polygons (Filler)
>> comparing image outputs rendered with clipping enabled vs disabled
>>
>
> I have only one note that the test is passed before the fix, so if we will
> regress at some point later we will not catch this.
>
>
> --
> Best regards, Sergey.
>
>
>


-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

Hi Sergey,

Thanks for your comment.

This new test only validates the new clipping algorithms ie it compares the
rendering outputs with / without clipping enabled.

As such algorithms are only available in Marlin 0.8.2 and the test uses new
system properties to enable/disable clipping, I confirm it passes before
(jdk9 or jdk10 before patch).

To ensure it detects any regression, I manually inserted some bugs in the
clipping code, and the test failed.

Note: I should add another test @run to check the float variant too (and
not only the double variant, the default in jdk10).

Finally I could write a new performance test that would prove clipping is
more efficient than before.
Such test would fail before patch (timeout ?), but it is difficult to make
it robust as it depends on the hw.
Jim wrote a basic test in the jfx bug showing 300ms without but 2ms now =>
gain is high.
A possible 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 possible combinations of
> (cap / join) for random polyline (Stroker) and polygons (Filler) comparing
> image outputs rendered with clipping enabled vs disabled
>

I have only one note that the test is passed before the fix, so if we will
regress at some point later we will not catch this.


-- 
Best regards, Sergey.

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

[Laurent Bourgès]

clipping = trivial
segment rejection based on point outcodes and calls clip() to insert corner
points if needed + update the accumulated outcode (for finishPath)
- clip(): tricky (but tested) solution to insert 1 or 2 corner
points in the index stack when the segment outcodes are different but only
on left or right sides
- added the PathTracer class that log PathConsumer2D methods (std out)

- MarlinCache: fixed syntax of the useRLE flag (shorter conditions)
- MarlinConst: moved all WIND / CAP / JOIN constants here + added outcode
constants (sides & masks)
- MarlinProperties: added system properties for clipping
- RendererStats: updated statistics for new features
- Version: 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

[Laurent Bourgès]

Phil,

Here is an updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.1/

It fixes the ClipShapeTest to run ~35s (< 2mins) on my latop: 22 test
setups only (5000 random polygons each) that covers all aspects of the new
clipping algorithm.

I wonder if I should remove the 'slow' mode that has till @ignore:
both tests are ignored if I run jtreg -ignore:quiet although I would like
to only ignore the @ignore run (1/2).


Once again, I have to create a new JBS bug for Marlin2D tomorrow then start
a new RFR with a complete change log.

Laurent

2017-11-16 10:50 GMT+01: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 the images for the same
>> mode.
>>
>
> Yes that is always possible but I do not want to spend too much time
> improving the test to parallelize it.
>
> I fixed it last night and it runs only 22 test setups (1 stroke width =
> 8px, no dashes) and takes ~ 30 seconds on my laptop (single-thread).
> I verified that any bug in Marlin clipping is detected by this new variant
> of the tests.
> Will provide a new patch asap.
>
>
>>
>> Finally I will minimize the number of stroker tests: use only 1 stroke
>>> width (=5px) and that should be enough to stay below timeout (2mins).
>>>
>>
>> Note that the test can be run on some slow/virtual systems, it would be
>> good to have some additional time.
>>
>> Is there any documentation about jtreg tags ?
>>>
>>
>> You can find it here:
>> http://openjdk.java.net/jtreg/tag-spec.html
>>
>
> Thanks.
>
> Laurent
>



-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

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 slow ~ 20mins, so I added @ignore
> but it marks the test as failed.
>

Why not split it across the threads? 5~7 minutes is not a big deal for the
test which has a good coverage.


Good idea but it can not work:
- I use specific a system property to enable/disable Marlin clipping
support at runtime
- it is by nature not thread safe !

Maybe I could use new RenderingHints but for now these are not given by
SunGraphics2d to Marlin.
Moreover I would like having the rendering hint Quality/Speed in order to
let Marlin be faster but less accurate.

Finally I will minimize the number of stroker tests: use only 1 stroke
width (=5px) and that should be enough to stay below timeout (2mins).

Is there any documentation about jtreg tags ?

Cheers,
Laurent

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

[Laurent Bourgès]

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 current bug concerns javafx) tomorrow and
give the complete change log + some explanations (late).

PS: I added the new ClipShapeTests with special jtreg tags: what is the
default timeout ? The complete tests are slow ~ 20mins, so I added @ignore
but it marks the test as failed.

Cheers,
Laurent

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

[Laurent Bourgès]

Phil & Kevin,
The proposed plan looks good.

I will first work on refactoring my ShapeClipTest and then focus on having
a Java2d patch ready.

I absolutely want that this new performance improvement will ship in Java
10.

PS: Another important performance change concerns tuning Java2D tile sizes.
This can be easily done: set tile log2 settings to 7 x 6 to let Marlin use
128x64 tiles: up to 60% gain for large shapes rendered on VolatileImage
(linux 64 + i7 + nvidia)

I will create new bugs to track these RFE...

Bye,
Laurent

Le 8 nov. 2017 23:44, "Phil Race" <philip.r...@oracle.com> a écrit :

I think they should be separate webrevs sent to the separate lists and you
should start with 2D
as I can then run the JDK regression tests on it. I know you can
theoretically run the open regression
tests too (are you ?) but there are some random scattered closed regression
tests that so far
as I can see can be open sourced .. that I can run but you can't .. I'll at
least run the
automated ones. I wouldn't call them anything very focused on testing
rasterization but
I can at least check off that concern ..

And yes, I'll make time to review it.

-phil.


On 11/08/2017 01:55 PM, Laurent Bourgès wrote:

Kevin & Phil,

Some news on that issue:
I successfully managed to finish the Path clipping support in Marlin 0.8.2
(release last week):
https://github.com/bourgesl/marlin-renderer/releases/tag/v0.8.2

I fixed few remaining bugs in either Stroker (1) and in PathClipFilter (2)
to have proper & tested clipping in Marlin renderer (2D). It now works
perfectly with either NZ or EO winding rules.

To ensure detecting any artefact between Clipping Off vs On, I implemented
a 'basher' test (as recommended by Jim) that renderers 10 000 random
polygons (5 -> 9 -> 50 line segments or mixed with line / quads / cubics) (
whose point coordinates are in [-50 to 150] ) to a 100x100 buffered image
with or without clipping enabled (using a system property at runtime). Of
course, all output pixels are compared and any pixel difference is
considered as a failure.

The new ShapeClipTests tests all stroke combinations (cap / join / with or
without dashes / closed or not / EO or NZ rule) and also fills (closed or
not / EO or NZ rule) => 170 tests run OK

I need some time to synchronize MarlinFX and then with either OpenJDK
forrest (new) or OpenJFX10.
If you want the new automated test (long run ~ 20 minutes), I need some
time to refactor it as it uses some code from my MapBench tool and have a
standalone test class.

Will you have time to review such (medium) changes in Marlin2D (Phil ?) and
/ or MarlinFX (Kevin ?) before the deadline (dec 14th) ?
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 Laurent Bourgès <bourges.laur...@gmail.com>:

> Hi Kevin,
>
> Ok I propose to withdraw or postpone this review after JavaOne where we
> will be able to discuss in a face to face meeting about Marlin & MarlinFX
> changes for JDK10.
>
> I hope the 2d / jfx groups have other Graphics Guru to help, as good as
> Jim Graham.
>
> Cheers,
> Laurent
>
> Le 6 sept. 2017 16:23, "Kevin Rushforth" <kevin.rushfo...@oracle.com> a
> écrit :
>
>> Hi Laurent,
>>
>> Some combination of Phil, Sergey, and I will take a look at this when we
>> can. Perhaps there might be others on these two lists who could lend a
>> helping hand?
>>
>> -- Kevin
>
>

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

[Laurent Bourgès]

Kevin & Phil,

Some news on that issue:
I successfully managed to finish the Path clipping support in Marlin 0.8.2
(release last week):
https://github.com/bourgesl/marlin-renderer/releases/tag/v0.8.2

I fixed few remaining bugs in either Stroker (1) and in PathClipFilter (2)
to have proper & tested clipping in Marlin renderer (2D). It now works
perfectly with either NZ or EO winding rules.

To ensure detecting any artefact between Clipping Off vs On, I implemented
a 'basher' test (as recommended by Jim) that renderers 10 000 random
polygons (5 -> 9 -> 50 line segments or mixed with line / quads / cubics) (
whose point coordinates are in [-50 to 150] ) to a 100x100 buffered image
with or without clipping enabled (using a system property at runtime). Of
course, all output pixels are compared and any pixel difference is
considered as a failure.

The new ShapeClipTests tests all stroke combinations (cap / join / with or
without dashes / closed or not / EO or NZ rule) and also fills (closed or
not / EO or NZ rule) => 170 tests run OK

I need some time to synchronize MarlinFX and then with either OpenJDK
forrest (new) or OpenJFX10.
If you want the new automated test (long run ~ 20 minutes), I need some
time to refactor it as it uses some code from my MapBench tool and have a
standalone test class.

Will you have time to review such (medium) changes in Marlin2D (Phil ?) and
/ or MarlinFX (Kevin ?) before the deadline (dec 14th) ?
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 Laurent Bourgès <bourges.laur...@gmail.com>:

> Hi Kevin,
>
> Ok I propose to withdraw or postpone this review after JavaOne where we
> will be able to discuss in a face to face meeting about Marlin & MarlinFX
> changes for JDK10.
>
> I hope the 2d / jfx groups have other Graphics Guru to help, as good as
> Jim Graham.
>
> Cheers,
> Laurent
>
> Le 6 sept. 2017 16:23, "Kevin Rushforth" <kevin.rushfo...@oracle.com> a
> écrit :
>
>> Hi Laurent,
>>
>> Some combination of Phil, Sergey, and I will take a look at this when we
>> can. Perhaps there might be others on these two lists who could lend a
>> helping hand?
>>
>> -- Kevin
>
>

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

[Laurent Bourgès]

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
conclusion of my slides):

- I was overbusy with Marlin & MarlinFX projects in the last 3 years: It
consumed a lot of my spare time.
I succeeded with JEP265, maybe the only FOSS & independent contribution in
Java 9, in integrating these renderers into OpenJDK & OpenJFX.
I consider my JavaOne talk as an achievement and I will not spend much time
on these lovely projects, only on small changes or bug fixes (see github
issue boards).
Maybe someone else could implement more important enhancements... as a new
project leader that I can sponsor and help.
Please join OpenJDK or OpenJFX projects too in order to provide your own
improvements. I do not want to be a community leader or waste my time on
long discussion threads: I prefer coding concrete changes provided freely
to the community, free & alone in the dark.

- I am absolutely a performance engineer, so please report any performance
issue in bugs.openjdk.java.net and I may have a look.

Better performance means higher power efficiency that represents large
gains in the global power consumption for any data center. At the earth
scale, this is my contribution to reduce our human footprint and hopefully
lower the impact of the climate change.

Finally Adopt any FOSS project you like and contribute: code, or any bug
reports, documentation, tests, benchmarks ... if you have time.
You can also give money to any contributor you appreciate or enjoy benefits
of his work (sponsoring).

Thanks again to all my sponsors that made my JavaOne talk happen.

PS: As mentioned, I have not enough free time to implement new JavaFX
features, only fix some perf bugs if I can.
Please do it yourself or try improving any great JavaFX libs...

Goodbye & Good luck,
Laurent Bourges

[OpenJDK 2D-Dev] Client group consolidation ?

[Laurent Bourgès]

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 obtain a larger work team.

Of course, it depends on the ByLaws consensus.

Laurent