Re: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v2]

[Laurent Bourgès]

On Tue, 31 May 2022 22:25:23 GMT, Kevin Rushforth  wrote:

>> Hi,
>> Time is going short before openjfx 19...
>> 
>> 2 options:
>> - keep dpqs for corner cases and keep my coding life simple
>> - disable or remove dpqs code in marlinFX for openjfx, so my branches will 
>> diverge...
>> 
>> Any advice, @kevinrushforth ?
>
>> keep dpqs for corner cases and keep my coding life simple
> 
> I think this approach is fine. Diverging the code would likely make it less 
> stable, and you answered the question about the provenance of the code, so 
> there's no issue there. We should try to get this in before RDP1 of JavaFX 19 
> if possible.
> 
> One more thing, as I wrote in my above comment:
> 
>> We should file a new JBS Enhancement issue -- similar to what was done for 
>> Marlin 0.9.2 via 
>> [JDK-8204621](https://bugs.openjdk.java.net/browse/JDK-8204621) rather than 
>> using a narrow bug, since that bug is only part of what's being done. The 
>> current bug can either be added to the PR, or else that JBS bug 
>> (JDK-8274066) can be closed as a duplicate of the new Enhancement.
> 
> I took the liberty of filing 
> [JDK-8287604](https://bugs.openjdk.java.net/browse/JDK-8287604) for this 
> enhancement. Can you change the title to:
> 
> 8287604: Update MarlinFX to 0.9.4.5

Thx @kevinrushforth 
I will look at fixing the test with hidpi very soon

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]

[Laurent Bourgès]

On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourgès  wrote:

>> Changelog for this MarlinFX 0.9.4.5 release:
>> 
>> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path 
>> clipper:
>> - improved Stroker to handle huge coordinates, up to 1E15
>> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15
>> 
>> 
>> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement 
>> fixes in the MarlinRenderingEngine:
>> - Update DPQS to latest OpenJDK 14 patch
>> - Improve cubic curve offset computation
>> 
>> 
>> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix 
>> in the MarlinRenderingEngine: 
>> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728.
>> 
>> 
>> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, 
>> reported first against JavaFX 11: 
>> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789.
>> 
>> 
>> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot 
>> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized 
>> MergeSort (x-position + edge indices) for arrays larger than 256.
>> 
>> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 
>> 19.05 with many variants, improving almost-sorted datasets. We are 
>> collaborating to provide a complete Sort framework (15 algorithms, many 
>> various datasets, JMH benchmarks) publicly on github:
>> see https://github.com/bourgesl/nearly-optimal-mergesort-code
>
> Laurent Bourgès has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   added test for huge polygon coords

Hi,
Time is going short before openjfx 19...

2 options:
- keep dpqs for corner cases and keep my coding life simple
- disable or remove dpqs code in marlinFX for openjfx, so my branches will 
diverge...

Any advice, @kevinrushforth ?

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]

[Laurent Bourgès]

On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourgès  wrote:

>> Changelog for this MarlinFX 0.9.4.5 release:
>> 
>> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path 
>> clipper:
>> - improved Stroker to handle huge coordinates, up to 1E15
>> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15
>> 
>> 
>> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement 
>> fixes in the MarlinRenderingEngine:
>> - Update DPQS to latest OpenJDK 14 patch
>> - Improve cubic curve offset computation
>> 
>> 
>> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix 
>> in the MarlinRenderingEngine: 
>> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728.
>> 
>> 
>> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, 
>> reported first against JavaFX 11: 
>> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789.
>> 
>> 
>> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot 
>> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized 
>> MergeSort (x-position + edge indices) for arrays larger than 256.
>> 
>> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 
>> 19.05 with many variants, improving almost-sorted datasets. We are 
>> collaborating to provide a complete Sort framework (15 algorithms, many 
>> various datasets, JMH benchmarks) publicly on github:
>> see https://github.com/bourgesl/nearly-optimal-mergesort-code
>
> Laurent Bourgès has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   added test for huge polygon coords

Hi Kevin,
I am running again MapBench tests to determine good conditions proving this 
DPQS patch has much benefits in real cases. 
I added a new TextPage (50 lines of long text) scene.

I remember (2019) that dpqs rocks really when the edge density is high (200 to 
1000 items to sort per scanline) but it can happen quite easily:
- AA disabled => 8 times more crossings to sort at each scanline (the test case 
of the plot 
https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/marlin-0.9.4/diff-marlin-094-gain.png)
- zoomed out scene so the all complex paths are really small that maximizes the 
density, like 1/8 ot 1/20 ... of course, the scene must contain long paths 
(many edges) like a complex polyline, polygon or text (as shape)

@iaroslavski could you answer the IP / legal question ?

More results soon,
Laurent

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]

[Laurent Bourgès]

On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourgès  wrote:

>> Changelog for this MarlinFX 0.9.4.5 release:
>> 
>> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path 
>> clipper:
>> - improved Stroker to handle huge coordinates, up to 1E15
>> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15
>> 
>> 
>> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement 
>> fixes in the MarlinRenderingEngine:
>> - Update DPQS to latest OpenJDK 14 patch
>> - Improve cubic curve offset computation
>> 
>> 
>> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix 
>> in the MarlinRenderingEngine: 
>> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728.
>> 
>> 
>> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, 
>> reported first against JavaFX 11: 
>> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789.
>> 
>> 
>> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot 
>> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized 
>> MergeSort (x-position + edge indices) for arrays larger than 256.
>> 
>> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 
>> 19.05 with many variants, improving almost-sorted datasets. We are 
>> collaborating to provide a complete Sort framework (15 algorithms, many 
>> various datasets, JMH benchmarks) publicly on github:
>> see https://github.com/bourgesl/nearly-optimal-mergesort-code
>
> Laurent Bourgès has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   added test for huge polygon coords

I advocate I did not give more information on the current patch. Do you need a 
detailled change log ?

Concerning DualPivotQuicksort20191112Ext, it was developped in collaboration 
with Vladimir to have a new sort algorithm based on two int arrays: a[] vector 
contains crossing x positions, b[] vector contains the edge indices. Both 
arrays are returned sorted by a (positions) to satisfy my MergeSort.

It was developped in the following repository (intensively tested like the 
current DPQS in jdk17 or the new proposed patch for JDK19?): 
https://github.com/bourgesl/nearly-optimal-mergesort-code

Here are java2d results with complex random polygons (1k to 100k random 
segments):
https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/marlin-0.9.4/diff-marlin-094-gain.png
from https://github.com/bourgesl/marlin-renderer/releases/tag/v0_9_4_b2
It mostly fixes performance in case of insanely complex polygons; but it could 
happen with large text blocks + complex fonts or overly detailed maps.

Thanks

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used

[Laurent Bourgès]

On Fri, 7 Jan 2022 23:35:37 GMT, Kevin Rushforth  wrote:

>> Changelog for this MarlinFX 0.9.4.5 release:
>> 
>> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path 
>> clipper:
>> - improved Stroker to handle huge coordinates, up to 1E15
>> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15
>> 
>> 
>> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement 
>> fixes in the MarlinRenderingEngine:
>> - Update DPQS to latest OpenJDK 14 patch
>> - Improve cubic curve offset computation
>> 
>> 
>> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix 
>> in the MarlinRenderingEngine: 
>> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728.
>> 
>> 
>> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, 
>> reported first against JavaFX 11: 
>> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789.
>> 
>> 
>> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot 
>> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized 
>> MergeSort (x-position + edge indices) for arrays larger than 256.
>> 
>> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 
>> 19.05 with many variants, improving almost-sorted datasets. We are 
>> collaborating to provide a complete Sort framework (15 algorithms, many 
>> various datasets, JMH benchmarks) publicly on github:
>> see https://github.com/bourgesl/nearly-optimal-mergesort-code
>
> Would a targeted test for the failing case from the bug report make sense?

@kevinrushforth I added a new test: it fails on jfx11 & 17, passes with the 
patch.
Ready for review ?

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used

[Laurent Bourgès]

On Fri, 7 Jan 2022 23:39:05 GMT, Laurent Bourgès  wrote:

> Would a targeted test for the failing case from the bug report make sense?

I added the HugePolygonClipTest that fails on jdk11, 17 ... but now passes.

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]

[Laurent Bourgès]

> Changelog for this MarlinFX 0.9.4.5 release:
> 
> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path 
> clipper:
> - improved Stroker to handle huge coordinates, up to 1E15
> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15
> 
> 
> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement 
> fixes in the MarlinRenderingEngine:
> - Update DPQS to latest OpenJDK 14 patch
> - Improve cubic curve offset computation
> 
> 
> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix 
> in the MarlinRenderingEngine: 
> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728.
> 
> 
> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, 
> reported first against JavaFX 11: 
> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789.
> 
> 
> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot 
> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized 
> MergeSort (x-position + edge indices) for arrays larger than 256.
> 
> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 
> 19.05 with many variants, improving almost-sorted datasets. We are 
> collaborating to provide a complete Sort framework (15 algorithms, many 
> various datasets, JMH benchmarks) publicly on github:
> see https://github.com/bourgesl/nearly-optimal-mergesort-code

Laurent Bourgès has updated the pull request incrementally with one additional 
commit since the last revision:

  added test for huge polygon coords

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/674/files
  - new: https://git.openjdk.java.net/jfx/pull/674/files/8859d244..94874a15

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

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

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used

[Laurent Bourgès]

On Fri, 7 Jan 2022 23:35:37 GMT, Kevin Rushforth  wrote:

> Would a targeted test for the failing case from the bug report make sense?

I agree the rule is to have a test, I will write a basic test derived from 
user's case asap.

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used

[Laurent Bourgès]

On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourgès  wrote:

> Changelog for this MarlinFX 0.9.4.5 release:
> 
> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path 
> clipper:
> - removed simple-precision (float) variant
> - improved Stroker to handle huge coordinates, up to 1E15
> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15
> 
> 
> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement 
> fixes in the MarlinRenderingEngine:
> - Update DPQS to latest OpenJDK 14 patch
> - Improve cubic curve offset computation
> 
> 
> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix 
> in the MarlinRenderingEngine: 
> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728.
> 
> 
> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, 
> reported first against JavaFX 11: 
> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789.
> 
> 
> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot 
> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized 
> MergeSort (x-position + edge indices) for arrays larger than 256.
> 
> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 
> 19.05 with many variants, improving almost-sorted datasets. We are 
> collaborating to provide a complete Sort framework (15 algorithms, many 
> various datasets, JMH benchmarks) publicly on github:
> see https://github.com/bourgesl/nearly-optimal-mergesort-code

Sorry I forgot to explain why I did not write any new test:
- I wrote a quadrant test in my own project that tests this clipper bug 
exhaustively, using all combinations, but it was visual, not automated like a 
robot.
- existing ClipShapeTest already validates using a fuzzy testing approach all 
clipper possible cases with small coords in range [-300, 300]. The new clipper 
algorithm in this patch still passes this hardness test on small coords, so no 
regression is present. I tested up to 10^6 random shapes for every test cases 
(order 1,2,3) + all cap/join/fill combinations.
To conclude, I decided to skip writing another test for this bug.

Cheers

-

PR: https://git.openjdk.java.net/jfx/pull/674

Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used

[Laurent Bourgès]

On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourgès  wrote:

> Draft PR to see how big is the MarlinFX 0.9.4.5 patch (DPQS, Path clipper 
> fixes to handle huge coords)

I will add changelog asap

-

PR: https://git.openjdk.java.net/jfx/pull/674

RFR: 8274066: Polygon filled outside its area when very large coordinates are used

[Laurent Bourgès]

Draft PR to see how big is the MarlinFX 0.9.4.5 patch (DPQS, Path clipper fixes 
to handle huge coords)

-

Commit messages:
 - fixed jcheck warning (tab)
 - Merge branch 'openjdk:master' into marlinFX-0.9.4.5
 - minor changes (syntax, warnings) + merge with marlin 0.9.4.5 (jdk)
 - fixed bad IntArrayCache usages + clean white spaces
 - initial marlinFX 0.9.4.5 for openjfx 18

Changes: https://git.openjdk.java.net/jfx/pull/674/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=674=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274066
  Stats: 4086 lines in 31 files changed: 2594 ins; 1218 del; 274 mod
  Patch: https://git.openjdk.java.net/jfx/pull/674.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/674/head:pull/674

PR: https://git.openjdk.java.net/jfx/pull/674

Integrated: JDK-8259718 Remove the Marlin rasterizer (single-precision)

[Laurent Bourgès]

On Sun, 17 Jan 2021 15:49:33 GMT, Laurent Bourgès  wrote:

> Changes:
> - Removed single-precision Marlin renderer
> -  class name refactoring
> - fix prism
> - copyright year

This pull request has now been integrated.

Changeset: c1b14de9
Author:Laurent Bourgès 
URL:   https://git.openjdk.java.net/jfx/commit/c1b14de9
Stats: 10877 lines in 33 files changed: 6 ins; 9689 del; 1182 mod

8259718: Remove the Marlin rasterizer (single-precision)

Reviewed-by: kcr

-

PR: https://git.openjdk.java.net/jfx/pull/379

Re: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) [v3]

[Laurent Bourgès]

> Changes:
> - Removed single-precision Marlin renderer
> -  class name refactoring
> - fix prism
> - copyright year

Laurent Bourgès has updated the pull request incrementally with one additional 
commit since the last revision:

  updated Version

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/379/files
  - new: https://git.openjdk.java.net/jfx/pull/379/files/b5589b50..c8accadc

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

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

PR: https://git.openjdk.java.net/jfx/pull/379

Re: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision)

[Laurent Bourgès]

On Sun, 17 Jan 2021 15:49:33 GMT, Laurent Bourgès  wrote:

> Changes:
> - Removed single-precision Marlin renderer
> -  class name refactoring
> - fix prism
> - copyright year

How to run tests again ? I tried pull commands but it does nothing.

-

PR: https://git.openjdk.java.net/jfx/pull/379

Re: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) [v2]

[Laurent Bourgès]

> Changes:
> - Removed single-precision Marlin renderer
> -  class name refactoring
> - fix prism
> - copyright year

Laurent Bourgès has updated the pull request incrementally with one additional 
commit since the last revision:

  fixed ClipShapeTest (marlin detection)

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/379/files
  - new: https://git.openjdk.java.net/jfx/pull/379/files/07686e63..b5589b50

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

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

PR: https://git.openjdk.java.net/jfx/pull/379

RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision)

[Laurent Bourgès]

Changes:
- Removed single-precision Marlin renderer
-  class name refactoring
- fix prism
- copyright year

-

Commit messages:
 - Removed single-precision Marlin renderer + class name refactoring + fix 
prism + copyright year

Changes: https://git.openjdk.java.net/jfx/pull/379/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=379=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259718
  Stats: 10875 lines in 32 files changed: 6 ins; 9689 del; 1180 mod
  Patch: https://git.openjdk.java.net/jfx/pull/379.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/379/head:pull/379

PR: https://git.openjdk.java.net/jfx/pull/379

Re: RFR: 8196079: Remove obsolete Pisces rasterizer

[Laurent Bourgès]

On Sat, 18 Jul 2020 14:57:08 GMT, Kevin Rushforth  wrote:

> This removes the obsolete OpenPiscesRasterizer (Java-based) and 
> NativePiscesRasterizer implementations. The Marlin
> rasterizer was added in FX 9 and was made the default in FX 10. Marlin both 
> outperforms Pisces and is more robust.
> There is no reason to keep the Pisces rasterizer(s) any more.  Note that the 
> SW pipeline still has a Pisces-based
> renderer for the actual rendering of primitives. This is separate from the 
> rasterizer and is not affected by this
> proposed fix.  I have tested this on Mac, Windows, and Linux.

Loiks good to me.

-

Marked as reviewed by lbourges (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/268

Re: RFR: 8196079: Remove obsolete Pisces rasterizer

[Laurent Bourgès]

On Sat, 18 Jul 2020 22:07:59 GMT, Kevin Rushforth  wrote:

>> That's the case, michael.
>> In SWContext, the Marlin renderer is called to rasterize any shape.
>> 
>> See 
>> https://github.com/openjdk/jfx/pull/268/files#diff-28f93b00dc9cba7197f0a6c2fef022ed
>
> I think you are conflating the rasterization step with the rendering step. In 
> Prism the rasterization mainly includes
> clipping the shape and generating the mask data for the filled and/or stroked 
> shape (the latter possibly being a wide
> and/or dashed stroke). The rasterized shape is then sent to the Prism 
> GraphicsPipeline for drawing into the render
> target. This latter step is either done using shaders + D3D or OpenGL, or via 
> the SW pipeline (or the J2D pipeline for
> printing). In the case of the SW pipeline, the renderer is based on code that 
> was originally derived from Pisces, but
> it is distinct from the rasterization step that OpenPisces used to perform 
> and Marlin now does perform. Take a look at
> the [SW 
> pipeline](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/prism/sw)
> classes, the [Java
> PiscesRendering](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/pisces)
> classes, and the
> [prism-sw](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/native-prism-sw)
>  native code.

@kevinrushforth I asked skara JBS to associate my github account with my 
openjdk role...
I will approve your PR once I have proper credentials.

Good job, 10k LOC removed.

I wonder if I should also deprecate the Float-precision Marlin renderer to 
remove 10k lines too.
The Double-precision Marlin renderer was enabled as the default renderer since 
JDK10, so it is doing the job properly,
no reason to have 2 variants anymore and it will ease the maintenance.

Laurent

-

PR: https://git.openjdk.java.net/jfx/pull/268

Re: RFR: 8196079: Remove obsolete Pisces rasterizer

[Laurent Bourgès]

On Sat, 18 Jul 2020 16:11:38 GMT, Phil Race  wrote:

>> This removes the obsolete OpenPiscesRasterizer (Java-based) and 
>> NativePiscesRasterizer implementations. The Marlin
>> rasterizer was added in FX 9 and was made the default in FX 10. Marlin both 
>> outperforms Pisces and is more robust.
>> There is no reason to keep the Pisces rasterizer(s) any more.  Note that the 
>> SW pipeline still has a Pisces-based
>> renderer for the actual rendering of primitives. This is separate from the 
>> rasterizer and is not affected by this
>> proposed fix.  I have tested this on Mac, Windows, and Linux.
>
> Marked as reviewed by prr (Reviewer).

That's the case, michael.
In SWContext, the Marlin renderer is called to rasterize any shape.

See 
https://github.com/openjdk/jfx/pull/268/files#diff-28f93b00dc9cba7197f0a6c2fef022ed

-

PR: https://git.openjdk.java.net/jfx/pull/268

Re: RFR: 8189092: ArrayIndexOutOfBoundsException on Linux in getCachedGlyph

[Laurent Bourgès]

On Fri, 25 Oct 2019 20:18:48 GMT, Phil Race  wrote:

> I have added an evaluation in https://bugs.openjdk.java.net/browse/JDK-8207839
> Please read that for more detail, but basically we are not properly 
> preventing or
> handling cases where fontconfig causes us to overflow the byte storage used
> for a font "slot".
> 
> 
> 
> Commits:
>  - b6c19466: Fix whitespace
>  - e00ef992: 8189092: ArrayIndexOutOfBoundsException on Linux in 
> getCachedGlyph
> 
> Changes: https://git.openjdk.java.net/jfx/pull/24/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/24/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8189092
>   Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/24.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/24/head:pull/24

I had a quick look by curiosity as it is not my field. Explanations really make 
sense, thanks Phil.
Bit masks & shifts look good and definitely it will make that code safer.
However I wonder how to deal with more than 255 fonts (1 byte limit) as it may 
happen on some systems, even not reallistic.
Thanks

PR: https://git.openjdk.java.net/jfx/pull/24

RFR: 8226789: Path rendered incorrectly when it goes outside the clipping region

[Laurent Bourgès]

Hi,

Please review this bug fix in Marlin renderer's path clipper
:https://bugs.openjdk.java.net/browse/JDK-8226789https://github.com/javafxports/openjdk-jfx/pull/534

PS: I will propose another fix soon to JDK14 / Marlin renderer (java2d)

Laurent

Re: Javafx - graphics

[Laurent Bourgès]

Hi,

This is not stack overflow, neither a support list !
OpenJFX-dev is dedicated to OpenJFX dev, ie enhancing the JavaFX
implementation.

Concerning Vector Graphics, I made MarlinFX, the 2d shape rasterizer for
openjfx, ie Shape to pixel coverage converter integrated in Prism.

Laurent

Le sam. 8 déc. 2018 à 03:19, thepooran  a écrit :

> I am working on vector based graphic editor software and I've just started
> it with javafx. The most challenging part, I guess, is to make this
> software vector based.
>
> I think it could be done by making graphics rendering system in java and
> then use it as a part of that software but I don't know how to do it.
>
> Please help me to solve this problem.
>

Re: Text rendering on Mojave (macOS)

[Laurent Bourgès]

Hi,

It remembers me that recently (within 2 months), somebody proposed 2 patchs
to enable freetype LCDFilter for awt & javafx.

Both patches are integrated in jdk12 & jfx 12 ... probably a backport to
jdk11u & jfx11u is in progress...

Please test latest version, first.

My 2 cents,
Laurent

Le mer. 28 nov. 2018 à 16:49, Kirill Grouchnikov <
kirill.grouchni...@gmail.com> a écrit :

> I've sent this one a couple of days ago, and looks like it fell through the
> moderation cracks since it had an image attached to it. So sending this
> again...
>
> So I spent some time today looking into font rendering on the latest macOS
> 10.14 (Mojave), I came across
> https://news.ycombinator.com/item?id=17476873
> that says that it has removed the subpixel anti-aliasing setting. There's a
> new one under "General" named "Use font smoothing when available".
>
> When that setting is on (which is by default), font rendering in Swing with
> the recommended awt.font.desktophints system property is too heavy. Looking
> at how
>
> https://github.com/JetBrains/intellij-community/blob/master/platform/editor-ui-api/src/com/intellij/ide/ui/UISettings.kt
> is doing it (lines 399-420) it appears that they are setting
> KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, and doing that in Swing
> results in font rendering that is consistent with native apps.
>
> Then I looked at how JavaFX font rendering looks like with locally built
> https://github.com/gluonhq/gluon-samples/tree/master/fifty-states
>
> No matter if that new platform setting is off or on, all the texts look
> halo'd - zoom in on
> https://www.pushing-pixels.org/wp-content/uploads/2018/11/javafx-mojave.png
> and see all those pink / light blue pixels around glyphs.
>
> Am I running the demo wrong?
>

Re: JavaFX 11.0.1-ea+1 release

[Laurent Bourgès]

Thanks,

That is important to me to share publicly release notes.

Cheers,
Laurent

Le ven. 2 nov. 2018 à 14:12, Kevin Rushforth  a
écrit :

> The JBS query would only show up the one Marlin fix, because the rest
> were confidential security bugs. Here is the list, as seen in the 'hg log'
>
> 8194321: Update FX installer
> 8195879: Improve media support
> 8204365: Improve WebView processing
> 8204880: Enhance object method calls
> 8207387: WebView is not rendering html checkbox and radio buttons
> 8210386: Clipping problems with complex affine transforms: negative
> scaling factors or small scaling factors
>
> -- Kevin
>
>
> On 11/2/2018 3:52 AM, Laurent Bourgès wrote:
> > Hi,
> >
> > Could you publish the list of included bug fixed (JBS query) ?
> >
> > Cheers,
> > Laurent
> >
> > Le ven. 2 nov. 2018 à 10:00, Johan Vos  a écrit :
> >
> >> Hi,
> >>
> >> We are about to release JavaFX 11.0.1, containing the fixes that made it
> >> into the 11-dev repository.
> >> An early-access build for this is available as SDK/jmods at
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> >> <
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
> >>
> >> The maven artifacts are available in the usual repositories, with
> version
> >> tag being "11.0.1-ea+1" e.g.
> >>
> >> org.openjfx:javafx-base:11.0.1-ea+1 (see
> >>
> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
> >>
> >> If we don't hear major issues with this ea, it should become the 11.0.1
> >> release.
> >>
> >> - Johan
> >>
>
>

Re: JavaFX 11.0.1-ea+1 release

[Laurent Bourgès]

Hi,

Could you publish the list of included bug fixed (JBS query) ?

Cheers,
Laurent

Le ven. 2 nov. 2018 à 10:00, Johan Vos  a écrit :

> Hi,
>
> We are about to release JavaFX 11.0.1, containing the fixes that made it
> into the 11-dev repository.
> An early-access build for this is available as SDK/jmods at
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> <
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>
> The maven artifacts are available in the usual repositories, with version
> tag being "11.0.1-ea+1" e.g.
>
> org.openjfx:javafx-base:11.0.1-ea+1 (see
> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>
> If we don't hear major issues with this ea, it should become the 11.0.1
> release.
>
> - Johan
>

Re: Review request backport 8210386

[Laurent Bourgès]

Thank you,

Laurent

Le lun. 29 oct. 2018 à 19:35, Kevin Rushforth 
a écrit :

> Looks good. Approved for pushing to 11-dev.
>
> -- Kevin
>
> On 10/29/2018 11:27 AM, Johan Vos wrote:
> > new webrev including test:
> > http://cr.openjdk.java.net/~jvos/8210386/webrev.01/
> > 
> >
> > On Mon, Oct 29, 2018 at 5:55 PM Kevin Rushforth
> > mailto:kevin.rushfo...@oracle.com>> wrote:
> >
> > The newly added test, which was pushed to jfx-dev as part of the
> > fix for
> > 12, is missing from the webrev:
> >
> > tests/system/src/test/java/test/com/sun/marlin/ScaleClipTest.java
> >
> > The rest looks OK.
> >
> > -- Kevin
> >
> >
> > On 10/29/2018 9:39 AM, Johan Vos wrote:
> > > Hi Kevin,
> > >
> > > Please review the backport of 8210386 (Marlin fixes) into 11-dev
> > (target
> > > 11.0.1)
> > > http://cr.openjdk.java.net/~jvos/8210386/webrev.00/
> > 
> > >
> > > - Johan
> >
>
>

[12] RFR: JDK-8210386: Clipping problems with complex affine transforms

[Laurent Bourgès]

Please review the following bug fix in the MarlinFX renderer for JavaFX 12:
https://bugs.openjdk.java.net/browse/JDK-8210386
https://github.com/javafxports/openjdk-jfx/pull/206

PS: What is the process to backport this bug fix to OpenJFX 11 updates ?
This patch is small and can be applied directly to OpenJFX 11.

Thanks,
Laurent

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

[Laurent Bourgès]

Johan,
I agree Marlin 0.9.2 provides new clipping algorithms (curve subdivision &
clipping in the dasher stage) so it involves lots of maths and tricks ...

I implemented the automated ClipShapeTest that compares rendering with
clipping enabled vs disabled for all possible combinations:
- stroked & dashed paths with all sort of joins / caps
- filled paths with all filling rules (NZ /EO)
with
 lines/quads/curves ...

This intensive test proves new algorithms do not introduce visual
regressions except that clipped stroked curves are slightly different due
to the curve offsetting algorithm. Such problem has no exact solution and
the approximated offsetted curve causes the minor visual differences along
the stroked curve.

Finally MarlinFX 0.9.2 is giving same clipping accuracy than Marlin 0.9.1
integrated in jdk11.
Performance is mainly improved for huge dashed paths.

Kevin & Johan, do you consider the last webrev is approved by 2 reviewers ?

Laurent

Le jeu. 5 juil. 2018 à 11:46, Johan Vos  a écrit :

> I had a slightly deeper look and had a few comments, but it's hard to
> check the math behind it and evaluating performance without doing real
> tests.
> However, I feel confident we can merge it. That will also allow eager
> developers to use it and provide feedback.
>
> - Johan
>
> On Wed, Jul 4, 2018 at 9:55 AM Johan Vos  wrote:
>
>> I looked at it, mainly at the differences between the Java2D patch and
>> the JavaFX patch, and it looks ok to me.
>> I'll try to test it on linux and/or mac later today and have a deeper
>> look.
>>
>> - Johan
>>
>>
>> On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Looks good.
>>>
>>> +1 -- note that needs a second reviewer (doesn't need to be a capital-R
>>> Reviewer).
>>>
>>> -- Kevin
>>>
>>>
>>> On 7/3/2018 8:56 AM, Kevin Rushforth wrote:
>>> >> PS: I am not really satisfied by adding such noise in build.gradle,
>>> >> but it can be improved later ...
>>> >
>>> > Agreed. This can be a follow-on issue. I'll finish my review shortly.
>>> >
>>> > -- Kevin
>>> >
>>> >
>>> > On 7/3/2018 8:45 AM, Laurent Bourgès wrote:
>>> >> Kevin,
>>> >>
>>> >> > I added the system property "ClipShapeTest.numTests" but it
>>> >> requires a
>>> >> build.gradle change to pass the parameter:
>>> >>
>>> >> Yes, something like this is what I had in mind. As long as we
>>> >> don't add too many of these, it is OK with me. Note that as coded,
>>> >> the build will fail if you don't define ClipShapeTest.numTests, so
>>> >> you will need to check for that. I note also that you used tabs in
>>> >> build.gradle (so please change them to spaces). I recommend the
>>> >> following logic:
>>> >>
>>> >> if (rootProject.hasProperty("ClipShapeTest.numTests")) {
>>> >> systemProperty "ClipShapeTest.numTests",
>>> >> rootProject.getProperty("ClipShapeTest.numTests")
>>> >> }
>>> >>
>>> >>
>>> >> I adopted your proposal and updated the webrev:
>>> >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/
>>> >> <http://cr.openjdk.java.net/%7Elbourges/marlinFX/marlinFX-092.2/>
>>> >>
>>> >> PS: I am not really satisfied by adding such noise in build.gradle,
>>> >> but it can be improved later ...
>>> >>
>>> >> Laurent
>>> >
>>>
>>>

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

[Laurent Bourgès]

Thanks Kevin for your approval.

Phil or Sergey, could you make another review ?

I would like to push this large patch in jfx 11.

Regards,
Laurent

Le mar. 3 juil. 2018 à 18:03, Kevin Rushforth 
a écrit :

> Looks good.
>
> +1 -- note that needs a second reviewer (doesn't need to be a capital-R
> Reviewer).
>
> -- Kevin
>
>
> On 7/3/2018 8:56 AM, Kevin Rushforth wrote:
> >> PS: I am not really satisfied by adding such noise in build.gradle,
> >> but it can be improved later ...
> >
> > Agreed. This can be a follow-on issue. I'll finish my review shortly.
> >
> > -- Kevin
> >
> >
> > On 7/3/2018 8:45 AM, Laurent Bourgès wrote:
> >> Kevin,
> >>
> >> > I added the system property "ClipShapeTest.numTests" but it
> >> requires a
> >> build.gradle change to pass the parameter:
> >>
> >> Yes, something like this is what I had in mind. As long as we
> >> don't add too many of these, it is OK with me. Note that as coded,
> >> the build will fail if you don't define ClipShapeTest.numTests, so
> >> you will need to check for that. I note also that you used tabs in
> >> build.gradle (so please change them to spaces). I recommend the
> >> following logic:
> >>
> >> if (rootProject.hasProperty("ClipShapeTest.numTests")) {
> >> systemProperty "ClipShapeTest.numTests",
> >> rootProject.getProperty("ClipShapeTest.numTests")
> >> }
> >>
> >>
> >> I adopted your proposal and updated the webrev:
> >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/
> >> <http://cr.openjdk.java.net/%7Elbourges/marlinFX/marlinFX-092.2/>
> >>
> >> PS: I am not really satisfied by adding such noise in build.gradle,
> >> but it can be improved later ...
> >>
> >> Laurent
> >
>
>

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

[Laurent Bourgès]

Kevin,

> I added the system property "ClipShapeTest.numTests" but it requires a
> build.gradle change to pass the parameter:
>
> Yes, something like this is what I had in mind. As long as we don't add
> too many of these, it is OK with me. Note that as coded, the build will
> fail if you don't define ClipShapeTest.numTests, so you will need to check
> for that. I note also that you used tabs in build.gradle (so please change
> them to spaces). I recommend the following logic:
>
> if (rootProject.hasProperty("ClipShapeTest.numTests")) {
> systemProperty "ClipShapeTest.numTests",
> rootProject.getProperty("ClipShapeTest.numTests")
> }
>

I adopted your proposal and updated the webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.2/

PS: I am not really satisfied by adding such noise in build.gradle, but it
can be improved later ...

Laurent

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

[Laurent Bourgès]

Kevin,

Thanks for the review !

2018-06-29 22:52 GMT+02:00 Kevin Rushforth :

> I'm giving a +1 on the implementation changes. I scanned the webrev and
> didn't see anything out of place. I compared the diffs of the FX Marlin
> 0.9.2 with the Java2D 0.9.1 changeset, and there were a few more diffs than
> I might have expoected, but nothing jumped out of me as a problem. Also,
> I've tested it pretty well on all three platforms.
>
> The overall +1 is pending the fixes needed for the test: at least the
> copyright header and shortening or disabling the test.
>

Here is the updated webrev fixing the test:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.1/

ClipShapeTest incremental diff:
--- /tmp/meld-tmpyWO0FS
+++
/home/bourgesl/libs/marlin/branches/marlin-fx-openjdk/src/test/java/test/manual/marlin/ClipShapeTest.java
@@ -4,7 +4,9 @@
  *
  * 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.
+ * published by the Free Software Foundation.  Oracle designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Oracle in the LICENSE file that accompanied this code.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
@@ -219,12 +221,10 @@

 // cubic min/max error:
 System.setProperty("prism.marlin.cubic_dec_d2", "1e-3");
-System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); // or
disabled ~ 1e-6
+System.setProperty("prism.marlin.cubic_inc_d1", "1e-4");

 // quad max error:
 System.setProperty("prism.marlin.quad_dec_d2", "5e-4");
-
-System.setProperty("javafx.animation.fullspeed", "true"); // full
speed
 }

 // Application class. An instance is created and initialized before
running
@@ -273,7 +273,7 @@
 }

 private static void resetOptions() {
-NUM_TESTS = 5000;
+NUM_TESTS = Integer.getInteger("ClipShapeTest.numTests", 100);

 // shape settings:
 SHAPE_MODE = ShapeMode.NINE_LINE_POLYS;

Changes:
- fixed license (Classpath exception)
- removed "javafx.animation.fullspeed" in the test setup
- use 100 tests by default to shorten the test duration (but I kept the
high timeout values if the following parameter is increased):

I added the system property "ClipShapeTest.numTests" but it requires a
build.gradle change to pass the parameter:

 +// Marlin ClipShapeTest+
systemProperty "ClipShapeTest.numTests",
project.getProperty("ClipShapeTest.numTests")+

If it is not recommended to add such specific parameters into the
build.gradle file, what do you recommend ? (manual edit ?)

Best regards,
Laurent



>
> On 6/29/2018 11:25 AM, Kevin Rushforth wrote:
>
>> One more thing about the test. All of the OpenJFX unit tests should have
>> GPL v2 + Classpath Exception (this differs from the JDK).
>>
>> -- Kevin
>>
>>
>> On 6/29/2018 10:23 AM, Kevin Rushforth wrote:
>>
>>>
>>> I'll plan to review the code today if possible. This will need one more
>>> reviewer, so maybe Phil can also review it, since he reviewed the Java2D
>>> patch?
>>>
>>> As for my comments on the test:
>>>
>>> Finally I think this test should be manually run only if Marlin renderer
>>>> is modified.
>>>> How to do that ? use @Ignore or specific tags ?
>>>>
>>>
>>> As a slight variation of this: How about running a small number (say,
>>> 200 or 250) by default, but adding a flag to run more? Alternatively, you
>>> could use a flag to enable it, but since you would need to do something
>>> extra (provide a flag or modify the test) to run it, we might as well get
>>> at least some testing all the time. Unless you really think there is no
>>> value in doing this.
>>>
>>> I deliberately set all these Marlin clip (runtime + always subdivider) /
>>>> curve quality settings (quads / cubics thresholds) to be sure of the
>>>> concrete Marlin setup as quality thresholds are sensitive to such values.
>>>>
>>>
>>> As a best practice, tests should generally be run using the same
>>> settings as are used in production. Other than to verify how it behaves
>>> when you change these settings, I don't see the value in testing the system
>>> running in a mode that no application will ever see. I may be missing some
>>> point here.
>>>
>>> -- K

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

[Laurent Bourgès]

Kevin,

Here are my comments below:

2018-06-16 1:47 GMT+02:00 Kevin Rushforth :

> I tested this on all three platforms and the updated rasterizer looks good.
>
> I spot checked the code changes, but didn't get time to do a complete
> review yet. I was mostly looking for diffs between the Java2D version which
> was already reviewed, and this one.
>
> I do have a couple comments on the new ClipShapeTest (which looks like a
> nice accuracy test, btw).
>
> 1. The test runs for way too long (about 20x too long) to include in our
> normal test runs. By default the entire class file (all three tests) needs
> to take < 5 minutes and 2 minutes would be better. I measured the time on 4
> machines that I have and found that if you cut the number of iterations
> down from 5000 to 250 it will be just about the right run time. Then you
> can set the timeout to 120 seconds (the slowest test on the slowest of my
> machines took about 48 seconds, so a 2 minute timeout should be plenty).
>

I agree this test is very long but it is the only mean I found to test all
possible stroke combinations and test enough shapes (5000) to detect bugs.
I wondered if using mask directly (via ShapeUtils.getMaskData()) would
become faster but it will never run below the 2 minutes threshold in total.

Finally I think this test should be manually run only if Marlin renderer is
modified.
How to do that ? use @Ignore or specific tags ?


> 2. Can you explain the reason for setting the following?
>
>  206 // disable static clipping setting:
>  207 System.setProperty("prism.marlin.clip", "false");
>  208 System.setProperty("prism.marlin.clip.runtime.enable",
> "true");
>  209
>  210 // enable subdivider:
>  211 System.setProperty("prism.marlin.clip.subdivider", "true");
>  212
>  213 // disable min length check: always subdivide curves at clip
> edges
>  214 System.setProperty("prism.marlin.clip.subdivider.minLength", "-1");
>  215
>  216 // If any curve, increase curve accuracy:
>  217 // curve length max error:
>  218 System.setProperty("prism.marlin.curve_len_err", "1e-4");
>  219
>  220 // cubic min/max error:
>  221 System.setProperty("prism.marlin.cubic_dec_d2", "1e-3");
>  222 System.setProperty("prism.marlin.cubic_inc_d1", "1e-4"); //
> or disabled ~ 1e-6
>  223
>  224 // quad max error:
>  225 System.setProperty("prism.marlin.quad_dec_d2", "5e-4");
>
> It seems better to test with the default parameters (i.e., it makes a
> better regression test that way).
>

I deliberately set all these Marlin clip (runtime + always subdivider) /
curve quality settings (quads / cubics thresholds) to be sure of the
concrete Marlin setup as quality thresholds are sensitive to such values.

The ClipShapeTest is dedicated to test the clipper (+ subdivider) part of
the Marlin renderer.


>
>
> 3. Related to that, I think you should eliminate the following (I don't
> recommend running functional tests with this set), although since you don't
> do any animation, it probably doesn't matter.
>
>  227 System.setProperty("javafx.animation.fullspeed", "true"); //
> full speed
>

I will remove it and see if the overall test is not slower.
Is Platform.runLater() impacted by such setting (latency of FX thread ->
Prism rendering thread ?) ?

Laurent



>
> On 6/8/2018 7:28 AM, Laurent Bourgès wrote:
>
>> Hi,
>>
>> Please review this large patch to upgrade MarlinFX to 0.9.2 in OpenJFX11:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8198885
>> webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/ <
>> http://cr.openjdk.java.net/%7Elbourges/marlinFX/marlinFX-092.0/>
>> PR: https://github.com/javafxports/openjdk-jfx/pull/96 (CI OK)
>>
>> This patch is almost identical to Marlin(2D) patch, see:
>> https://bugs.openjdk.java.net/browse/JDK-8198885
>>
>> I added the ClipShapeTest (ported to jfx) that compares shape clipping
>> (within threshold) and it works (within large timeouts):
>> gradle -PFULL_TEST=true :system:test --tests
>> test.com.sun.marlin.ClipShapeTest
>>
>> Regards,
>> Laurent
>>
>
>

[11] JDK-8204621: Upgrade MarlinFX to 0.9.2

[Laurent Bourgès]

Hi,

Please review this large patch to upgrade MarlinFX to 0.9.2 in OpenJFX11:
JBS: https://bugs.openjdk.java.net/browse/JDK-8198885
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-092.0/
PR: https://github.com/javafxports/openjdk-jfx/pull/96 (CI OK)

This patch is almost identical to Marlin(2D) patch, see:
https://bugs.openjdk.java.net/browse/JDK-8198885

I added the ClipShapeTest (ported to jfx) that compares shape clipping
(within threshold) and it works (within large timeouts):
gradle -PFULL_TEST=true :system:test --tests
test.com.sun.marlin.ClipShapeTest

Regards,
Laurent

[11] RFR JDK-8202743: Dashed Stroke randomly painted incorrectly, may freeze application

[Laurent Bourgès]

Please review this simple fix for MarlinFX Dasher:

JBS: https://bugs.openjdk.java.net/browse/JDK-8202743
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8202743.0/

Github Pull request: https://github.com/javafxports/openjdk-jfx/pull/87

Notes:

   - (D)Dasher changes corresponds to MarlinFX 0.8.2 (upgrade to 0.9.2
   later)
   - test adapted to javafx API using scene.snapshot()


Laurent

Re: OpenJFX GitHub mirror

[Laurent Bourgès]

Hi,

As such github references point to either issue or PR, I recommend using
the term 'github-link'.

Laurent

Le jeu. 29 mars 2018 à 03:40, Kevin Rushforth 
a écrit :

> I think this would be fine. We would want something that didn't conflict
> with anything else and wasn't confusing. Possible choices:
>
> github-link
> github-bug
> gitbug-issue
>
> Any preferences?
>
> -- Kevin
>
>
> Nir Lisker wrote:
> > Kevin, can we get a label for this?
> >
> > - Nir
> >
> > On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos 
> wrote:
> >
> >
> >> Hi Nir,
> >>
> >> About 4. (jfx-dev): you're right, I just removed that repository. That
> was
> >> just some testing before we did the real thing.
> >>
> >> As for the other points: I agree
> >>
> >> - Johan
> >>
> >> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker  wrote:
> >>
> >>
> >>> Hi All,
> >>>
> >>> A few comments about the mirror and JBS:
> >>>
> >>> 1. In PRs and issues on GitHub, I strongly suggest that the link to
> JBS be
> >>> included in the top comment. If the JBS issue was created after a
> >>> discussion, edit it in.
> >>>
> >>> 2. In JBS, I suggest to link to the GitHub mirror via More > Link > Web
> >>> Link and in the Link Text use something like "GitHub mirror" (open for
> >>> suggestions). JIRA renders the link in an easy to see way (easier than
> >>> looking at URLs). Iv'e tried it in a couple of issues, e.g.,
> >>> https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems
> preferable
> >>> to
> >>> me.
> >>>
> >>> 3. In JBS, I suggest a new label will be used for issues which are
> linked
> >>> to GitHub for search purposes. This is similar to the webbug label.
> >>>
> >>> If these are agreeable, please add them to the contribution
> instructions.
> >>>
> >>> 4. What is https://github.com/javafxports/jfx-dev? Newcomers can
> confuse
> >>> it
> >>> with javafxports/openjdk-jfx.
> >>>
> >>> 5. When the mirror is fully ready and operational, we should advertise
> on
> >>> community pages (like Reddit) to gather up contributors. Please keep a
> >>> mental reminder when the time comes.
> >>>
> >>> Thanks to all who are working on this.
> >>>
> >>> - Nir
> >>>
> >>>
>

[11] Review request: JDK-8196617: FX print tests fail with NPE in some environments

[Laurent Bourgès]

Kevin,

Please review this webrev that fixes the NPE in getMediaName():
JBS: https://bugs.openjdk.java.net/browse/JDK-8196617
webrev: http://cr.openjdk.java.net/~lbourges/fx/fx-8196617.0/

It was tested OK on the appveyor CI that failed before the patch.

Thanks,
Laurent

Re: Test failures running on OS X

[Laurent Bourgès]

Kevin,

It is possible to define the Locale (set user.language=...) in the gradle
build file, that would avoid touching the java code at all.

I have no opinion what is preferable to have less maintenance work or
problems in future.

Laurent

2018-03-12 16:09 GMT+01:00 Kevin Rushforth <kevin.rushfo...@oracle.com>:

> I haven't run these with a Locale other than en_US, but given the nature
> of the failure, it looks like you may have discovered another
> Locale-related test bug.
>
> We had another test that was fixed by setting the default Locale to
> Locale.US in a static @BeforeClass method in the test class [1]. Perhaps a
> similar solution is needed here.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8160039
>
>
>
> Sven Reimers wrote:
>
>> Hi,
>>
>> getting back into the OpenJFX I started with a fresh clone and ran gradle
>> test..
>>
>> I got
>>
>> test.javafx.scene.control.SpinnerTest >
>> dblSpinner_testToString_valueInRange FAILED
>> junit.framework.ComparisonFailure: null expected:<0[.]3> but
>> was:<0[,]3>
>> at junit.framework.Assert.assertEquals(Assert.java:81)
>> at junit.framework.Assert.assertEquals(Assert.java:87)
>> at
>> test.javafx.scene.control.SpinnerTest.dblSpinner_testToStrin
>> g_valueInRange(SpinnerTest.java:607)
>>
>> test.javafx.scene.control.SpinnerTest >
>> dblSpinner_testFromString_valueInRange FAILED
>> junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0>
>> at junit.framework.Assert.fail(Assert.java:47)
>> at junit.framework.Assert.failNotEquals(Assert.java:283)
>> at junit.framework.Assert.assertEquals(Assert.java:64)
>> at junit.framework.Assert.assertEquals(Assert.java:71)
>> at
>> test.javafx.scene.control.SpinnerTest.dblSpinner_testFromStr
>> ing_valueInRange(SpinnerTest.java:615)
>>
>> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel
>> FAILED
>> junit.framework.ComparisonFailure: null expected:<2[.]5> but
>> was:<2[,]5>
>> at junit.framework.Assert.assertEquals(Assert.java:81)
>> at junit.framework.Assert.assertEquals(Assert.java:87)
>> at
>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC
>> ancel(SpinnerTest.java:1334)
>>
>> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_valid
>> FAILED
>> junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0>
>> at junit.framework.Assert.fail(Assert.java:47)
>> at junit.framework.Assert.failNotEquals(Assert.java:283)
>>     at junit.framework.Assert.assertEquals(Assert.java:64)
>> at junit.framework.Assert.assertEquals(Assert.java:71)
>> at
>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC
>> ommit_valid(SpinnerTest.java:1308)
>>
>> This is with gradle 46, 9.0.4 on a german locale OS X...
>>
>> Any ideas what to look for?
>>
>> Thanks
>>
>> Sven
>>
>>
>


-- 
-- 
Laurent Bourgès

Re: Test failures running on OS X

[Laurent Bourgès]

Hi,

I confirm I have the same problem on my FR Locale.

I added -Duser.language=en to the gradle command line and it worked.
Alternatively set LANG=US in your env.

It should be fixed in build.gradle...

Cheers,
Laurent

Le 10 mars 2018 11:07 PM, "Sven Reimers"  a écrit :

> Hi,
>
> getting back into the OpenJFX I started with a fresh clone and ran gradle
> test..
>
> I got
>
> test.javafx.scene.control.SpinnerTest >
> dblSpinner_testToString_valueInRange FAILED
> junit.framework.ComparisonFailure: null expected:<0[.]3> but
> was:<0[,]3>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at
> test.javafx.scene.control.SpinnerTest.dblSpinner_
> testToString_valueInRange(SpinnerTest.java:607)
>
> test.javafx.scene.control.SpinnerTest >
> dblSpinner_testFromString_valueInRange FAILED
> junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:283)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:71)
> at
> test.javafx.scene.control.SpinnerTest.dblSpinner_
> testFromString_valueInRange(SpinnerTest.java:615)
>
> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel FAILED
> junit.framework.ComparisonFailure: null expected:<2[.]5> but
> was:<2[,]5>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at
> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_
> testCancel(SpinnerTest.java:1334)
>
> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_valid
> FAILED
> junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:283)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:71)
> at
> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_
> testCommit_valid(SpinnerTest.java:1308)
>
> This is with gradle 46, 9.0.4 on a german locale OS X...
>
> Any ideas what to look for?
>
> Thanks
>
> Sven
>

[11] Review request: JDK-8189689: JavaFX build fails with gcc 6

[Laurent Bourgès]

Kevin,

Please review the following webrev that fixes compilation with gcc 6, that
was initiated on github by Emmanuel Bourg (@ebourg) in PR #11 and #16

https://bugs.openjdk.java.net/browse/JDK-8189689
http://cr.openjdk.java.net/~lbourges/fx/fx-8189689.0/

Thanks,
Laurent

Re: Repositories, AdoptOpenJDK and github

[Laurent Bourgès]

Johan,
I am following the long discussion and I mostly agree what was said.

Maybe it is time to start working on github on few minor / trivial bugs...
to test all the new process.

I propose to extract few JBS bugs (small) with high ROI (agile /scrum
approach) and create shadow copies into github issues (id, title, short
description & JBS LINK) to be proposed to the jfx community.

That would become our backlog that can be managed in a kanban board (github
project). Moreover it would be awesome if such board would gather the
activity of both oracle & community people on OpenJFX.

Once somebody wants to work on one issue, just comment on the github issue
and start working in your fork, make PR...

Adopting this method, anybody will know publicly what's going on and it
would reduce the risk of conflicts (code merge)

My 2 cents...

Let's go on,
"We are the champions..."

Laurent


Le 28 févr. 2018 9:15 AM, "Johan Vos"  a écrit :

That is the difficult point indeed.
But why would a PR to OpenJFX be rejected after it was approved in the
github mirror? I would assume the main reason for this is because the PR
did not what it was supposed to do. In that case, it makes sense to remove
the commits from the github mirror as well.

I think the main thing here is that we need to be very serious about
reviewing and accepting PR's in the github mirror. Accepting a PR in github
does not require the *formal* process of creating webrevs etc, but it
requires discussion about the issue with reviewers of OpenJFX.
We have to minimize the number of times an edge case occurs, in which the
discussion was pro PR first, but after it got merged into "development" new
arguments are brought up against the PR.
I think it would be good to have sort of a post-mortem analysis in case
this happens, in order to prevent it from happening again. But as I said,
if it does happen, it probably has good reasons and in that case we have to
remove it from the development branch as well.

I think the more common case would be that an issue is fixed on the github
mirror, but not yet accepted (nor rejected) in OpenJFX, so there will be
some time lag between the PR acceptance and the integration in OpenJFX. But
this should not be a problem, as long as the following scenario is the main
flow:

The github master branch is always synced with OpenJFX, and never gets
modified by other commits.
The github "development" branch is where we accept PR's, that can then be
send upstream. Changes from "master" are regularly merged into
"development". The moment an accepted PR makes it into OpenJFX, it will be
synced into "master" and merged into "development" where the merge happens
silently as there are no conflicts (since development already has this
code).

Does that make sense?

- Johan

On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth 
wrote:

>
>
> Nir Lisker wrote:
>
> Johan's thinking was to allow Committers to approve the PR on GitHub --
>> meaning they could be merged on GitHub before an actual Review has
>> happened. Are you proposing to change that?
>
>
> What if the PR is rejected at review? We'll end up with conflicts between
> the repos. And supposed someone works on a different fix and uses the
> rejected PR code, how will that be committed?
>
>
> Good questions; maybe Johan has some thoughts as to how to mitigate this?
>
>
> -- Kevin
>
>
>
> On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> This seems a good start in formalizing the process. It will need a little
>> tweaking in a couple of areas.
>>
>> Regarding JBS access, even though I want to relax the requirement to
>> become an Author (get a JBS account), it will likely end up somewhere
>> between "an intention to contribute" and "two sponsored contributions,
>> already reviewed and committed". Even without this, there will
necessarily
>> be a gap in time between "I want to work on a bug" and getting a JBS
>> account. So there is value in encouraging people to clone the GitHub
>> sandbox, "kick the tires", make a PR to get feedback, etc., before they
can
>> access JBS directly (or even while waiting for their OCA to be processed,
>> but no PRs in that case). Something to take into account.
>>
>> Regarding review, we will need a bit more discussion on that. I like the
>> idea of the PR being logged in JBS once it is ready to be reviewed.
Johan's
>> thinking was to allow Committers to approve the PR on GitHub -- meaning
>> they could be merged on GitHub before an actual Review has happened. Are
>> you proposing to change that? It might have some advantages, but it could
>> also make it harder in other areas. I'd like to hear from Johan on this.
>> This reminds me that we need to continue the discussion on the general
>> "Review" policy, as it is relevant here.
>>
>> As for whether it is merged into GitHub, I don't have a strong opinion on
>> that. As you say it will be pulled into the mirror 

Re: More community participation in JavaFX

[Laurent Bourgès]

Hi folks,

Please respect the 2 threads with different scopes:
- this one on how to simplify external contributions (infrastructure,
review policies...)
- the other one on javafx features...

Please stay in the scope & being constructive...
I personally improved the prism shape rasterizer (marlinfx @ github) on my
own time... integrated in jfx9+ as it is its real place (javafx.graphics
module).

I totally agree Jonathan & Johan that new features should be first
developped externally in third party libraries... and could be merged in
JavaFX core if it is worthful or required (low level API or module
encapsulation issue ?).

Finally I can help on graphics performance so we could create a small perf
team.
Moreover, funding FOS projects need clients or creating sponsorship
programs (grant, awards) but it is another challenge.

Cheers,
Laurent

Le 7 févr. 2018 8:38 AM, "John-Val Rose"  a écrit :

> Jonathan - why do you *cough* at ideas like more complex controls and
> docking frameworks?
>
> I think that a docking framework especially would be a great addition to
> JavaFX.
>
> Am I missing something?
>
> > On 7 Feb 2018, at 18:16, Jonathan Giles 
> wrote:
> >
> > Obviously everyone is at ControlsFX instead ;-)
> >
> > Part of the drop I would suggest is simply that many of the itches people
> > want to scratch are now scratched. Alternatively, the remaining itches
> are
> > either in more complex controls (*cough* docking frameworks *cough*) or
> in
> > areas beneath the controls APIs - performance, webview, etc - which are
> > more challenging and require greater levels of dedication.
> >
> > However, more generally, your point is well made - contribution to JavaFX
> > does not need to be synonymous with contribution to OpenJFX. People who
> > find the challenges of the current OpenJFX requirements too great should
> be
> > encouraged to involve themselves in projects such as JFXtras, etc.
> >
> > -- Jonathan
> >
> >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink  wrote:
> >>
> >> Many years ago I had a discussion with Jonathan Giles about if the
> things
> >> that were being made in JFXtras would eventually become part of the
> JavaFX
> >> core. In the end I decided that, for me personally, I could do the
> things I
> >> wanted to perfectly in a separate project. The rigid structure that
> >> Java(FX) has to adhere to, would be a big downside.
> >>
> >> What I want to say with that is that all the external projects are also
> >> contributions to JavaFX. It does not matter whether for example a
> control
> >> is part of the core distribution or of a side project; it is just
> another
> >> module users can add to the mix.
> >>
> >> So reflecting back I still stand by that choice. But having a few more
> >> people in the project (just like in JavaFX ;-) ) would be nice, but
> OTOH it
> >> forces me to deal with (and learn about) annoying stuff like Gradle
> build
> >> scripts and Java 9 migration. But because of that progress is not as
> fast
> >> as I would like it to be. Could it be that there is a decline in people
> >> willing to work for open source projects? Or is it just that this tech,
> >> JavaFX, is no longer appealing?
> >>
> >> Tom
> >>
> >>
> >>
> > Obviously everyone is at ControlsFX instead ;-)
> >
> > Part of the drop I would suggest is simply that many of the itches people
> > want to scratch are now scratched. Alternatively, the remaining itches
> are
> > either in more complex controls (*cough* docking frameworks *cough*) or
> in
> > areas beneath the controls APIs - performance, webview, etc - which are
> > more challenging and require greater levels of dedication.
> >
> > However, more generally, your point is well made - contribution to JavaFX
> > does not need to be synonymous with contribution to OpenJFX. People who
> > find the challenges of the current OpenJFX requirements too great should
> be
> > encouraged to involve themselves in projects such as JFXtras, etc.
> >
> > -- Jonathan
> >
> >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink  wrote:
> >>
> >> Many years ago I had a discussion with Jonathan Giles about if the
> things
> >> that were being made in JFXtras would eventually become part of the
> JavaFX
> >> core. In the end I decided that, for me personally, I could do the
> things I
> >> wanted to perfectly in a separate project. The rigid structure that
> >> Java(FX) has to adhere to, would be a big downside.
> >>
> >> What I want to say with that is that all the external projects are also
> >> contributions to JavaFX. It does not matter whether for example a
> control
> >> is part of the core distribution or of a side project; it is just
> another
> >> module users can add to the mix.
> >>
> >> So reflecting back I still stand by that choice. But having a few more
> >> people in the project (just like in JavaFX ;-) ) would be nice, but
> OTOH it
> >> forces me to deal with (and learn about) 

Re: More community participation in JavaFX

[Laurent Bourgès]

Hi Chris,



I'm more than happy to keep the community JavaFX build server at
chriswhocodes.com running and host JDK 8/9/10/n + FX builds there.

At the moment it's mostly used by the Raspberry Pi community to grab
JavaFX overlays for JDK8 on ARM.

I can also build and host OSX and Windows builds there once the build
instructions are updated.


Excellent but we should discuss with adoptopenjdk or you how to build &
provide OpenJFX release more widely...

I would definitely love having an openjfx github mirror and use any CI
(travis ?) to submit patches & obtain build & test results.

Graal compiler is already on github, why not openjfx ?
At least to prepare openjfx patches and broaden the community contributions.

However you are focused on jdk8, so we could try providing MarlinFX too on
jdk8 builds too if it may interest users.

However we should avoid providing too many custom builds... users will be
lost by the diversity: we should find a single place to host OpenJFX EA
builds.


Lastly I'd also be interested in profiling and contributing performance
enhancements to the FX Java source code based on JIT analysis. IMO it
would be useful if the OpenJFX team would make a statement on what kind of
contributions fit with their overall vision (e.g. increasing performance
vs bug fixing desktop widgets).


Please go on, any perf improvement is great (and help saving our planet) !

PS: big thanks for JITWatch !

Kindly regards,
Laurent

Re: Building OpenJFX.

[Laurent Bourgès]

Phil,
I am using ubuntu 17.4 (soon will upgrade to 17.10) and gcc 6 is the
default compiler.

I submitted a jfx bug as I had to fix some c code (wait call) and ignore
warnings (as error) to build OpenJFX / JDK 10 on gcc6.

I may help fixing some warnings but I am not an expert of javafx native
code so I can give you at least the complete list of gcc warnings.

My 2 cents...
Cheers,
Laurent

Le 19 déc. 2017 21:12, "Phil Race"  a écrit :

> In the "innovation" email thread it was suggested that one obstacle to
> getting involved and contributing to OpenJFX is just building it.
>
> So what are the top one or two pain points with building OpenJFX today ?
>
> - Insufficient or out-dated build docs ?
> - Tool-chain configuration problems - platform-specific or otherwise ?
> - Needing to do a JDK build as well (JDK 9 and later) ?
> - Something else ?
>
> And having identified your pain point(s), what do you think would be a
> solution ?
>
> -phil.
>

Re: Innovation again (was Re: Text classes)

[Laurent Bourgès]

Dear all,

Chris mail motivated me to answer too.

*** For *your* situation, what is JavaFX, how do you want it to evolve and
what does it mean to you? ***


I am developping for 10 years scientific desktop apps with Java Swing  (+
Java Web Start).
As our users are mostly using linux & macOS, we only require JDK 6 !
(old linux distributions had only openjdk6 by default)

Of course we could switch our code base to jdk8 soon as user stats reports
that 90% have it.

Using JDK8 would let us adopt JavaFX lately ... for its nicer widgets & 3d
plots (star models) but we could also use third-party libs for 3d plots
(orson charts).

My main concern is about the future of Java Client (2d / JFX)...

For science, python is the main language so we are outsiders and users
complain about Java updates... if JavaFX is no more in the mood, we will
not adopt it in future  as our service is offered for 10 years min ...

Finally I invested a lot of my own time improving the OpenJDK/JFX AA
renderers (Marlin) and had the chance to work with Oracle gentle persons on
its integration in jdk9/10.
My own experience proves that good FOSS & external contributions have their
place in the OpenJDK projects.
Let's the community get more involved to contribute patches to these
projects.

The main issue is sustainability:
- who will maintain / review patches (only few people) ?
- what funding for the community (meeting, conference, travel costs) ?

Cheers,
Laurent


Maybe I really am "Robinson Crusoe"...


PS: I feel like the last jedi
(coding legacy AA software renderers while others use Gpu)

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

[Laurent Bourgès]

Hi Kevin,

Here is the updated patch providing MarlinFX-0.8.2 to OpenJFX-10 that
provides an efficient path clipper fixing the bug JDK-8184429:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-082-8184429.0/

It is up-to-date with jfx-dev / jdk forrest (10) and recent changes
from the Marlin 0.8.2 patch under review (2d).

Changes:
- (D)MarlinPrismUtils share lots of code from (D)MarlinRenderingEngine
to initialize clipping & Marlin Stroker / Filler pipelines
- It does not include the ClipShapeTest (2d) as it needs rewritting to
use JavaFX API.

PS: Use the Test class (from jbs bug) to see large performance gains

Cheers,
Laurent

2017-11-08 23:58 UTC+01:00, Kevin Rushforth :
> And once we are happy with the 2D webrev, it should be pretty
> straight-forward to review it for FX.
>
> -- Kevin
>
>
> Phil Race wrote:
>> 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.

Re: Build issues on Ubuntu 16.04, 17.10 and 18.04-daily inside Docker

[Laurent Bourgès]

ative/library/common/PosixPlatform.cpp:235:5:
> note: suggested alternative: 'Wait'
>  wait();
>  ^~~~
>  Wait
>
> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:
> In destructor 'JavaClass::~JavaClass()':
>
> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46:
> warning: throw will always call terminate() [-Wterminate]
>  throw JavaException(FEnv, _T("Error"));
>   ^
>
> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46:
> note: in C++11 destructors default to noexcept
>  FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':fxpackager:compileLinuxLibrary'.
> > Could not call NativeCompileTask.compile() on task
> ':fxpackager:compileLinuxLibrary'
>
> Details and complete build logs can be found at
> https://gitlab.com/krichter/openjfx-8u-dev-rt/pipelines/14781176. The
> build script `.gitlab-ci.yml` contains the commands used to build.
>
> -Kalle
>
>


-- 
-- 
Laurent Bourgès

Re: Font metrics in JavaFX Canvas

[Laurent Bourgès]

Hi David,

If I can help (dev / test / build / patch), I would love doing it on this
RFE... on my spare time as usual (best effort).

However I have no idea how text metrics are implemented in JavaFX.
Could anyone give us directions or draft ideas to do the job ourselves ?

Should we start a github repository to fix that issue with all interested
people ?

Cheers,
Laurent

Le 5 déc. 2017 13:54, "David Gilbert"  a écrit :

> Any feedback on this item?
>
> Best regards,
> David Gilbert
>
>
> > On 30 Nov 2017, at 08:26, David Gilbert  wrote:
> >
> > Hello,
> >
> > I have an open source project FXGraphics2D [1] that provides a
> Graphics2D API for the JavaFX canvas.  It is open source and used to
> provide JavaFX support for JFreeChart [2] and Orson Charts [3].  It can
> also be used more generally for any code that targets the Java2D API.
> >
> > One limitation that I’ve encountered is that there is no API to get font
> metrics for fonts rendered on the JavaFX canvas, so it is difficult to
> implement the method Graphics2D.getFontMetrics(Font f) accurately.  As a
> result, text alignment is difficult, for example see the tick labels on the
> vertical axis in this chart:
> >
> > http://www.jfree.org/jfreechart/fxgraphics2d-font-issue.png
> >
> > There is a feature request in the bug tracker, open for some time, that
> targets this particular feature.  I’d like to highlight it for (hopefully)
> some attention in a future JDK release:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8090775 <
> https://bugs.openjdk.java.net/browse/JDK-8090775>
> >
> > Best regards,
> >
> > David Gilbert
> >
> > [1] https://github.com/jfree/fxgraphics2d  fxgraphics2d>
> > [2] https://github.com/jfree/jfreechart-fx  jfreechart-fx>
> > [3] https://github.com/jfree/orson-charts-fx  orson-charts-fx>
>
>

Re: PLEASE READ: OpenJFX developer repos + JDK 10 RDP1 deadlines

[Laurent Bourgès]

Kevin,

To be sure, does it mean OpenJFX 10 changes are due to dec 14th ie for
JDK10 RDP1 ?

I would like to provide MarlinFX 0.8.2 for jfx10 but the remaining time is
short for the web review to happen... and the RFR Marlin 0.8.2 patch for
Java2d is submitted but no comment yet.

Should I submit an openjfx 10 patch for monday ?

Cheers,
Laurent

Le 28 nov. 2017 22:44, "Kevin Rushforth"  a
écrit :

> To: All OpenJFX developers
>
> There are two related items that you need to be aware of, so please read
> this if you are a developer of OpenJFX.
>
> Executive summary:
>
> 1. To match the JDK project, which has a persistent, non-release-specific
> mainline repo [1], the FX 10 and 10-dev repos will be "renamed" to jfx and
> jfx-dev. Starting Monday, Dec 4 all fixes for FX should be pushed to
> jfx-dev/rt rather than 10-dev/rt.
>
> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 [2].
> All bug fixes and RFEs planned for 10 should be pushed by that date. We
> will fork the repo at that time and only approved fixes will go into JDK 10
> after that point.
>
>
> Details:
>
> 1. Historically, the JDK has had separate development mainline repos for
> each code line, and the OpenJFX project has followed this pattern. Starting
> with JDK 10, development has switched to a model where the development
> branch is persistent (that is, it doesn't change when a new release is
> started) and is no longer release-specific. So there is a jdk project with
> a jdk mainline repo [1], and no longer a jdk10 mainline repo. We will start
> following this for the OpenJFX project, too.
>
> We will "effectively rename" the FX 10-dev (and 10 [master]) repos to
> jfx-dev (and jfx [master]). I use the term "effectively rename", because
> what we will actually do is clone a new jfx-dev repo from 10-dev and make
> 10-dev read-only. This is because we will shortly need a new forked repo
> for 10 stabilization, so it is easier to do this than delete and recreate
> it.
>
> The end result will be that for developers, the place you push fixes going
> forward will always be "jfx-dev/rt" rather than "10-dev/rt" and then
> "11-dev/rt" and then ...
>
> The planned timeline for the switchover is:
>
> Sunday, Dec 3
>
> * The openjfx 10-dev forest will be made read only at 8:00 pm Pacific time
> on Sunday. If you have a fix that you want in before Monday, then you need
> to push it no later than 7:59 pm (Pacific) Sunday night.
>
> * The jfx-dev forest will be cloned from 10-dev (and the jfx [master]
> forest will be cloned from 10 [master])
>
> Monday, Dec 4
>
> * Once this is done and tested, I will send out email announcing that it
> is open for pushing. I expect that this will happen early Monday morning
> (Pacific time). Once the repo is open, developers will need to edit their
> .hgrc files to point to the new jfx-dev forest instead of 10-dev.
>
>
> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 [2].
> All bug fixes and RFEs planned for 10 should be pushed by that date. We
> will fork the repo at that time; only approved fixes will go into JDK 10
> after that point. The guidelines are that only P1-P3 bugs will be
> considered for inclusion into JDK 10 during RDP1, and not all P3 bugs will
> be taken.  Generally developers focus on getting a fix into the mainline,
> and it will make the next available train. Once the 10 stabilization repo
> has forked, the next train will be 11.
>
> I expect that more guidance will be given on the jdk-dev mailing list as
> for the processes and policies surrounding this.
>
> -- Kevin
>
> [1] http://hg.openjdk.java.net/jdk/jdk/
>
> [2] http://openjdk.java.net/projects/jdk/10/
>
>

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: [10] RFR 8188062: Use Marlin renderer in JavaFX BasicStroke

[Laurent Bourgès]

Kevin & Phil,

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

Changes:
- wrapPath2d typo => wrapPath2D()
- whitespace / braces in (D)TransformingPathConsumer2D

As mentioned in my answer to Phil's review, I moved the CAP/JOIN constants
into BasicStroke (as in Java2D) as it is the public API (for me) instead of
importing them from renderer implementation (openpisces or Marlin).

Build OK on up-to-date OpenJFX10 + tested with MapBenchFX.

If that webrev is OK, please push it for me.


FYI the remaining OpenPisces references are listed below (and OpenPisces
can be easily removed in other OpenJFX release):
./src/main/java/com/sun/prism/impl/shape/ShapeUtil.java:new
com.sun.openpisces.Stroker(p2d, lw, stroke.getEndCap(),
./src/main/java/com/sun/prism/impl/shape/ShapeUtil.java:pc2d =
new com.sun.openpisces.Dasher(pc2d, stroke.getDashArray(),

./src/main/java/com/sun/prism/impl/shape/OpenPiscesPrismUtils.java:import
com.sun.openpisces.Dasher;
./src/main/java/com/sun/prism/impl/shape/OpenPiscesPrismUtils.java:import
com.sun.openpisces.Renderer;
./src/main/java/com/sun/prism/impl/shape/OpenPiscesPrismUtils.java:import
com.sun.openpisces.Stroker;
./src/main/java/com/sun/prism/impl/shape/OpenPiscesPrismUtils.java:import
com.sun.openpisces.TransformingPathConsumer2D;
./src/main/java/com/sun/prism/impl/shape/OpenPiscesRasterizer.java:import
com.sun.openpisces.AlphaConsumer;
./src/main/java/com/sun/prism/impl/shape/OpenPiscesRasterizer.java:import
com.sun.openpisces.Renderer;

./src/main/java/com/sun/prism/sw/SWContext.java:import
com.sun.openpisces.Renderer;

./src/main/java/com/sun/prism/sw/DirectRTPiscesAlphaConsumer.java:import
com.sun.openpisces.AlphaConsumer;
./src/main/java/com/sun/prism/sw/DirectRTPiscesAlphaConsumer.java:import
com.sun.openpisces.Renderer;

./src/main/java/com/sun/openpisces/Curve.java:package com.sun.openpisces;
./src/main/java/com/sun/openpisces/TransformingPathConsumer2D.java:package
com.sun.openpisces;
./src/main/java/com/sun/openpisces/Helpers.java:package com.sun.openpisces;
./src/main/java/com/sun/openpisces/Dasher.java:package com.sun.openpisces;
./src/main/java/com/sun/openpisces/Stroker.java:package com.sun.openpisces;
./src/main/java/com/sun/openpisces/Renderer.java:package com.sun.openpisces;
./src/main/java/com/sun/openpisces/AlphaConsumer.java:package
com.sun.openpisces;

./src/main/java/com/sun/marlin/MarlinAlphaConsumer.java:import
com.sun.openpisces.AlphaConsumer;

(the openpisces.AlphaConsumer interface should be kept and moved in another
package like marlin ?)

Cheers,
Laurent


2017-11-08 0:04 GMT+01:00 Kevin Rushforth <kevin.rushfo...@oracle.com>:

> I did a fairly quick review and ran tests on two platforms. It looks good
> to me. I have some minor formating nits:
>
> PathConsumer2D.java:
>
> 1. In the following:
>
> +public DPathConsumer2D wrapPath2d(Path2D p2d)
> +{
>
>
> the opening curly brace can go at the end of the method declaration (same
> pattern appears in a few other files)
>
>
> 2. Can you add a blank line before the Path2DWrapper class declaration?
>
> Other than that, as long as you address Phil's concerns it is OK to go in.
>
> Thanks.
>
> -- Kevin
>
>
> Laurent Bourgès wrote:
>
> Just a gentle reminder...
> Kevin, could you have a look ?
>
> I have other patches coming soon...
>
> Cheers,
> Laurent
>
> Le 27 oct. 2017 8:02 PM, "Laurent Bourgès" <bourges.laur...@gmail.com> a
> écrit :
>
>> Hi Phil,
>> Thanks for your comments.
>>
>> Le 27 oct. 2017 18:28, "Phil Race" <philip.r...@oracle.com> a écrit :
>>
>>   38 private final Path2DWrapperwp_Path2DWrapper= new 
>> Path2DWrapper();
>>
>> Are there tabs  here ? The formatting looks odd.
>>
>>
>> It is manually aligned with followings lines (only space).
>>
>>
>>   44 public DPathConsumer2D wrapPath2d(Path2D p2d)
>> The method naming pattern I see elsewhere is  "2D" not "2d" .. so can we fix 
>> this one ?
>> ie make it wrapPath2D
>> This occurs in at least two different files in this webrev: 
>> [D]TransformingPathConsumer2D.java
>>
>>
>> I agree and I can fix it here and also in Marlin2D (same code).
>>
>> I really don't like the changes in BasicStroke that not use direct literals 
>> instead of copying
>> the values from Stroker. It can't possibly help performance and you lose the 
>> implied relationship.
>>
>> I agree your point of view. However the reference or origin was the
>> public BasicStroke in 2d and Marlin checks that constants match in static
>> initializers (MarlinRenderingEngine).
>>
>> I prefer applying the

Re: [10] RFR 8188062: Use Marlin renderer in JavaFX BasicStroke

[Laurent Bourgès]

Just a gentle reminder...
Kevin, could you have a look ?

I have other patches coming soon...

Cheers,
Laurent

Le 27 oct. 2017 8:02 PM, "Laurent Bourgès" <bourges.laur...@gmail.com> a
écrit :

> Hi Phil,
> Thanks for your comments.
>
> Le 27 oct. 2017 18:28, "Phil Race" <philip.r...@oracle.com> a écrit :
>
>   38 private final Path2DWrapperwp_Path2DWrapper= new 
> Path2DWrapper();
>
> Are there tabs  here ? The formatting looks odd.
>
>
> It is manually aligned with followings lines (only space).
>
>
>   44 public DPathConsumer2D wrapPath2d(Path2D p2d)
> The method naming pattern I see elsewhere is  "2D" not "2d" .. so can we fix 
> this one ?
> ie make it wrapPath2D
> This occurs in at least two different files in this webrev: 
> [D]TransformingPathConsumer2D.java
>
> I agree and I can fix it here and also in Marlin2D (same code).
>
>
> I really don't like the changes in BasicStroke that not use direct literals 
> instead of copying
> the values from Stroker. It can't possibly help performance and you lose the 
> implied relationship.
>
> I agree your point of view. However the reference or origin was the public
> BasicStroke in 2d and Marlin checks that constants match in static
> initializers (MarlinRenderingEngine).
>
> I prefer applying the same pattern in FX so I did that change which
> removes the reference to OpenPisces.Stroker.
>
> -public static final int CAP_BUTT = Stroker.CAP_BUTT;-public static 
> final int CAP_ROUND = Stroker.CAP_ROUND;-public static final int 
> CAP_SQUARE = Stroker.CAP_SQUARE;--public static final int JOIN_BEVEL = 
> Stroker.JOIN_BEVEL;-public static final int JOIN_MITER = 
> Stroker.JOIN_MITER;-public static final int JOIN_ROUND = 
> Stroker.JOIN_ROUND;++/** Constant value for end cap style. */+public 
> static final int CAP_BUTT = 0;+/** Constant value for end cap style. */+  
>   public static final int CAP_ROUND = 1;+/** Constant value for end cap 
> style. */+public static final int CAP_SQUARE = 2;++/** Constant value 
> for join style. */+public static final int JOIN_MITER = 0;+/** 
> Constant value for join style. */+public static final int JOIN_ROUND = 
> 1;+/** Constant value for join style. */+public static final int 
> JOIN_BEVEL = 2;
>
>
> The next one is not something I think must be fixed but an observation that it
> seems odd to have to decide which Rasterizer to use every time some one calls 
> this
> API rather than making it a one time initialisation.
>
> I wondered the same question. As PrismSettings are constants, hotspot will
> optimize that code as a direct call to the proper method (dead code
> elimination).
>
> +public static Shape createCenteredStrokedShape(Shape s, BasicStroke 
> stroke)+{+if (PrismSettings.rasterizerSpec == 
> RasterizerType.DoubleMarlin) {+return 
> DMarlinRasterizer.createCenteredStrokedShape(s, stroke);+}+if 
> (PrismSettings.rasterizerSpec == RasterizerType.FloatMarlin) {+    
> return MarlinRasterizer.createCenteredStrokedShape(s, stroke);+}+ 
>// JavaPisces fallback:+return 
> createCenteredStrokedShapeOpenPisces(s, stroke);+}+
>
> Laurent
>
> -phil.
>
>
>
> On 10/25/2017 02:11 PM, Laurent Bourgès wrote:
>
> Please review this simple patch that moves the
> BasicStroke.createCenteredStrokedShape() implementation into ShapeUtil in
> order to use Marlin instead of OpenPisces:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8188062
> Webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8188062.0/
>
> Changes:
> - BasicStroke: fixed definition of CAP / JOIN constants +
> createCenteredStrokedShape() calls ShapeUtil createCenteredStrokedShape()
> (delegation)
> - ShapeUtil.createCenteredStrokedShape() delegates to (D)MarlinRasterizer
> (if enabled) or to OpenPisces (fallback)
> - (D)MarlinRasterizer: applied the same approach as in Marlin2D
> createStrokedShape() except I adopted the lineWidth trick as in OpenPisces
> - (D)MarlinPrismUtils: some refactoring to let the new strokeTo() method
> reuse the initPipeline() + simplified Path2D special handling
> - (D)RendererContext / (D)TransformingPathConsumer2D: added cached Path2D
> instance and Path2DWrapper (like in Marlin2D)
>
>
> PS: Removing OpenPisces in the future will be easier as remaining
> references are in ShapeUtil, OpenPiscesPrismUtils and few sw pipeline
> classes. Use the following command to get usages:
> find . -name "*.java" -exec grep -H "openpisces" {} \;)
>
> Cheers,
> Laurent
>
>
>
>

Re: [10] RFR 8188062: Use Marlin renderer in JavaFX BasicStroke

[Laurent Bourgès]

Hi Phil,
Thanks for your comments.

Le 27 oct. 2017 18:28, "Phil Race" <philip.r...@oracle.com> a écrit :

  38 private final Path2DWrapperwp_Path2DWrapper=
new Path2DWrapper();

Are there tabs  here ? The formatting looks odd.


It is manually aligned with followings lines (only space).


  44 public DPathConsumer2D wrapPath2d(Path2D p2d)
The method naming pattern I see elsewhere is  "2D" not "2d" .. so can
we fix this one ?
ie make it wrapPath2D
This occurs in at least two different files in this webrev:
[D]TransformingPathConsumer2D.java

I agree and I can fix it here and also in Marlin2D (same code).


I really don't like the changes in BasicStroke that not use direct
literals instead of copying
the values from Stroker. It can't possibly help performance and you
lose the implied relationship.

I agree your point of view. However the reference or origin was the public
BasicStroke in 2d and Marlin checks that constants match in static
initializers (MarlinRenderingEngine).

I prefer applying the same pattern in FX so I did that change which removes
the reference to OpenPisces.Stroker.

-public static final int CAP_BUTT = Stroker.CAP_BUTT;-public
static final int CAP_ROUND = Stroker.CAP_ROUND;-public static
final int CAP_SQUARE = Stroker.CAP_SQUARE;--public static final
int JOIN_BEVEL = Stroker.JOIN_BEVEL;-public static final int
JOIN_MITER = Stroker.JOIN_MITER;-public static final int
JOIN_ROUND = Stroker.JOIN_ROUND;++/** Constant value for end cap
style. */+public static final int CAP_BUTT = 0;+/** Constant
value for end cap style. */+public static final int CAP_ROUND =
1;+/** Constant value for end cap style. */+public static
final int CAP_SQUARE = 2;++/** Constant value for join style. */+
  public static final int JOIN_MITER = 0;+/** Constant value for
join style. */+public static final int JOIN_ROUND = 1;+/**
Constant value for join style. */+public static final int
JOIN_BEVEL = 2;


The next one is not something I think must be fixed but an observation that it
seems odd to have to decide which Rasterizer to use every time some
one calls this
API rather than making it a one time initialisation.

I wondered the same question. As PrismSettings are constants, hotspot will
optimize that code as a direct call to the proper method (dead code
elimination).

+public static Shape createCenteredStrokedShape(Shape s,
BasicStroke stroke)+{+if (PrismSettings.rasterizerSpec ==
RasterizerType.DoubleMarlin) {+return
DMarlinRasterizer.createCenteredStrokedShape(s, stroke);+}+
if (PrismSettings.rasterizerSpec == RasterizerType.FloatMarlin) {+
   return MarlinRasterizer.createCenteredStrokedShape(s,
stroke);+}+// JavaPisces fallback:+return
createCenteredStrokedShapeOpenPisces(s, stroke);+}+

Laurent

-phil.



On 10/25/2017 02:11 PM, Laurent Bourgès wrote:

Please review this simple patch that moves the
BasicStroke.createCenteredStrokedShape() implementation into ShapeUtil in
order to use Marlin instead of OpenPisces:

JBS: https://bugs.openjdk.java.net/browse/JDK-8188062
Webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8188062.0/

Changes:
- BasicStroke: fixed definition of CAP / JOIN constants +
createCenteredStrokedShape() calls ShapeUtil createCenteredStrokedShape()
(delegation)
- ShapeUtil.createCenteredStrokedShape() delegates to (D)MarlinRasterizer
(if enabled) or to OpenPisces (fallback)
- (D)MarlinRasterizer: applied the same approach as in Marlin2D
createStrokedShape() except I adopted the lineWidth trick as in OpenPisces
- (D)MarlinPrismUtils: some refactoring to let the new strokeTo() method
reuse the initPipeline() + simplified Path2D special handling
- (D)RendererContext / (D)TransformingPathConsumer2D: added cached Path2D
instance and Path2DWrapper (like in Marlin2D)


PS: Removing OpenPisces in the future will be easier as remaining
references are in ShapeUtil, OpenPiscesPrismUtils and few sw pipeline
classes. Use the following command to get usages:
find . -name "*.java" -exec grep -H "openpisces" {} \;)

Cheers,
Laurent

Re: Build JFX-10 on linux gcc 6

[Laurent Bourgès]

Hi Kevin,

As I deleted (by mistake) my former OpenJFX10, I was a bit lost !

2017-10-19 20:40 UTC+02:00, Kevin Rushforth :
> Hi Laurent,
>
> We don't have an easy way to suppress -Werror (no equivalent of JDK's
> --disable-warnings-as-errors configure option).
>
> For the short term, you can edit buildSrc/linux.gradle and remove the
> --Werror flags that are causing the problems.
>
> Can you file a bug to track fixing these warnings on gcc 6? Even though
> we still build our production bits using gcc 4.9.1 we don't want to stop
> someone from building on the latest compiler.

Thanks for your help, it reminded me what I did few months ago.

Here is the new bug: https://bugs.openjdk.java.net/browse/JDK-8189689

I also fixed the wait() calls for gcc-6 and the build is OK and it works !

Thanks,
Laurent

Build JFX-10 on linux gcc 6

[Laurent Bourgès]

Hi,

I cloned a fresh openjfx 10 and I got gradle build error with gcc 6 on my
ubuntu 17.4 as gcc warnings are considered as errors.

Sorry I forgot how to fix the gradle setting to avoid -Werror.

What is the trick ?

Laurent

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

JavaOne slides about Marlin/FX renderer

[Laurent Bourgès]

Hi,

Here are my final JavaOne slides about the Marlin & MarlinFX renderers:
https://github.com/bourgesl/bourgesl.github.io/raw/master/ja
vaone2017/slides/javaone-marlin-talk.pdf

You will also get links to my github repositories...

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

Cheers,
Laurent

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

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

[Laurent Bourgès]

Hi Jim,

I made good progress on my PathClipFilter that works now perfectly with
many test maps for the NZ rule (EO has artefacts if I enable the filter in
that case).

Here is the updated code below to illustrate the approach:
- use a new IndexStack in (D)Helpers to store only corner indexes (0/1 for
Top/Bottom Left, 2/3 for Top/Bottom Right)
- when the segment is out, I now check (L/R case) if the segment ends have
different outcodes to insert needed corners that can be removed later if a
segment does the same in the reverse order (same repeated corner is
cancelled out): see IndexStack.push(int)

- PathClipFilter:

static final class PathClipFilter implements DPathConsumer2D {

private DPathConsumer2D out;

// Bounds of the drawing region, at pixel precision.
private final double[] clipRect;

private final double[] corners = new double[8];
private boolean init_corners = false;

private final IndexStack stack;

// the outcode of the starting point
private int sOutCode = 0;

// the current outcode of the current sub path
private int cOutCode = 0;

private boolean outside = false;
private double cx0, cy0;

PathClipFilter(final DRendererContext rdrCtx) {
this.clipRect = rdrCtx.clipRect;
this.stack = (rdrCtx.stats != null) ?
new IndexStack(rdrCtx,
rdrCtx.stats.stat_pcf_idxstack_indices,
rdrCtx.stats.hist_pcf_idxstack_indices,
rdrCtx.stats.stat_array_pcf_idxstack_indices)
: new IndexStack(rdrCtx);
}

PathClipFilter init(final DPathConsumer2D out) {
this.out = out;

// Adjust the clipping rectangle with the renderer offsets
final double rdrOffX = DRenderer.RDR_OFFSET_X;
final double rdrOffY = DRenderer.RDR_OFFSET_Y;

// add a small rounding error:
final double margin = 1e-3d;

final double[] _clipRect = this.clipRect;
_clipRect[0] -= margin - rdrOffY;
_clipRect[1] += margin + rdrOffY;
_clipRect[2] -= margin - rdrOffX;
_clipRect[3] += margin + rdrOffX;

init_corners = true;

return this; // fluent API
}

/**
 * Disposes this instance:
 * clean up before reusing this instance
 */
void dispose() {
stack.dispose();
}

@Override
public void pathDone() {
out.pathDone();

// TODO: fix possible leak if exception happened
// Dispose this instance:
dispose();
}

@Override
public void closePath() {
if (outside) {
this.outside = false;

if (sOutCode == 0) {
finish();
} else {
stack.reset();
}
}
out.closePath();
this.cOutCode = sOutCode;
}

private void finish() {
if (!stack.isEmpty()) {
if (init_corners) {
init_corners = false;
// Top Left (0):
corners[0] = clipRect[2];
corners[1] = clipRect[0];
// Bottom Left (1):
corners[2] = clipRect[2];
corners[3] = clipRect[1];
// Top right (2):
corners[4] = clipRect[3];
corners[5] = clipRect[0];
// Bottom Right (3):
corners[6] = clipRect[3];
corners[7] = clipRect[1];
}
stack.pullAll(corners, out);
}
out.lineTo(cx0, cy0);
}

@Override
public void moveTo(final double x0, final double y0) {
final int outcode = DHelpers.outcode(x0, y0, clipRect);
this.sOutCode = outcode;
this.cOutCode = outcode;
this.outside = false;
out.moveTo(x0, y0);
}

@Override
public void lineTo(final double xe, final double ye) {
final int outcode0 = this.cOutCode;
final int outcode1 = DHelpers.outcode(xe, ye, clipRect);
this.cOutCode = outcode1;

final int sideCode = (outcode0 & outcode1);

// basic rejection criteria:
if (sideCode != 0) {
// keep last point coordinate before entering the clip
again:
this.outside = true;
this.cx0 = xe;
this.cy0 = ye;

clip(sideCode, outcode0, outcode1);
return;
}
if (outside) {
this.outside = false;
finish();
}
// clipping disabled:
out.lineTo(xe, ye);
}

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

[Laurent Bourgès]

de stack (throw if never enter
again ?)
this.cx0 = x3;
this.cy0 = y3;
return;
} else {
// corner or cross-boundary
// TODO: add to outside stack (throw if never enter
again ?)
//line(P0-P1)

finish();
// clipping disabled:
out.lineTo(x3, y3);
return;
}
}
finish();
// clipping disabled:
out.curveTo(x1, y1, x2, y2, x3, y3);
}

@Override
public void quadTo(final double x1, final double y1,
   final double x2, final double y2)
{
final int outcode0 = this.cOutCode;
final int outcode2 = DHelpers.outcode(x2, y2, clipRect);
this.cOutCode = outcode2;

// TODO: optimize ?
final int outcode1 = DHelpers.outcode(x1, y1, clipRect);

// basic rejection criteria
if ((outcode0 & outcode1 & outcode2) != 0) {
// Different quadrant ?
if ((outcode0 == outcode2) && (outcode0 == outcode1)) {
// corner or cross-boundary
this.outside = true;
// TODO: add to outside stack (throw if never enter
again ?)
this.cx0 = x2;
this.cy0 = y2;
return;
} else {
// corner or cross-boundary
// TODO: add to outside stack (throw if never enter
again ?)
//line(P0-P1)

finish();
// clipping disabled:
out.lineTo(x2, y2);
return;
}
}
finish();
// clipping disabled:
out.quadTo(x1, y1, x2, y2);
}

@Override
public long getNativeConsumer() {
throw new InternalError("Not using a native peer");
}
}

Here is a screenshot illustrating the remaining paths in Renderer after
clipping a 4000x4000 spiral converted as stroked shape:
http://cr.openjdk.java.net/~lbourges/png/SpiralTest-dash-false.ser.png

You can see all rounds arround the clip that I expect soon to ignore too as
I plan to use a corner stack to remember turining points until the path
enters again or go back in reverse order...

clip off: ~ 145ms
clip on: ~ 106ms

TODO: handle corner points & turns arround / reverse the clip

Cheers,
Laurent


2017-09-01 22:09 GMT+02:00 Laurent Bourgès <bourges.laur...@gmail.com>:

> Dear Jim,
>
> I am not so good at explaining my early solution for NZ rule in english:
> - it mimics the Stroker approach
> - it skips all intermediate segments outside (except at corners ie
> different outcodes)
> - preserve only the last point of the entering segment
>
> So mostly invisible segments on the left and right sides are skipped from
> the original that makes the Renderer only processing visible segments like
> in the Stroker case where I opened the path.
>
> It improves the performance as less left / right segments are processed in
> addLine(). For now the Renderer accepts all segments and only rejects
> top/bottom parts and keeps all left/right edges in its processing: that
> costs a lot.
>
>
> I think we are discussing two different things.  I thought you were
> considering a separate filter for clipping filled only paths.  I agree that
> the Stroker webrev is still needed for stroked paths.  We should also
> create one for dashed paths that will clip before dashing.  There are
> multiple stages at which we can clip to reduce processing.
>
>
> Exactly I also like the pipeline approach that decouples stages into
> different parts.
>
>
> I take that case into account.  How is a prefilter that excludes those
> segments any simpler than the Renderer rejecting them itself?
>
> Keep in mind that they are already rejected.  Renderer.addLine() already
> does this.  In the case of a polygon, there isn't much code you can reduce
> because it goes from the loop that feeds the path in the rendering engine
> directly to Renderer.move/lineTo() which goes directly to addLine() which
> rejects all of those segments.
>
>
> Not on the left / right side.
> Closed subpaths or extra segments can be ignored for NZ rule = only
> keeping the path closed properly matters.
>
> Will send you the current code to illustrate the basic filter asap.
>
>
> In the case of curves, the path is nearly as direct, but first you run a
> DDA on it to break it into lines.  Simply modifying Renderer.quadTo and
> cubicTo to perform quick-rejection would be a very simple change (certainly
> simpler than adding a new class to do that) and would reject all of those
> curved segments much faster...
>
>
> Agreed, I have done it in the past and can provide the change.
>
> Laurent
>
>


-- 
-- 
Laurent Bourgès

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

[Laurent Bourgès]

at the path filtering will be
done twice or that Stroker should indicate to not filter twice the segments
!

>
> So, in the end, I don't see any situation - including any calculation that
> you think could help reject pieces faster - that would be better served as
> a filter run ahead of Renderer that can't be more optimally done by adding
> code to the Renderer and simply dropping pieces on the floor...?
>

I already tried to explain an interesting case: closed subpaths on the left
or right sides are bringing lots of edges into the Renderer bag that cost a
lot due to the scanline processing (crossing inc, sort, spans ...).
I prefer coding an external simplifier compatible with Renderer, than
complexifying the Renderer itself to record subpaths, test outcodes that
would add more complexity, code lines...


>
> On 8/31/17 1:34 PM, Laurent Bourgès wrote:
>
>> Another case: you provided a Test class using a path made with 1 line
>> segments on the left side. If it is converted by createStrokedShape(), then
>> the Renderer will again deal with thousands crossings and it will be slow
>> again.
>>
>
> Such a case will already be handled by the clipping in the Stroker, though
> - work that you've already done in these webrevs.
>

Yes that works well with Stroker.
As I explained such huge polyline can be converted to a polygon by calling
createStrokedShape() and then rendered by fill(shape):
- unclipped: 300ms
- (experimental) clipped path: 4ms (twice slower than Stroker as there is
twice more segments as the shape was completely stroked)


> For the Even-odd filling rule, I think it needs exact segment
>> intersections on the left side, so I am focused on the Non-zero filling
>> rule for now.
>>
>
> They are identical.  All that matters is that you have the proper starting
> winding count as you enter the clip from the left.  They could be replaced
> by either a segment with the same "Y range" as I mention above, or they
> could be replaced by having a value in the segments list that is "starting
> count", so if you have a segment that is out-left and it goes from Y=10 to
> Y=20, you simply add (or subtract for reversed lines) one to the "starting
> count" field for all scanlines from 10->20.
>

I am still very skeptic with EO rule as I am not sure it was equivalent as
shapes can have self intersections ... or curve / line intersections on the
left side that could lead to different accumulated count.

After reading several times your explanations, I understand that on the
left side (outside):
- curves / quads  can be simplified to a simple line (P0 to P3), but what
about intersections in the middle of the curves ? should the Y range be set
to min(curveY), max(curveY) that is not easy to solve ...
- quad/curve/line segments can not be skipped with the EO rule to preserve
the Y ranges properly. Am I right ?

Maybe your later approach is interesting to introduce a new starting_counts
array along the Y axis to increment / decrement and then it would be
possible to totally ignore invisible segments on the left side ?



> Finally I tried two approach:
>> - basic subpath outside test (derived from the ClosedPathDetector) to
>> ignore closed sub-paths outside of the clip.
>> - more general clipper that follows the path, detect enter/exit the clip
>> but it needs to insert/remove corner points. I am improving this latter
>> approach.
>>
>
> Consider that your filter that works ahead of the Renderer will need to
> deal with the following issues:
>
> - detecting if the segments are out-top/bottom/right and drop them
> - A filter will then need to worry how to connect those paths back to
> the rest
> - Renderer can just drop them, end of story
>

On right side, Renderer need a 'closing' span edge.


> - detecting if the segments are out-left and manage the winding counts
> - A filter will need to manage that plus it will have to connect the
> paths
> - Renderer can just do addLine() or adjust "scanline-starting-count",
> end of story
>

But addLine() is the origin of the performance issue = extra cost of
processing extra crossings !


> - worrying about paths that loop around the entire clip, perhaps winding
> several times around the clip before they dive back into the clip rectangle
> - A filter has to construct a meaningful path to represent that same
> outcome
> - Renderer just discards all pieces that aren't out-left and
>   just manages the "starting count" for just the out-left parts
>

Thanks for the filter specifications I am working on.
I will find a compromise between rejecting segments and preserving accuracy
while providing better performance for the NZ rule as EO seems too
complicated to me (later ?).


2017-09-01 

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

[Laurent Bourgès]

Hi Jim,

I am answering your first message:

Area is overkill for this as it tries to find exact intersection points of
arbitrary geometry.   You simply need something that will trace accurately
around the outside of a clip to get from an exit point back to an entry
point. That is a much simpler operation.


OK, I started such approach but as it skips segments on the left side, it
will not preserve crossing counts for the even-odd winding rule, I suppose.

The key point is to reduce the edges / crossings processed by the Renderer
in the left and right sides of the clip at every scanlines.
For example, it will be worth when rendering a large text as a transformed
shapes as many letter (closed paths) will be out the L/R sides...
Top/Bottom clipping in Renderer already ignores such edges (except for
curves).

Moreover I agree Marlin does not need a proper path clipper (intersections)
but just needs skipping useless segments like a path simplifier as I did in
the Stroker.

Another case: you provided a Test class using a path made with 1 line
segments on the left side. If it is converted by createStrokedShape(), then
the Renderer will again deal with thousands crossings and it will be slow
again.

Also, I thought that the Renderer already did basic clipping along the
lines that you indicate.  It does that on a per-segment basis, but all it
would take is a simple test at the top of quadTo() and curveTo() to
completely reject all curves that lie outside the fill region (and simply
shadow any part that is entirely to the left so that we maintain the proper
crossings count)...


Agreed but closed subpaths can also be ignored on either left or right
sides like circles, letters...
What do you mean by shadow any part on the left ?

For the Even-odd filling rule, I think it needs exact segment intersections
on the left side, so I am focused on the Non-zero filling rule for now.

Finally I tried two approach:
- basic subpath outside test (derived from the ClosedPathDetector) to
ignore closed sub-paths outside of the clip.
- more general clipper that follows the path, detect enter/exit the clip
but it needs to insert/remove corner points. I am improving this latter
approach.

Thanks for your advices,
Laurent

Re: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

[Laurent Bourgès]

Jim,

FYI I am working on a more general clipper for filled shapes (only non zero
winding rule) that ignores useless segments on left / right sides but
leaves the path closed for filling primitives.

It is more tricky... to handle turning points (corners) but I think it
could be applied later to the Stroker case to avoid opening the path (and
require ClosedPathDetector).

Should I look at the Area class that performs such clipping but is known to
be extremely slow ? If you think it is useful, I could optimize it as I did
in Marlin (array caching...). What is your opinion ? Is Area used in the
java2d pipeline ? That would improve the overall performance.

PS: I wonder if curves should be subdivided at inflexion / root points in
this (too) basic fill pipeline to improve cubic / quad accuracy (as it is
the case in Stroker) and have monotonic curves.
I studied AFD accuracy (inc/dec thresholds) but did not try curve
subdivision to guarantee the special point accuracy (cups...)

Hope you will have time soon to look at the webrev, your feedback may help
a lot.

Cheers,
Laurent

Le 29 août 2017 2:58 AM, "Jim Graham" <james.gra...@oracle.com> a écrit :

Hi Laurent,


On 8/28/17 2:09 PM, Laurent Bourgès wrote:

> Hi Jim,
>
> Thanks for your comments, it helped refining the webrev.
>
> Here are my answers:
>
> 2017-08-26 2:22 GMT+02:00 Jim Graham <james.gra...@oracle.com  james.gra...@oracle.com>>:
>
>
> [D]Dasher.java - why the changes from (firstSegIdx > 0) to
> (firstSegIdx != 0)?
>
> As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx!= 0) as
> it looks more obvious.
>
> For me, (firstSegIdx > 0) indicates that the sign has a particular meaning
> and that firstSegIdxmay be negative.
>

Interesting, I'm used to != 0 being only used in contexts where the value
might have some specific reason for being negative, but I can see why you
did that.


[D]Stroker.java, line 196ish - why are ROUND treated differently.  You
> have a question on that as well in a comment.
>
> I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control
> points (cubics) to approximate a circle. I fixed the constant estimation
> according to the math formula.
>

The control points don't control how far the path gets from the line,
though - that measurement is arbitrary compared to the clipping operation.
The correct distance from the vertex to the edge of the drawn path is lw/2.


I agree your new rules.
> I fixed the (D)Stroker init() methods according the latter rules and
> tested again.
>

Looks good.


Probably I should write a new Clip test rendering Z shapes with all  (cap /
> join) combinations and their bounds aligned to the Stroker's outside clip
> rules.
>
> Here is an updated webrev (Marlin2D only):
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/
>
> PS: I can send you an updated MarlinFX patch (when you need it).
>

Not yet until I've had a chance to review the guts of the algorithm.  So
far I've only looked at a few boundary changes.  I'll get to that soon...

...jim

Re: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

[Laurent Bourgès]

Hi Jim,

Thanks for your comments, it helped refining the webrev.

Here are my answers:

2017-08-26 2:22 GMT+02:00 Jim Graham <james.gra...@oracle.com>:

> [D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx !=
> 0)?
>

As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx != 0) as
it looks more obvious.
For me, (firstSegIdx > 0) indicates that the sign has a particular meaning
and that firstSegIdx may be negative.


> [D]Dasher.java - why is there a new goto_starting() which is only used
> from one place?  To be able to add final to the parameters?
>

For inlining purposes, the JITWatch jarscan tool reported that this
(hotspot) method is larger than 325 byte codes so I wanted to split it in
smaller parts.


> [D]Dasher.java, line 268ish - why move the call to out.moveto() down a
> line?
>

To set the needsMoveTo flag just below the condition: if (needsMoveTo) {
needsMoveTo = false; ...}


> [D]Stroker.java, line 170ish - you added final to the float params, but
> not the double
>

Fixed. I also fixed all (D)PathConsumer2D methods overriden in Dasher,
Stroker & Renderer.


> [D]Stroker.java, line 196ish - why are ROUND treated differently.  You
> have a question on that as well in a comment.
>

I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control
points (cubics) to approximate a circle. I fixed the constant estimation
according to the math formula.


> [D]Stroker.java, line 196ish - CAP_SQUARE would require more than lw/2
> padding.  I think it needs lw*sqrt(2)/2 padding.
>

Exactly, good point !

I would think the padding would be (max of the CAP/JOIN values below):
> CAP_BUTT - lw/2
> CAP_ROUND - lw/2
> CAP_SQUARE - lw/2 * sqrt(2)
> JOIN_BEVEL - lw/2
> JOIN_ROUND - lw/2
> JOIN_MITER - max(lw/2, miter_limit * lw)
>
> In other words:
> - lw/2 by default
> - if CAP_SQUARE then multiply that by sqrt(2)
> - if JOIN_MITER then max it with limit
>

I agree your new rules.
I fixed the (D)Stroker init() methods according the latter rules and tested
again.

Probably I should write a new Clip test rendering Z shapes with all  (cap /
join) combinations and their bounds aligned to the Stroker's outside clip
rules.

Here is an updated webrev (Marlin2D only):
http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/


PS: I can send you an updated MarlinFX patch (when you need it).

Cheers,
Laurent



> I'm still looking through the management of the closed path detection
> coordinates, but I thought I'd get at least these questions out first
> before the weekend...
>
> ...jim
>
> On 8/25/17 1:09 PM, Laurent Bourgès wrote:
>
>> Hi,
>>
>> Please review Marlin/FX upgrades that provide an efficient path clipper in
>> Stroker (float / double variants) fixing the bug JDK-8184429
>> <https://bugs.openjdk.java.net/browse/JDK-8184429>
>>
>>
>> Marlin2D patch (jdk10):
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.0/
>> MarlinFX patch (openjfx10):
>> http://cr.openjdk.java.net/~lbourges/marlinFX/marlin-080.0/
>>
>> Path Clipper in (D)Stroker:
>> - it uses outcode computation (cohen - sutherland) for segment edges (2
>> for
>> lines, 3 for quads, 4 for cubics)
>> - it opens the path when a segment is invisible ie special moveTo() and
>> ignore invisible joins; it does not compute any intersection (line /
>> curve), it just skips useless segment for better performance and accuracy
>> - the ClosedPathDetector is needed to infer if the path is closed or not
>> (call to closePath) to produce caps when appropriate. It reuses the former
>> PolyStack (moved into Helper classes) to store the forward segments
>> - the clip rectangle is adjusted either in Stroker but also in
>> Transformer2D to take into account the mitter limit, stroker width and
>> also
>> the Renderer offset
>>
>> That's why it can not be applied to closed paths (fill operations) as the
>> path must remain closed in such case (concave polygon).
>> This could be implemented later as it needs to insert corner points when
>> needed to avoid artefacts; so the algorithm seem more complicated to me.
>>
>> Marlin2D / FX Patches are slightly different to handle the Renderer
>> offsets.
>>
>> I tested these patches against my MapBench test with a small clip and
>> several affine transforms: it does not produce any artefact (0 pixel
>> difference between clip=true/false)
>>
>> PS: I also improved the accuracy of Renderer's AFD by using the kaham
>> compensated-sum approach (later patch)
>>
>> Cheers,
>> Laurent Bourgès
>>
>>


-- 
-- 
Laurent Bourgès

[10] RFR 8180449: Upgrade the Marlin renderer in JavaFX

[Laurent Bourgès]

Please review this MarlinFX upgrade, following recent changes in Marlin2D
to synchronize Marlin 0.7.5 with OpenJDK & OpenJDK:

JBS: https://bugs.openjdk.java.net/browse/JDK-8180449
(last) webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/

Changes:
- Renderer (4 variants): use shared memory among AA and NonAA renderer
- Renderers: fixed block processing
- dead code & few comment removals in Strokers
- added quality settings (cubic/quad)
- fixed all floating-point number literals to be x.0f or x.0d to simplifythe
conversion between float & double variants
- many syntax & comment fixes

This issue was discussed in the following threads:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-April/020466.html
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-May/020554.html

Cheers,
Laurent

[10] RFR

[Laurent Bourgès]

Please review this MarlinFX upgrade, following recent changes in Marlin2D
to synchronize Marlin 0.7.5 with OpenJDK & OpenJDK:

JBS: https://bugs.openjdk.java.net/browse/JDK-8180449
(last) webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/

Changes:
- Renderer (4 variants): use shared memory among AA and NonAA renderer
- Renderers: fixed block processing
- dead code & few comment removals in Strokers
- added quality settings (cubic/quad)
- fixed all floating-point number literals to be x.0f or x.0d to simplifythe
conversion between float & double variants
- many syntax & comment fixes

This issue was discussed in the following threads:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-April/020466.html
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-May/020554.html

Cheers,
Laurent

Re: MarlinFX upgrade 0.7.5

[Laurent Bourgès]

One more comment about '(D)RendererSharedMemory in FX, but not 2D':

This reduces the memory footprint of the RendererContext among Renderer and
RendererNoAA implementations (shared arrays) that can co-exist at runtime
if both AA and NonAA rendering is needed.

As this behavior is unique to JavaFX, I wonder if it is worth to backport
this small difference in Marlin2D where there will be no gain.

Laurent


2017-05-16 23:11 GMT+02:00 Laurent Bourgès <bourges.laur...@gmail.com>:

> Hi Jim,
>
> I didn't notice anything functionally wrong with reviewing the webrev.
>> I'm going to do some basic testing on it now while you create a JBS bug for
>> it and submit for a formal review.  But I did notice some discrepancies by
>> diffing the sources against each other which it would be nice to know if
>> they were oversights or "future work".  If there is something you think
>> should be addressed now, do that in the process of switching to a formal
>> review (with JBS #) on it...
>>
>
> I will create the JBS bug asap.
>
>
>> I did a bit of diffing:
>>
>> - Marlin2D against MarlinFX
>> - *NoAA against the AA versions
>>
>> and noticed:
>>
>
> Thanks for your carefull analysis, here are my comments below:
>
> - RendererNoAA and DRendererNoAA line 38 are missing a "d" suffix.
>> - RendererNoAA and DRendererNoAA lines 61,90 - missing comment about test
>>
>
> I forgot to synchronize recent changes into RendererNoAA variants: good
> catch !
>
>
>> - Helpers and DHelpers - some adjustment of "pts[ off+1 ]" lines that
>> didn't happen in 2D
>>
>
> I decided to revert those minor syntax changes.
>
>
>> - Configurable constants for Inc/Dec/Quad/Cubic in 2D, but not FX
>>
>
> I hesitated but decided to backport the support for these configurable
> constants in all (D)Renderer(NoAA) (4 variants)
>
>
>> - DRendererSharedMemory in FX, but not 2D
>>
>
>
>> - FloatMath.ceil_f deleted from FX, but not 2D (not used in 2D)
>> - (FloatMath.floor_f is also only in 2D, but it is used in
>> MarlinRenderingEngine)
>>
>
> I decided to leave those FloatMath differences as Marlin2D (and FloatMath
> Tests) do use these methods.
>
>
> Finally I propose another MarlinFX webrev:
> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/
>
> Changes:
> - (D)Helpers: revert syntax changed in cubicRootsInAB() + fixed comment in
> subdivide()
> - (D)MarlinRenderingEngine: added logs for cubic/quad properties
> - (D)Renderer and (D)RendererNoAA: use cubic/quad properties like Marlin2D
> - (D)RendererNoAA: fixed syntax changes mentioned: missing "d" suffix +
> comment about test
> - MarlinProperties: added quality settings (cubic/quad)
>
>
> PS: I will send an updated webrev for the Marlin2D patch.
>
>
> Regards,
> Laurent
>



-- 
-- 
Laurent Bourgès

Re: MarlinFX upgrade 0.7.5

[Laurent Bourgès]

Hi Jim,

I didn't notice anything functionally wrong with reviewing the webrev.  I'm
> going to do some basic testing on it now while you create a JBS bug for it
> and submit for a formal review.  But I did notice some discrepancies by
> diffing the sources against each other which it would be nice to know if
> they were oversights or "future work".  If there is something you think
> should be addressed now, do that in the process of switching to a formal
> review (with JBS #) on it...
>

I will create the JBS bug asap.


> I did a bit of diffing:
>
> - Marlin2D against MarlinFX
> - *NoAA against the AA versions
>
> and noticed:
>

Thanks for your carefull analysis, here are my comments below:

- RendererNoAA and DRendererNoAA line 38 are missing a "d" suffix.
> - RendererNoAA and DRendererNoAA lines 61,90 - missing comment about test
>

I forgot to synchronize recent changes into RendererNoAA variants: good
catch !


> - Helpers and DHelpers - some adjustment of "pts[ off+1 ]" lines that
> didn't happen in 2D
>

I decided to revert those minor syntax changes.


> - Configurable constants for Inc/Dec/Quad/Cubic in 2D, but not FX
>

I hesitated but decided to backport the support for these configurable
constants in all (D)Renderer(NoAA) (4 variants)


> - DRendererSharedMemory in FX, but not 2D
>


> - FloatMath.ceil_f deleted from FX, but not 2D (not used in 2D)
> - (FloatMath.floor_f is also only in 2D, but it is used in
> MarlinRenderingEngine)
>

I decided to leave those FloatMath differences as Marlin2D (and FloatMath
Tests) do use these methods.


Finally I propose another MarlinFX webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/

Changes:
- (D)Helpers: revert syntax changed in cubicRootsInAB() + fixed comment in
subdivide()
- (D)MarlinRenderingEngine: added logs for cubic/quad properties
- (D)Renderer and (D)RendererNoAA: use cubic/quad properties like Marlin2D
- (D)RendererNoAA: fixed syntax changes mentioned: missing "d" suffix +
comment about test
- MarlinProperties: added quality settings (cubic/quad)


PS: I will send an updated webrev for the Marlin2D patch.


Regards,
Laurent

Re: MarlinFX upgrade 0.7.5

[Laurent Bourgès]

Hi Jim,

Please review this updated webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.1/

I mainly synchronized again all my Marlin repositories and this provides an
up-to-date patch in synch with Marlin2D.

Changes:
- Renderer (4 variants): use shared memory among AA and NonAA renderer
- Fixed comments in Helpers, XXXArrayCache
- Marlin2D backports in ArrayCacheConst, Renderer ...
- SWUtils: remove import + JavaShapeRenderer made static
- fixed copyright year to 2017

You can see the incremental changes by comparing the openjfx10.patch:
diff marlinFX-075.0/openjfx10.patch marlinFX-075.1/openjfx10.patch

Regards,
Laurent


2017-04-26 7:06 GMT+02:00 Jim Graham <james.gra...@oracle.com>:

> I've reviewed the code and run a number of tests.  Things look fine.
>
> I spotted at least one thing that I brought up in the 2D Marlin review,
> but since the 2 source bases are moving towards synchronizing with each
> other I didn't look too closely since many of the changes in the 2D Marlin
> update are things that are already "fixed" in this FX Marlin code, so I
> thought I would focus my scrutiny more on the 2D review instead. Would this
> code base be affected by the review comments I made there?  Did you want to
> hold both until they both are ready to go in and then push them at the same
> time (to keep them in sync)?
>
> Minimally, it is time to file a bug against FX for this...
>
>         ...jim
>
>
> On 4/19/17 11:35 PM, Laurent Bourgès wrote:
>
>> Hi,
>>
>> Please review this MarlinFX upgrade to Marlin 0.7.5:
>>
>> JBS: no bug yet for OpenJFX 10
>> webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/
>>
>> Changes:
>> - Renderers: fixed block processing
>> - dead code & few comment removals in Strokers
>> - fixed all floating-point number literals to be x.0f or x.0d to simplify
>> the conversion between float & double variants
>>
>> PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools
>> to fix any warning
>>
>> Cheers,
>> Laurent
>>
>>


-- 
-- 
Laurent Bourgès

MarlinFX upgrade 0.7.5

[Laurent Bourgès]

Hi,

Please review this MarlinFX upgrade to Marlin 0.7.5:

JBS: no bug yet for OpenJFX 10
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/

Changes:
- Renderers: fixed block processing
- dead code & few comment removals in Strokers
- fixed all floating-point number literals to be x.0f or x.0d to simplify
the conversion between float & double variants

PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools
to fix any warning

Cheers,
Laurent

[10] RFR 8170024: PiscesRenderer.pr.emitAndClearAlphaRow cannot accept a pix_x_from parameter greater than clip.xmin

[Laurent Bourgès]

Please review this performance enhancement for OpenJFX 10 / Marlin:

JBS: https://bugs.openjdk.java.net/browse/JDK-8170024
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170024.0/

The performance impact is small but may be more important for large shapes
(left-side is 'empty) but anyway this patch only impacts the SW pipeline.

Changes:
- added a new method parameter pix_x_off to
PiscesRenderer.emitAndClearAlphaRow() giving the offset (in pixels) within
the alpha row + bound checks (for consistency)
-
*modified JPiscesRenderer to alter the initial alpha buffer pointer; the C
blit functions seems to support well the 'trick'*

*- use the new parameter in SWContext to make MarlinFX only process the
alphaRow in the range [pix_from; pix_to[ (as initially made for)*

Cheers,
Laurent

Re: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer

[Laurent Bourgès]

Jim,

It looks good to me (even I am not an official reviewer) and the Marlin
Double-precision will be the default rasterizer.

Bye,
Laurent

Le 14 avr. 2017 22:32, "Jim Graham"  a écrit :

> JBS: https://bugs.openjdk.java.net/browse/JDK-8177985
> webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/
>
> The only way to get one of the old Pisces rasterizers now is to manually
> disable Marlin (or use the new order option as follows).
>
> This fix also introduces a similar pattern for rasterizer selection that
> we use for pipeline selection:
>
> -Dprism.rasterizerorder=listof(
> marlin|marlinfloat|marlindouble|
> pisces|javapisces|nativepisces|
> *)
> (unknown values are ignored for future/backwards-proofing)
>
> Suggestions for naming of the new rasterizer identifiers and the "public
> name" strings are welcome...
>
> ...jim
>

[9] Review request: JDK-8170030 Code in Marlin-based rasterizers may have an off-by-1 bug

[Laurent Bourgès]

Please review this simple fix for MarlinFX:

JBS: https://bugs.openjdk.java.net/browse/JDK-8170030
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170030.0/

PS: I will provide asap a Marlin2D patch incorporating changes made in
MarlinFX (including this one)

Cheers,
Laurent

Re: Planning for JavaFX.next

[Laurent Bourgès]

Hi,

I would like to promote performance & quality improvements on the
rasterizer that I could do in jdk10 within a tiger team focused on fx
rendering:

- multithreaded rendering (Marlin is thread-safe) ie the javafx could do
parallel rendering of layers or shapes
- software rasterizers: optimize inner / outer strokes, clipping in
particular for dashes, intersection of curves with scanlines (integer maths)
- rendering quality: use exact pixel coverage (agg approach), gamma
corrected blending
- in general: optimize array/buffer copies and memory allocations in the
complete javafx stack (jvmstat + profiling)
- use value types and more generally, enjoy vahalla, panama integration to
improve java and c code in the rendering pipeline
- gpu / shader upgrade ?

Finally all these items represent an important workload that need both
Oracle and OSS contributors = manpower.
The main issue consists in building a team with new contributors. Maybe
some Oracle or OpenJDK sponsorship is needed to fund such team ie donate
some money for some contributions... at least to organise meetings.

Let me cite the GNU philosophy:
 Thus, “free software” is a matter of liberty, not price. To understand the
concept, you should think of “free” as in “free speech,” not as in “free
beer”.

Cheers,
Laurent

[9] Review request: JDK-8170879 Fix Quad / Cubic BND constants for Marlin (FX)

[Laurent Bourgès]

Please review this simple fix for MarlinFX:

JBS: https://bugs.openjdk.java.net/browse/JDK-8170879
webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170879.0/

As mentioned in JBS, I studied both quality & performance and MarlinFX is
now slightly better than openpisces (1.6 vs 2.1 avg px).

I added attachements in JBS providing updated test classes (bug fix)


"
This simple fix changes MarlinFX renderers:
- use QUAD_DEC_BND=0.5 pixel
- cleaned up comments about both CUBIC / QUAD BND that are really related
to 2nd derivative (so expressed subpixels)
- modified the subdivision condition to use the manhattan norm |ddx| +
|ddy| instead of max( |ddx| , |ddy| ) to improve the average bad pixels
from 2.1 to 1.6 (30% better)

Quality tests after the fix:
cubic: bad paths (59294/10 == 59,29%, 94335 bad pixels (avg = 1,59),
3966 warnings (avg = 0,07)
quad: bad paths (62916/10 == 62,92%, 103818 bad pixels (avg = 1,65),
6514 warnings (avg = 0,10)


I also fixed the RasterPerf test that did not really tested the nonAA
performance as the antialiasing argument was hard-coded to true.

Here are the latest results still showing that MarlinFX is still the
fastest rasterizer (the fix caused only 3% slowdown on quads)

1656771 10x10 Rectangle native non-AA rasterizations took 2838.21ms,
583737.989789339 ops/sec
167656 100x100 Rectangle native non-AA rasterizations took 2988.26ms,
56104.89047137799 ops/sec
24657 300x300 Rectangle native non-AA rasterizations took 2999.07ms,
8221.548680090827 ops/sec
1095638 10x10 Ellipse native non-AA rasterizations took 2921.11ms,
375075.91292351193 ops/sec
141453 100x100 Ellipse native non-AA rasterizations took 2993.52ms,
47253.06662390764 ops/sec
23322 300x300 Ellipse native non-AA rasterizations took 2990.53ms,
7798.6176363387085 ops/sec
104167 100x100 Cubics native non-AA rasterizations took 2993.09ms,
34802.49508033504 ops/sec
179098 100x100 Quads native non-AA rasterizations took 2990.27ms,
59893.588204409636 ops/sec

697353 10x10 Rectangle native AA rasterizations took 2970.08ms,
234792.66551742714 ops/sec
69040 100x100 Rectangle native AA rasterizations took 2996.82ms,
23037.75335188633 ops/sec
15150 300x300 Rectangle native AA rasterizations took 3000.23ms,
5049.6128630138355 ops/sec
427194 10x10 Ellipse native AA rasterizations took 2984.12ms,
143155.77121563477 ops/sec
52642 100x100 Ellipse native AA rasterizations took 3000.88ms,
17542.187624963342 ops/sec
14141 300x300 Ellipse native AA rasterizations took 2999.32ms,
4714.735340010402 ops/sec
32264 100x100 Cubics native AA rasterizations took 3004.43ms,
10738.80902533925 ops/sec
65598 100x100 Quads native AA rasterizations took 2996.14ms,
21894.170499375865 ops/sec


2270203 10x10 Rectangle Java non-AA rasterizations took 2643.8ms,
858689.3864891444 ops/sec
130620 100x100 Rectangle Java non-AA rasterizations took 2933.28ms,
44530.355097365406 ops/sec
18158 300x300 Rectangle Java non-AA rasterizations took 2999.77ms,
6053.130740023402 ops/sec
1302146 10x10 Ellipse Java non-AA rasterizations took 2832.42ms,
459729.1362156742 ops/sec
115743 100x100 Ellipse Java non-AA rasterizations took 2980.09ms,
38838.759903224396 ops/sec
17448 300x300 Ellipse Java non-AA rasterizations took 3000.02ms,
5815.961226925154 ops/sec
90130 100x100 Cubics Java non-AA rasterizations took 2947.1ms,
30582.606630246682 ops/sec
153626 100x100 Quads Java non-AA rasterizations took 2981.04ms,
51534.36384617449 ops/sec


577864 10x10 Rectangle Java AA rasterizations took 2886.25ms,
200212.7327847553 ops/sec
49513 100x100 Rectangle Java AA rasterizations took 2997.83ms,
16516.280109279047 ops/sec
10649 300x300 Rectangle Java AA rasterizations took 2999.48ms,
3550.28204474 ops/sec
396414 10x10 Ellipse Java AA rasterizations took 2984.77ms,
132812.2434894481 ops/sec
40773 100x100 Ellipse Java AA rasterizations took 2999.61ms,
13592.767059717762 ops/sec
10132 300x300 Ellipse Java AA rasterizations took 2999.64ms,
3377.7386619727704 ops/sec
28466 100x100 Cubics Java AA rasterizations took 3080.16ms,
9241.727702457016 ops/sec
48989 100x100 Quads Java AA rasterizations took 2900.38ms,
16890.545376812694 ops/sec

2837061 10x10 Rectangle Marlin non-AA rasterizations took 2773.42ms,
1022946.7588753236 ops/sec
217841 100x100 Rectangle Marlin non-AA rasterizations took 2560.12ms,
85090.15202412388 ops/sec
48999 300x300 Rectangle Marlin non-AA rasterizations took 2966.98ms,
16514.772597051546 ops/sec
1165498 10x10 Ellipse Marlin non-AA rasterizations took 2259.69ms,
515777.82793215 ops/sec
145263 100x100 Ellipse Marlin non-AA rasterizations took 2450.31ms,
59283.51922817929 ops/sec
31591 300x300 Ellipse Marlin non-AA rasterizations took 2868.11ms,
11014.57057086374 ops/sec
93796 100x100 Cubics Marlin non-AA rasterizations took 2760.0ms,
33984.057971014496 ops/sec
182128 100x100 Quads Marlin non-AA rasterizations took 2978.02ms,
61157.413314887075 ops/sec

803422 10x10 Rectangle Marlin AA rasterizations took 2411.52ms,
333159.9986730361 ops/sec

Re: Follow-on bugs

[Laurent Bourgès]

Jim,

I found the bug in RendererNoAA caused by a 'bad' regexp match:
0x7fff was modified to 0x7Dff !

so there is no more regression in TestNonAARasterization !

Laurent


FYI, here is the diff of the correction (over the previous big patches):

< +++
new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java
2016-11-30 22:48:51.710420442 +0100
---
> +++
new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java
2016-11-30 23:35:42.879588649 +0100
2276,2277c2276,2277
< +private static final int ALL_BUT_LSB = 0xfffe;
< +private static final int ERR_STEP_MAX = 0x7Dff; // = 2^31 - 1
---
> +private static final int ALL_BUT_LSB = 0xFFFe;
> +private static final int ERR_STEP_MAX = 0x7FFF; // = 2^31 - 1
2675,2676c2675,2676
< +// = fixed_floor(x1_fixed + 0x7Dff)
< +// and error   = fixed_fract(x1_fixed + 0x7Dff)
---
> +// = fixed_floor(x1_fixed + 0x7FFF)
> +// and error   = fixed_fract(x1_fixed + 0x7FFF)
2681c2681
< + + 0x7DffL;
---
> + + 0x7FFFL;

< +++
new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java
2016-11-30 22:48:52.662420517 +0100
---
> +++
new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java
2016-11-30 23:35:43.835587936 +0100
4147,4148c4147,4148
< +private static final int ALL_BUT_LSB = 0xfffe;
< +private static final int ERR_STEP_MAX = 0x7Dff; // = 2^31 - 1
---
> +private static final int ALL_BUT_LSB = 0xFFFe;
> +private static final int ERR_STEP_MAX = 0x7FFF; // = 2^31 - 1
4537,4538c4537,4538
< +// = fixed_floor(x1_fixed + 0x7Dff)
< +// and error   = fixed_fract(x1_fixed + 0x7Dff)
---
> +// = fixed_floor(x1_fixed + 0x7FFF)
> +// and error   = fixed_fract(x1_fixed + 0x7FFF)
4543c4543
< + + 0x7DffL;
---
> +         + 0x7FFFL;



2016-11-30 23:12 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>:

> Jim,
>
> As announced yesterday night, I made a new 'Double' (alias D) pipeline for
> marlinFX with 2 webrevs:
> - cmp that compares the D pipeline vs the float pipeline:
> http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/
> - raw that makes no comparison to be easily applicable as a patch:
> http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/
>
> As explained, I duplicated the complete pipeline (including
> MarlinRasterizer) so both can be used for comparisons.
> To enable the D pipeline, just add -Dprism.marlin.double=true else the
> float pipeline will be used !
>
> I left the conv.sh script that makes the 90% of the class conversions.
>
>
> It is very preliminary as I doubt we will keep two pipelines (for
> maintenance reasons) and here my test results:
> - DemoFX (stars / sierpinski) / GuiMark performance are so close that I
> can not really see any real difference on my linux with intel 7-4800 ;
> maybe other cpu may have more impact with double vs float but the
> floating-point computations are representing a minor part of the shape
> rendering (dasher, stroker, curve interpolation in Renderer)
>
> Quality:
> - Dasher issue with large shapes: all issues are fixed with marlinFX-D
> (rect, circle)
> - TestNonAARasterization: the errors seem are more important (poly, quad,
> cubic) so there may be either a bug in the test (Path2D comparisons) or an
> important issue in the D pipeline as also polygons are affected
>
> I wanted to present you this work to get your early feedback and mention
> the issues with TestNonAARasterization that will require some work to
> understand clearly what's happening !
>
> Cheers,
> Laurent
>
> As I wanted to use double precision for long, I ported main marlinFX
>> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems
>> already working well.
>>
>> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark
>> (webview) seems the same as the hot spot is in scanline processing +
>> coverage / mask processing, not in the dasher or stroker parts.
>>
>> This first prototype is promising and it only took me few hours...
>>
>> However, subdiving large curves is still an interesting option to
>> preserve quality / accuracy even with double precision as mentioned in my
>> previous email.
>>
>

Re: Follow-on bugs

[Laurent Bourgès]

Jim,

As announced yesterday night, I made a new 'Double' (alias D) pipeline for
marlinFX with 2 webrevs:
- cmp that compares the D pipeline vs the float pipeline:
http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/
- raw that makes no comparison to be easily applicable as a patch:
http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/

As explained, I duplicated the complete pipeline (including
MarlinRasterizer) so both can be used for comparisons.
To enable the D pipeline, just add -Dprism.marlin.double=true else the
float pipeline will be used !

I left the conv.sh script that makes the 90% of the class conversions.


It is very preliminary as I doubt we will keep two pipelines (for
maintenance reasons) and here my test results:
- DemoFX (stars / sierpinski) / GuiMark performance are so close that I can
not really see any real difference on my linux with intel 7-4800 ; maybe
other cpu may have more impact with double vs float but the floating-point
computations are representing a minor part of the shape rendering (dasher,
stroker, curve interpolation in Renderer)

Quality:
- Dasher issue with large shapes: all issues are fixed with marlinFX-D
(rect, circle)
- TestNonAARasterization: the errors seem are more important (poly, quad,
cubic) so there may be either a bug in the test (Path2D comparisons) or an
important issue in the D pipeline as also polygons are affected

I wanted to present you this work to get your early feedback and mention
the issues with TestNonAARasterization that will require some work to
understand clearly what's happening !

Cheers,
Laurent

As I wanted to use double precision for long, I ported main marlinFX
> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems
> already working well.
>
> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark
> (webview) seems the same as the hot spot is in scanline processing +
> coverage / mask processing, not in the dasher or stroker parts.
>
> This first prototype is promising and it only took me few hours...
>
> However, subdiving large curves is still an interesting option to preserve
> quality / accuracy even with double precision as mentioned in my previous
> email.
>

Re: Follow-on bugs

[Laurent Bourgès]

Hi again,

As I wanted to use double precision for long, I ported main marlinFX
classes using a tricky sed scripts... fixed the 'D' pipeline and it seems
already working well.

The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark
(webview) seems the same as the hot spot is in scanline processing +
coverage / mask processing, not in the dasher or stroker parts.

This first prototype is promising and it only took me few hours...

However, subdiving large curves is still an interesting option to preserve
quality / accuracy even with double precision as mentioned in my previous
email.

Laurent

> PS: anyway I will later try using doubles instead of floats in Marlin,
but it will time consuming, so let's postpone such task.

Re: Follow-on bugs

[Laurent Bourgès]

Hi,

For large curves, I would recommend using a first step to subdivide the
curve into smaller ones (1024 pixels as described in Lien paper) to ensure
the AFD algorithm preserves enough accuracy with float values (first) in
the Dasher.

Basic recursive subdivision at halves with a large flatness tolerance would
do the job... this initial step could also subdivide at cups, inflexion and
roots for fills ?

Moreover, it could help a basic clipper based on simple hulls (all control
points) to reject curve portions out of the top, bottom and maybe right and
left parts (tricky as interior rules are based on left to right
intersections...)

What are good curve length estimators ?

Help is welcome as usual and will have a look to the test classes asap.

PS: anyway I will later try using doubles instead of floats in Marlin, but
it will time consuming, so let's postpone such task.

Cheers,
Laurent

Le 29 nov. 2016 08:37, "Michael Paus"  a écrit :
>
> Am 29.11.16 um 01:09 schrieb Jim Graham:
>
>>
>> With respect to float/double, I have another bug somewhere where we have
a large inaccuracy for a very large circle that intersects the viewing area
along only a very tiny portion.  The errors get especially bad with dashing
because we iterate each dash using an incrementally relative sub-divide
rather than returning always to the original curve to sub-divide from
t1-to-t2.  I'll look it up and send you a pointer so you can see how Marlin
does with those paths.  I believe that I briefly modified the Pisces Dasher
to simply use doubles and the problem went away, but I didn't do any
performance analysis and the newly accurate dashes no longer matched the
still-float-based fills so more work was needed. Modern processors tend to
deal with double precision natively and so other than storage
considerations double calculations are often as fast or sometimes faster
than float (because of not needing to be cast back to 32-bit float when the
FPU always produces 64-bit double answers)...
>
> I can help you out here because I have reported these bugs. The
references are
>
>  https://bugs.openjdk.java.net/browse/JDK-8160599
>  https://bugs.openjdk.java.net/browse/JDK-8160600
>
> I also think that using doubles instead of floats would make things much
more accurate
> especially as the user actually can expect that because the JavaFX API
also uses doubles
> and it is not clear to the user that this is currently reduced internally
to float.
>
> Michael
>

Re: Follow-on bugs

[Laurent Bourgès]

Jim,

There is one thing I think you should look at, though, and I wasn't sure if
> I should file a bug.  If you've downloaded the Rasterization verifier from
> the old JBS bug for non-AA rendering, try running it with the 4quads mode
> (-quad argument I think).  It looks like it averages slightly more failures
> on Marlin than jpisces or npisces.  (3 bad pixels per shape rather than 2 -
> or 4 vs. 3 - I forget the exact numbers).  This may simply be a difference
> in the DEC_INC_BND settings and an easy fix.  File a bug if you find
> something to fix...
>


I made tests related to nonAA quality and the related quad decimation
thresholds:
The quad decrement threshold seem a bit too high => lowering to 0.5
subpixel leads to 2.07 error:

OpenPisces:
bad paths (78759/10 == 78,76%, 177046 bad pixels (avg = 2,25), 6524
warnings (avg = 0,08)

MarlinFX:
bad paths (90332/10 == 90,33%, 288202 bad pixels (avg = 3,19), 6702
warnings (avg = 0,07)

MarlinFX with DEC_BND=0.5:
bad paths (77342/10 == 77,34%, 164702 bad pixels (avg = 2,13), 6649
warnings (avg = 0,09)

So the trivial fix consist in lowering the threshold.

HOWEVER, it led me having a look again at the algorithmic approach:
The (Sun) paper (Lien 87) describes this approach (AFD) to draw curves
pixels by pixels so the original thresholds were defined to 1 / 0.5 pixels
and it indicates that this algorithm generates at least 1 point per pixel
... so is not related to any error bound nor really the good approach to
minimize the number of segments when the curve is "flat".

Moreover, this test performs path fills (no stroke) so I am asking several
questions about the algorithmic approach:
- AFD thresholds are in fact related to delta X/Y or speed and are ensuring
small displacements (subpixel) unrelated to any error (ROC ?) between the
segment and the curve => it will generate lots more segments than needed
except when the curve has cups or inflexions ...
- subdividing curves may be a more appropriate approach (agg, QT...) as
there are several flatness tests (intermediate point distance like in
ShapeSpanIterator.c) to ensure the curve is under-control ie within the
tolerance
- in Stroker, the curve is subdivided at cups, inflexion points, roots to
have monotonic cuves but in the case of path fills, the curve is directly
processed by the Renderer: maybe we should first subdivide the curves at
those extrema and then use the current approach to improve the affinity at
these special points.

Finally the curve segments are generated with the floating-point maths so
the pixel accuracy is also strongly related to rounding points on the grid
(at pixel centers), so this implies to have small tolerance to compensate
rounding issues.

Jim, do you have advices on:
- how to improve both curve accuracy but also minimize the number of
generated segments ? which algorithm ?
- which flatness test has your recommendations ?
- do you know an adaptive AFD variant that determine the step size
according to radius of curvature ? (like in Graphics Gem I: p594 Wallis
Tutorial on Forward Differencing)

Laurent

Review request for JDK-8170140: rendering anomaly with MarlinFX renderer

[Laurent Bourgès]

Jim & Kevin,

Please review the marlin-FX webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170140.0/
JBS: https://bugs.openjdk.java.net/browse/JDK-8170140

Ths bug fix seems very simple in MaskMarlinAlphaConsumer:

+// ensure last block flag = 0 to process final block:+
blkFlags[blkE] = 0;

But it is less easy to explain:
In Renderer, the block flags are set by:
blkFlags[(pix_xmax + 1)  >> _BLK_SIZE_LG] = 1

I recently added +1 that can lead to flag an extra block when pix_xmax is
at a block boundary (32 pixels).

pix_xmax = x1 >> _SUBPIXEL_LG_POSITIONS_X
x1 <= bboxx1 = bbox_spmaxX = pmaxX << SUBPIXEL_LG_POSITIONS_X

So pix_xmax is at most equals to pmaxX = bboxX1 = getOutpixMaxX()

The added line in MaskMarlinAlphaConsumer ensures that the
setAndClearRelativeAlphas() always process the loop that clears and copies
the last block of pixels:
blkFlags[blkE] = 0 is equivalent to blkFlags[(bboxX1 + 1)  >> _BLK_SIZE_LG]
= 0

This is quite difficult to explain but it is now correct.

I added a test in System tests as it was not working in javafx.graphics
tests (Exception in Application constructor)

PS: This bug may be the cause of RegionBackgroundFillUITest failures:
https://bugs.openjdk.java.net/browse/JDK-8170026

Regards,
Laurent

Re: Optimised, high-performance, multi-threaded rendering pipeline

[Laurent Bourgès]

Hi,

To optimize Pisces that became the Marlin rasterizer, I carefully avoided
any both array allocation (byte/int/float pools) and also reduced array
copies or clean up ie only clear dirty parts.

This approach is generic and could be applied in other critical places of
the rendering pipelines.

FYI here are my fosdem 2016 slides on the Marlin renderer:
https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf

Of course I would be happy to share my experience and work with a tiger
team on optimizing JavaFX graphics.

However I would like getting sort of sponsoring for my potential
contributions...

Cheers,
Laurent

Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit :
>
> Hi,
>
> thanks Felix, Laurent and Chris for sharing your stuff with the community!
>
> I am happy to see starting a discussion about boosting up the JavaFX
rendering performance. I can confirm that the performance of JavaFX scene
graph is not there where it should be. So multithreading would be an
excellent, but difficult approach.
>
> Felix, concerning your research of other toolkits: Do they all use
multithreading or are there any toolkits which use single threading but are
faster than JavaFX?
>
> So maybe there are other points than multithreading where we can boost
the performance?
>
> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark
with your HPR?
>
>
> Best regards,
> Tobi
>
>
> > Am 10.11.2016 um 19:11 schrieb Felix Bembrick <felix.bembr...@gmail.com
>:
> >
> > (Thanks to Kevin for lifting my "awaiting moderation" impasse).
> >
> > So, with all the recent discussions regarding the great contribution by
> > Laurent Bourgès of MarlinFX, it was suggested that a separate thread be
> > started to discuss parallelisation of the JavaFX rendering pipeline in
> > general.
> >
> > As has been correctly pointed-out, converting or modifying the existing
> > rendering pipeline into a fully multi-threaded and performant beast is
> > indeed quite a complex task.
> >
> > But, that's exactly what myself and my colleagues have been working on
for
> > about 2 years.
> >
> > The result is what we call the Hyper Rendering Pipeline (HPR).
> >
> > Work on HPR started when we developed FXMark and were (bitterly)
> > disappointed with the performance of the JavaFX scene graph.  Many
JavaFX
> > developers have blogged about the need to dramatically minimise the
number
> > of nodes (especially on embedded devices) in order to achieve even
> > "acceptable" performance.  Often it is the case that most (if not all
> > rendering) is eventually done in a single Canvas node.
> >
> > Now, as well already know, the JavaFX Canvas does perform very well and
the
> > recent awesome work (DemoFX) by Chris Newland, just for example, shows
what
> > can be done with this one node.
> >
> > But, the majority of the animation plumbing in JavaFX is related to the
> > scene graph itself and is designed to make use of multiple nodes and
node
> > types.  At the moment, the performance of this scene graph is the
Achilles
> > Heel of JavaFX (or at least one of them).
> >
> > Enter HPR.
> >
> > I personally have worked with a number of hardware-accelerated toolkits
> > over the years and am astounded by just how sluggish the rendering
pipeline
> > for JavaFX is. When I am animating just a couple of hundred nodes using
> > JavaFX and transitions, I am lucky to get more than about 30 FPS, but on
> > the same (very powerful) machine, I can use other toolkits to render
> > thousands of "objects" and achieve frame rates well over 1000 FPS.
> >
> > So, we refactored the entire scene graph rendering pipeline with the
> > following goals and principles:
> >
> > 1. It is written using JavaFX 9 and Java 9 (but could theoretically be
> > back-ported to JavaFX 8 though I see no reason to).
> >
> > 2. We analysed how other toolkits had optimised their own rendering
> > pipelines (especially Qt which has made some significant advances in
this
> > area in recent years).  We also analysed recent examples of
multi-threaded
> > rendering using the new Vulkan API.
> >
> > 3. We carefully analysed and determined which parts of the pipeline
should
> > best utilise the CPU and which parts should best utilise the GPU.
> >
> > 4. For those parts most suited to the CPU, we use the advanced
concurrency
> > features of Java 8/9 to maximise parallelisation and throughput by
> > utilising multiple cores & threads in as an efficient manner as
possible.
> >
> > 5. We devoted a large amount 

Review request for JDK-8169270: Leverage new Java2D Marlin rasterizer for JavaFX

[Laurent Bourgès]

Jim & Kevin,

Sorry to announce this code review in late, I thought JBS would have sent
such email from the comment.


Please review the marlin-FX webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/
JBS: https://bugs.openjdk.java.net/browse/JDK-8169270
Reviewers: flar, kcr

This webrev consist in Prism classes (ShapeUtil, SWContext) using the new
Marlin renderer ported to JavaFX.
The PrismSettings class has been modified to have the new
prism.marlinrasterizer flag (disabled by default).

Marlin-FX is slightly different than Marlin OpenJDK9 to:
- use javafx classes instead of java2d classes
- fix Dasher / Stroker as done in OpenPisces
- support both AA and nonAA Renderer (see MarlinRenderer interface)
- fix Renderer cubic decimation thresholds to match OpenPisces nonAA
quality
- the new MarlinAlphaConsumer supports optimized alpha copies (only
valuable ranges) and the block flag optimized fills for the
MarlinRasterizer only (not SWContext)

Note: The SWContext.DirectRTPiscesMarlinAlphaConsumer relies on
PiscesRenderer.emitAndClearAlphaRow() that is not optimal with the Marlin
approach as it expects a complete row [x0, x1] although Marlin gives the
span [xmin, xmax] where coverage != 0. The prism-native-sw (c code) could
be improved to accept an extra offset to skip useless pixels [x0, xmin] and
improve the blending performance.

Will upgrade later OpenJDK9's Marlin renderer or if you prefer, I can do it
first.


PS: As you proposed in the previous thread, I will refactor reentrant
classes to com.sun.util.reentrant and remove useless properties in
MarlinProperties.

Regards,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Jim,

2016-11-10 0:47 GMT+01:00 Jim Graham :

> Hi Laurent,
>
> Great job on creating a very obvious minimal impact!  That should help
> streamline it through the approval process.
>

Thanks.


>
> Is MarlinProperties.isEnabled still used?  (Searching patch file - no, I
> don't think so)
>

Will fix and also remove all tile related properties.


>
> Kevin and I had a long back and forth over the packaging of the Reentrant
> files and came up with "com.sun.util.reentrant" as we'd like to avoid
> "com.sun" as a terminal package.  We should eventually move a few other
> common utilities into that new tree as well, but we can start with these
> classes.
>

Agreed.


>
> I still want to take a pass through the changes to the Marlin files
> themselves, but above is my review of the glue code and with that Kevin can
> pursue the internal processes.
>
> Before I pursue too far on reading the Marlin source changes, I'd like to
> hear back about how this version of Marlin(FX) differs from the OpenJDK
> version of Marlin(2D) - were they based on different versions of your
> Marlin project?  Also, you mentioned waiting for the jigsaw build patch
> integration.  I'm guessing you meant the build changes that happened
> yesterday, so we can proceed now?
>

About jigsaw integration: I made the latest patch (JBS) after testing a
complete OpenJDK9+OpenJFX9 build and running DemoFX + Ensemble8.

Yes, let's discuss the webrev on a dedicated thread:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/


>
> With respect to the changes to the native part of the SW pipeline that
> would trim the rendering - please continue to investigate them, but we
> should pursue those as a separate bug fix so as not to complicate this
> particular change.  It sounds like you've adapted the new code in the
> SWContext wrapper class to not require that native change yet, so let's go
> with that for the first phase...
>

Agreed, let's postpone that effort later as it is not blocking.

Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Jim,

2016-11-10 0:39 GMT+01:00 Jim Graham <james.gra...@oracle.com>:

> Going forward perhaps we should refer to the version of Marlin in Java2D
> as Marlin2D?
>
> Then Marlin is your original plug-in version that is still being worked on.
> Marlin2D is what you integrated into OpenJDK/Java2D.
> MarlinFX is what you are planning for FX.
>

I agree your naming convention.


>
> That's just for conversational purposes, I'm not proposing that we
> formalize those into formal project names, but this will keep discussions
> smaller?
>
> On 11/2/16 2:54 PM, Laurent Bourgès wrote:
>
>> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit
>> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I
>> will synchronize both branches to provide soon MarlinFX9 patches closer to
>> OpenJDK9's Marlin renderer if we are going to work on its integration.
>>
>
> If I read this correctly, you have outstanding changes you've made to
> Marlin that you plan to propose for Marlin2D, but they haven't been
> proposed yet?
>

Exactly but I told you several times (in this thread):
- I started optimizing tile filling in Marlin 0.7.5 (asymetric tiles W !=
H) and it is 10% faster for almost empty (0x00) / full tiles (0xFF) but
also it speeds up larger tiles (128 x 32 ...) than usual (32 x 32)
- I switched to Marlin-FX and found out that OpenPisces (Dasher / Stroker /
Renderer cubic decimation thresholds) were changed compared to Pisces2D so
I ported all these changes to Marlin-FX (first)
- Very minor fixes in Renderer loop: block flag bug + fast exit loop on the
right side
- Increased array size for edge / crossings / polystack (as in 0.7.3)

If you prefer, I can first upgrade Marlin2D then propose a new webrev for
MarlinFX for its integration.

Anyway Marlin changes are very small compared to Marlin2D or MarlinFX and
are located in principal classes.


>
> And you based MarlinFX on the newer version of Marlin with those
> outstanding changes?
>

Yes but MarlinFX do not have MarlinCache nor MarlinTileGenerator where are
located changes for optimizing tile filling. To sum up, MarlinFX has small
changes from Marlin to make it compliant with OpenPisces.


>
> Is your plan to propose a patch for Marlin2D soon?
>

Yes to make Marlin2D up-to-date and behave like OpenPisces / MarlinFX.


>
> For now I'd like to keep the 2 versions of Marlin in the JDK in sync other
> than differences required for Java2D's rendering pipelines vs. the FX
> ones.  That will simplify at least the intial proposal to integrate this if
> we can say it is "99% the same as the one in Java2D other than differences
> required by the pipelines" which should quiet any fears that might get in
> the way.
>
> Did I read that correctly?  Does that sound reasonable?
>

MarlinFX is now ready and up-to-date to behave like OpenPisces.


Finally I submitted yesterday a new webrev on JBS and expected it would
have started a new review thread (as this one is too long !)

Please have a look to my comment:
https://bugs.openjdk.java.net/browse/JDK-8169270

"
Please review the marlin-FX webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/
Reviewers: flar

This webrev consist in Prism classes (ShapeUtil, SWContext) using the new
Marlin renderer ported to JavaFX.
The PrismSettings class has been modified to have the new
prism.marlinrasterizer flag (disabled by default).

Marlin-FX is slightly different than Marlin OpenJDK9 to:
- use javafx classes instead of java2d classes
- fix Dasher / Stroker as done in OpenPisces
- support both AA and nonAA Renderer (see MarlinRenderer interface)
- fix Renderer cubic decimation thresholds to match OpenPisces nonAA
quality
- the new MarlinAlphaConsumer supports optimized alpha copies (only
valuable ranges) and the block flag optimized fills for the
MarlinRasterizer only (not SWContext)

Note: The SWContext.DirectRTPiscesMarlinAlphaConsumer relies on
PiscesRenderer.emitAndClearAlphaRow() that is not optimal with the Marlin
approach as it expects a complete row [x0, x1] although Marlin gives the
span [xmin, xmax] where coverage != 0. The prism-native-sw (c code) could
be improved to accept an extra offset to skip useless pixels [x0, xmin] and
improve the blending performance.

Will upgrade later OpenJDK9's Marlin renderer or if you prefer, I can do it
first.
"

Best regards,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Jim,

>
> I would think an effort to parallelize a single shape rasterization would
> be much simpler in scope.  Still outside the current JDK 9 timeline, but
> definitely something that could help in future releases.  I believe that
> once we put the edges into the internal structures we could parallelize the
> rasterization of individual scanlines and maybe break a tall shape up into
> N horizontal bands for N threads.  Other thoughts would be a thread to
> generate the crossings and N threads to populate the alphas...?
>

Multithreaded rendering is a complex task that should be discussed in
another thread as it is totally out of my current scope.

My 2 cents: there is two approach:
- render shapes in parallel (but it requires the JavaFX pipeline to be
parallelized = tricky as caching mask, gpu need single thread communication
...)
- render shape with several threads (as you proposed) but the scanline
algorithm requires the previous scanline information like previous edges
(so it becomes tricky to make it efficient) and this will only speed up
large shapes (point clouds will remain slow !)

Anyway the major issue concerns latency ie how to spread the workload on
several threads when the scene contains shapes with various sizes or
complexity (edge count): the latency corresponds to the slowest thread to
complete its rendering task.
=> adaptive algorithm to make a sort of load balancing (work stealing
approach) or small tasks (average same cpu cost).

PS: I have some experience on parallelization, but please let's postpone
this discussion or let's do it in another thread.

Laurent

Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Felix & Tobias,

Could you please start another thread to discuss the parallelization
(multi-threading) in JavaFX Graphics ?

I am a bit lost as there is 13 messages since 12 hours on several topics
(marlin, MT ...) so I would like closing this topic soon by answering
MarlinFX questions and participate to other threads.

Thanks a lot,
Laurent

Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Hi,

First results with DemoFX (run.sh -e sierpinski) to compare a simple path
scene with HW pipeline (es2):
- native pisces: 138 fps
- open pisces: 150 fps
- marlin fx: 300 fps

But it is too simple to evaluate Marlin improvements: the more complex the
shape is, the more performance you get

Laurent

Re: ACTION - JavaFX modular build is here

[Laurent Bourgès]

Kevin & David,

It seems tricky to add a module dependency !

2016-11-09 14:51 GMT+01:00 Kevin Rushforth :

> My recommendation would be to avoid this dependency if possible, but if
> not, then Dave's suggestion is the way to go. What is it that you need from
> jdk.internal.ref that you can't do using public API?
>

Marlin (OpenJDK) use jdk.internal.ref.CleanerFactory.cleaner() to get the
java.base Cleaner instance (Thread).

I agree for Marlin-FX, it will be easier to use the public Cleaner API but
it will cost creating another thread.

Here is the current fix :

// JavaFX specific Cleaner for Marlin-FX:
// Module issue with jdk.internal.ref.Cleaner
private final static java.lang.ref.Cleaner cleaner
= java.lang.ref.Cleaner.create();

static java.lang.ref.Cleaner getCleaner() {
return cleaner;
}

instead of:
/*
static jdk.internal.ref.Cleaner getCleaner() {
return jdk.internal.ref.CleanerFactory.cleaner();
}
*/

Regards,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Hi,

I think we should wait for OpenJFX9 Jigsaw build patch that is coming and
rebase / test again the proposed patch Marlin for JavaFX.

Maybe jdk.internal.Cleaner or Unsafe.allocateDirect methods will be then
available to the javafx.graphics module or that may be acceptable to export
such jdk API to OpenJFX.

Finally I will have a look at the native prism sw code to see if I can fix
the forementioned method by adding 1 integer to give the output_minx
coordinate and only process pixels where the alpha coverage != 0.

Please give me your opinions.

Cheers,
Laurent

Le 7 nov. 2016 23:55, "Laurent Bourgès" <bourges.laur...@gmail.com> a
écrit :

> Jim,
>
> Here is the new patch:
> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/
>
> Changes:
> - cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner)
> - modified PrismSettings as recommended and renamed all Marlin properties
> to use the prefix 'prism.marlin'
> - SWContext: added Marlin SW support: I had to tweak the processed
> range[x; pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does
> not handle properly the bbox so it processes many extra pixels on the left
> side (empty coverage) = to be discussed as it can be fixed in the native
> prism-sw code ... See my comment in the code:
>
> +@Override+public void 
> setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+  
> final int pix_from, final int 
> pix_to)+{+// use x instead of pix_from as it 
> cause artefacts:+// note: it would be more efficient to skip 
> all those empty pixels [x to pix_from[+// but the native 
> implementation must be fixed too.+//
> pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from, pix_to, 
> rowNum);+pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, 
> pix_y, x, pix_to, rowNum);
>
> I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143
> (xpatch.args) with Ensemble8 + DemoFX.
>
> Maybe it is time to start the review for the FX enhancement ?
> https://bugs.openjdk.java.net/browse/JDK-8169270
>
> Cheers,
> Laurent
>
>
> 2016-11-04 19:55 GMT+01:00 Jim Graham <james.gra...@oracle.com>:
>
>> On 11/4/2016 11:33 AM, Laurent Bourgès wrote:
>>
>>> For SWContext, I figured out that only openpisces.* classes were used
>>> directly via imports (hardcoded) so I left it unchanged. So you propose
>>> to generalize use of marlin or native pisces ?
>>>
>>
>> I didn't notice that, I was just searching on the use of
>> "doNativePisces".  We can look at that separately, and Kevin would know how
>> frequently we end up in the SW pipeline these days...
>
>

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Jim,

Here is the new patch:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/

Changes:
- cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner)
- modified PrismSettings as recommended and renamed all Marlin properties
to use the prefix 'prism.marlin'
- SWContext: added Marlin SW support: I had to tweak the processed range[x;
pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does not handle
properly the bbox so it processes many extra pixels on the left side (empty
coverage) = to be discussed as it can be fixed in the native prism-sw code
... See my comment in the code:

+@Override+public void
setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+
   final int pix_from,
final int pix_to)+{+// use x instead of
pix_from as it cause artefacts:+// note: it would be
more efficient to skip all those empty pixels [x to pix_from[+
   // but the native implementation must be fixed too.+//
  pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from,
pix_to, rowNum);+pr.emitAndClearAlphaRow(alpha_map,
alphaDeltas, pix_y, x, pix_to, rowNum);

I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143
(xpatch.args) with Ensemble8 + DemoFX.

Maybe it is time to start the review for the FX enhancement ?
https://bugs.openjdk.java.net/browse/JDK-8169270

Cheers,
Laurent


2016-11-04 19:55 GMT+01:00 Jim Graham <james.gra...@oracle.com>:

> On 11/4/2016 11:33 AM, Laurent Bourgès wrote:
>
>> For SWContext, I figured out that only openpisces.* classes were used
>> directly via imports (hardcoded) so I left it unchanged. So you propose
>> to generalize use of marlin or native pisces ?
>>
>
> I didn't notice that, I was just searching on the use of
> "doNativePisces".  We can look at that separately, and Kevin would know how
> frequently we end up in the SW pipeline these days...

Re: Review request for 8169294:

[Laurent Bourgès]

Jim,

2016-11-07 21:05 GMT+01:00 Jim Graham :

> I'd like to see Kevin review the test as I'm not the best expert on our
> JUnit framework.
>

I just added @Test annotations and kept the jtreg tags in header (for
information).
I could add asserts but JUnit does intercept any thrown exception and
reports a test failure in such case.

I managed to undestand how to run my test with gradle:
gradle :graphics:test  --tests test.com.sun.javafx.geom.Path2DGrowTest

It is passing and the reports indicates that the 2 new tests are OK (report
in modules/javafx.graphics/build/reports/tests/index.html)


>
> It looks like it is mostly just going to emit some printouts about
> performance (using echo() and log()) and verify that we don't get any
> ArrayBounds related exceptions (or worse, OOME)?
>

Exactly, it is passing as there is no runtime exception and the performance
issue is fixed as indicated by the few logged lines.


>
> The only difference in Path2D.java I noted is that the Java2D version has
> an EXPAND_MIN which is 10, but you re-use INIT_SIZE, which is 20, here for
> the same purpose.
>

You're right; I think I didn't want to add an extra constant but if you
prefer being more consistent, I can prepare another webrev.

Laurent

Review request for 8169294:

[Laurent Bourgès]

Hi,

Please review this Path2D fix improving its storage growth algorithm as
done in java2d:
JBS: https://bugs.openjdk.java.net/browse/JDK-8169294
Webrev: http://cr.openjdk.java.net/~lbourges/fx/path2D/

PS: I converted the former jtreg test to JUnit test for OpenJFX. I hope it
is correct, as I was not able to run this test within gradle (but it works
in netbeans)

Best regards,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Hi Kevin & Jim,

this plan looks good for me.


> Thanks for the summary. We should proceed as you outlined. Can you file a
> new RFE (Enhancement) to integrate Marlin into JavaFX as an optional
> rasterizer (disabled by default) so we have a clean JBS issue to use for
> the JDK 9 feature extension request, rather than using JDK-8092373? You can
> assign the RFE to Laurent. It can be linked to the Java2D/Marlin JEP and to
> JDK-8092373.
>

Thanks, I got it.


> Laurent: Since there are multiple reasons for submitting the Path2D fix as
> a separate bug fix, please file a new bug for this, linking it to the
> equivalent Java2D bug and also to the new RFE that Jim will file.
>

Will create the bug tomorrow and propose a specific webrev asap.

Thanks,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Jim,

I agree your proposals on ShapeUtil and prism settings.
Will do it in next webrev after cleanup and OpenJDK9 synchro, certainly
happening during this week end.

> I also noticed that the SWContext also chooses a rasterizer for its use
using a copy of the decision logic in ShapeUtils.  We should probably add a
ShapeUtil.getRasterizer() method to return the one that was determined by
its algorithm rather than repeat the selection algorithm in SWContext.

For SWContext, I figured out that only openpisces.* classes were used
directly via imports (hardcoded) so I left it unchanged. So you propose to
generalize use of marlin or native pisces ?

As I extended the AlphaConsumer to add two specialized methods (clearAlphas
and block flag opt fill) for MarlinRenderer we should discuss how to adapt
the DirectSWAlphaConsumer with Marlin:
it is possible to use a SWRenderer interface (renamed new MarlinRenderer
interface) and change all consumers to implement the two new methods in the
SW Consumer.
Of course it will increase the risk so I propose to create an adaptor in
marlin to implement the MarlinAlphaConsumer methods and redirect to the
former AlphaConsumer.

Looking forward your answers on the several interleaved posts on this
thread.

Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Jim,

Here is an updated patch for MarlinFX:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/

I made big improvements: MarlinFX is now "feature-complete":
- Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new
methods on AlphaConsumer and common methods between AA & noAA renderers
- Renderer: fixed cubic dec/inc lengths (like openpisces) + use optimized
copyAlphas from MarlinAlphaConsumer (with block flag optimization derived
from former MarlinCache)
- RendererNoAA: optimized Renderer for non-antialiasing (tested OK)
- Dasher & Stroker: backported changes from openpisces (small dash phase &
refined cubic / quad mitters)
- Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin
renderer as a JavaFX ShapeRasterizer and implement the MarlinAlphaConsumer
efficiently (mimics former MarlinCache ie support the block flag
optimization); MarlinPrismUtils performs properly NaN / Infinity
coordinates filtering and use the same pipeline stages (delta / invDelta
transformers for Dasher/Stroker) like in the MarlinRenderingEngine
- Thread safety: MarlinRasterizer completely thread-safe (for future
multi-threaded rendering) using ReentrantContext...
- Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of the
OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable
Marlin-FX)
- Fixed Path2D growing algorithm (like java2d)

So MarlinFX is 13K LOC (few unused classes could be removed soon) and only
few lines are added in ShapeUtil to switch MarlinFX ON:

if (PrismSettings.doNativePisces) {
shapeRasterizer = new NativePiscesRasterizer();
} else {






*// TODO: move that new setting into PrismSettings:
// Enable Marlin-FX by setting -Dsun.javafx.marlin=trueif
(MarlinProperties.isMarlinEnabled()) {
System.out.println("Marlin-FX[" + Version.getVersion() + "]
enabled.");shapeRasterizer = new
MarlinRasterizer();} else {*shapeRasterizer =
new OpenPiscesRasterizer();

*}*}

So the OpenPisces classes are totally left unchanged and MarlinFX is just
added as another rasterizer and is enabled with the following settings:
-Dsun.javafx.marlin=true and -Dprism.nativepisces=false

Of course, we could adapt these few lines to satisfy your requirements
(system properties ...); please tell me what you prefer.

I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and
everything is working fine.


Does it look acceptable as a low risk RFE ?

Finally what do you prefer for OpenJDK9 integration ?
- as a new javafx rasterizer (like the provided marlinFX patch)
- or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ?
I wonder if it would be better to create another JavaFX ShapeRasterizer
that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication but it
will add some complexity in the marlin renderer (itself) to introduce the
AlphaConsumer interface...


I can make separate patches for all these changes concerning jfx Path2D or
Marlin changes for OpenJDK9 first, then MarlinFX.

PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit
different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I
will synchronize both branches to provide soon MarlinFX9 patches closer to
OpenJDK9's Marlin renderer if we are going to work on its integration.

PS2: I will also work on another MarlinFX variant not using Unsafe but only
plain arrays to evaluate the performance loss (small) that could simplify
the integration with Jigsaw ...

So I made a big step forward, and I am looking forward your feedback,

Cheers,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Hi,
Some new from the Marlin sides:
- Marlin (java2d) for openjdk9:
I backported changes from openpisces Dasher and Stroker classes + optimized
the tile filling for almost empty / full tiles = 10% gain on huge shapes. I
plan to provide new webrevs soon
- Marlin FX:
I implemented a new RendererNoAA class that optimize the nonAA case and
started refactoring the integration (try/dispose). It remains to adjust the
NaN coordinate filter + transformer.

Jim, do you think possible to unify Marlin and MarlinFX for openjdk9 ? The
main difference relies in different Shape/PathConsumer classes and Fx uses
the AlphaConsumer + different initialization.
Did you have a look at the diffs ?

I also ported my java2d.Path2d improvements (growing algo + copy
constructor) to javafx.Path2d as it suffers the same performance issue when
the path grows... I fixed 2 years ago.

> Early benchmark results look very promising, too.

Yes and I will experience using Unsafe or DirectByteBuffer + my "block
flag" optimization soon to optimize the coverage copies into the texture
buffer...

> Enabling parallel rasterization seems like a good follow-on task, but is
out of scope for the short term given the limited amount of time. Also, the
only way that MarlinFX even has a chance of getting approved for in JDK 9
is for the default OpenPisces path to be unaltered.

Of course, MT rendering is out of my scope as I am running a sprint to
provide Marlin for OpenJFX9...

Any guideline or volunteers to help making it real ?

Finally does somebody tested MarlinFX with real applications ?

Cheers,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Michael,

> I know, but JavaFX is still doing a lot of software rendering and I doubt
that this will change
> in the near future. So having at least the option to use MarlinFX instead
of the current
> default renderer may be a advantage especially when multithreading is
enabled.

Thanks for your positive feedback that motivates me to make the job to
integrate the marlin renderer in the JavaFX pipeline.
For now the OpenPiscesRasterizer class uses a static Renderer (single
instance) so it is single-threaded.

In MarlinFX I could prepare the multi-threading support by using 1
RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.

However it seems a complex task to enable parallelization in the javafx
pipeline but I could help there also...

Cheers,
Laurent

> Michael
>
> Am 19.10.16 um 17:16 schrieb Markus KARG:
>
>> Michael, note that Marlin FX still is fully software rendering, while
you asked for more hardware rendering recently. The latter will be an
additional approach not targeted yet by Marlin FX.
>> -Markus
>>
>> -Original Message-
>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
Behalf Of Michael Paus
>> Sent: Mittwoch, 19. Oktober 2016 15:07
>> To: openjfx-dev@openjdk.java.net
>> Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX
>>
>> I'd appreciate such a solution too.
>>
>> Michael
>>
>> Am 19.10.16 um 14:34 schrieb Kevin Rushforth:
>>>
>>> Jim Graham suggested the same thing to me privately, so he and Laurent
>>> are currently looking into that possibility.
>>>
>>> -- Kevin
>>>
>>>
>>> Davide Malpassini wrote:

 I think that Marlin-Renderer can be included not as a default
 renderer to limit the impact to the jdk9 release , but leave to the
 user / developer the possibility to use and test on real applications
 the benefit of this Renderer .

 This is only an user opinion , but i think that the benefits are big.
 Davide Malpassini
>>
>>
>>
>

RE: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Mark,

> Laurent, the problem is that OpenJDK 9's feature set is already fixed, so
I think it is not possible to *officially* adopt huge features like Marlin
FX at such a "late" point. Besides that I think that Marlin FX is of so
high value to OpenJDK that I would like to nominate you as an OpenJDK
committer. But that is up to Kevin to decide, certainly!

OpenJDK9 is currently in the Feature Complete extension-request process so
it seems possible to submit a new JEP with very small impact and risk.
As marlin-fx is very close to the integrated Marlin renderer in OpenJDK9,
the risk is small for me but there will be certainly issues with jigsaw
modularization of OpenJFX: MarlinFX uses jdk Unsafe for example. Moreover,
integrating such JEP would imply to hurry up to be completed for dec 2016 !

FYI I am already jdk9 commiter in the client forrest but not in openjfx.

> I don't know the internal structure of that part of JavaFX, but maybe
Kevin could point us to some private APIs or config options one could use
to allow anybody to simply bundle Marlin FX as an alternativ renderer with
any JavaFX 8 or 9 application?

It is certainly tricky due to classloader isolation and modules... but
there is certainly some workaround.

Cheers,
Laurent

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Hi Kevin,

> This sounds promising. I looks forward to taking it for a test drive.

Thanks for your feedback. Could you share benchmark tools ? Or at least
your results.
I also tested marlinFX with large texts and it rocks. See
https://bugs.openjdk.java.net/browse/JDK-8090461

> Besides asking other people to help you evaluate it and test it (which
you just did), the next step would be for you to file a JEP for
javafx/graphics as you did earlier for client-libs/java2d. It seems like
something we might consider for JDK 10, once the JDK 10 project is open and
we start scoping it.

I know that process which is very slow and time consuming: marlin JEP265
was submitted in july 2015, integrated in dec 2015, few improvements after
but still unreleased as OpenJDK9 should be GA in july 2017 !!

It took me few evenings to make MarlinFX (some cleanup work remains but
only few days of work) and I fear that jdk10 will be released in 2020 so
this timescale is just too far for me, as all this work will be done for
free and consume my spare time. Moreover I would hope GPU could perform the
rasterization at that date (opencl, panama project...)

Could somebody else endorse / sponsor this new OpenJFX JEP and help to make
it ready for jdk9 (new JEPs are still acceptable). Of course I will not
vanish but just focus on coding + testing improvements.

Regards,
Laurent