Marlin-Renderer and JavaFX

Discussion:

Laurent Bourgès

2016-10-15 12:05:33 UTC

Hi,

I am pleased to announce the new MarlinFX project I released 2 days ago
(GPL v2):
https://github.com/bourgesl/marlin-fx

MarlinFX is the JavaFX port of the Marlin renderer (scanline rasterizer
integrated in OpenJDK9) aimed to be faster than Open/Native Pisces (notably
for very complex paths: merge sort + optimized array copies and cleanup).

I tested in on both linux & windows 64bits (server JVM) and it is at least
as fast as OpenPisces or faster (javafx shape rasterization is single
threaded up to now but marlin scales very well). Of course, it is always
faster than native pisces on my machines.

For the DemoFX sierpinski test:
- native pisces = 130fps
- open pisces = 150fps
- marlin-fx = 325fps
This test renders a very complex path so marlin-fx rocks in hard rendering
cases.
See https://github.com/chriswhocodes/DemoFX

Another DemoFX test (stars):
- open pisces:
stars = 170 fps
- marlin-fx:
stars = 259 fps
This test case is very simple: see

Setup: laptop zbook-15 (i7 4800 + nvidia Quadro K610M) on ubuntu 16.4 +
Oracle JDK 1.8.0_b102 (javafx) - VSYNC: OFF

Of course, there is lot of potential improvements in the JavaFX pipeline...
(multi-threading, inner/outer strokes...)

Finally I made a first step, and more benchmarks or test cases are needed
(I could port my MapBench tool) to get some realistic data.

Then how to go next, as there is no way to plug in such marlinFX in JavaFX
...

Could you have a look at the code (on my github) ?
I can make a webrev between openjfx and open jdk 9 if you prefer.

Cheers,
Laurent

Kevin Rushforth

2016-10-15 16:15:34 UTC

Permalink

Hi Laruent,

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

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.

-- Kevin

Post by Laurent BourgÃ¨s
Hi,
I am pleased to announce the new MarlinFX project I released 2 days ago
https://github.com/bourgesl/marlin-fx
MarlinFX is the JavaFX port of the Marlin renderer (scanline rasterizer
integrated in OpenJDK9) aimed to be faster than Open/Native Pisces (notably
for very complex paths: merge sort + optimized array copies and cleanup).
I tested in on both linux & windows 64bits (server JVM) and it is at least
as fast as OpenPisces or faster (javafx shape rasterization is single
threaded up to now but marlin scales very well). Of course, it is always
faster than native pisces on my machines.
- native pisces = 130fps
- open pisces = 150fps
- marlin-fx = 325fps
This test renders a very complex path so marlin-fx rocks in hard rendering
cases.
See https://github.com/chriswhocodes/DemoFX
stars = 170 fps
stars = 259 fps
This test case is very simple: see
http://youtu.be/N1rihYA8c2M
Setup: laptop zbook-15 (i7 4800 + nvidia Quadro K610M) on ubuntu 16.4 +
Oracle JDK 1.8.0_b102 (javafx) - VSYNC: OFF
Of course, there is lot of potential improvements in the JavaFX pipeline...
(multi-threading, inner/outer strokes...)
Finally I made a first step, and more benchmarks or test cases are needed
(I could port my MapBench tool) to get some realistic data.
Then how to go next, as there is no way to plug in such marlinFX in JavaFX
...
Could you have a look at the code (on my github) ?
I can make a webrev between openjfx and open jdk 9 if you prefer.
Cheers,
Laurent

Laurent Bourgès

2016-10-15 17:31:53 UTC

Permalink

Hi Kevin,

Post by Kevin Rushforth
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

Post by Kevin Rushforth
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

Markus KARG

2016-10-16 06:53:47 UTC

Permalink

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!

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?

-Markus

-----Original Message-----
From: openjfx-dev [mailto:openjfx-dev-***@openjdk.java.net] On Behalf Of Laurent Bourgès
Sent: Samstag, 15. Oktober 2016 19:32
To: Kevin Rushforth
Cc: Jim Graham; openjfx-***@openjdk.java.net
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX

Hi Kevin,

Post by Kevin Rushforth
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

Post by Kevin Rushforth
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

Laurent Bourgès

2016-10-16 07:29:05 UTC

Permalink

Mark,

Post by Markus KARG
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.

Post by Markus KARG
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

Kevin Rushforth

2016-10-17 14:41:45 UTC

Permalink

Hi Laurent,

Sure, we will share any benchmark results we have, although we likely
won't have too much time to spend on it in the near term, since we are
busily fixing bugs for JDK 9. As for getting this into JDK 9, it is way
too late for something of this scope. We are already past feature freeze
and are now in bug fix and stabilization mode. Yes, there is a process
where a few small enhancements might be considered [1], but even those
require JDK 9 release team approval, which is very unlikely for anything
that rises to the level of a new feature.

I hope JDK 10 won't take as long as JDK 9 is taking, but as there isn't
a proposed JDK 10 project yet, we don't know the timeline. I expect we
will know more in the next couple of months.

With strong encapsulation, the only way to access internal
implementation classes is via a command-line switch to add qualified
exports for the internal packages that you access. Note that any such
use of internal packages is fragile and could break at any time, but is
an option for applications that bundle a specific version of the JRE.

-- Kevin

[1] http://openjdk.java.net/projects/jdk9/fc-extension-process

Post by Markus KARG
Mark,

Post by Markus KARG
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.

Post by Markus KARG
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

Sven Reimers

2016-10-17 14:59:04 UTC

Permalink

Seeing that there is JEP about AOT showing a 9 in the release number just
published, Marlin-Renderer should not be so big...

-Sven

Post by Kevin Rushforth
Hi Laurent,
Sure, we will share any benchmark results we have, although we likely
won't have too much time to spend on it in the near term, since we are
busily fixing bugs for JDK 9. As for getting this into JDK 9, it is way too
late for something of this scope. We are already past feature freeze and
are now in bug fix and stabilization mode. Yes, there is a process where a
few small enhancements might be considered [1], but even those require JDK
9 release team approval, which is very unlikely for anything that rises to
the level of a new feature.
I hope JDK 10 won't take as long as JDK 9 is taking, but as there isn't a
proposed JDK 10 project yet, we don't know the timeline. I expect we will
know more in the next couple of months.
With strong encapsulation, the only way to access internal implementation
classes is via a command-line switch to add qualified exports for the
internal packages that you access. Note that any such use of internal
packages is fragile and could break at any time, but is an option for
applications that bundle a specific version of the JRE.
-- Kevin
[1] http://openjdk.java.net/projects/jdk9/fc-extension-process

Post by Markus KARG
Mark,

Post by Markus KARG
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.

Post by Markus KARG
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

Davide Malpassini

2016-10-18 10:47:04 UTC

Permalink

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

Kevin Rushforth

2016-10-19 12:34:02 UTC

Permalink

Jim Graham suggested the same thing to me privately, so he and Laurent
are currently looking into that possibility.

-- Kevin

Post by Davide Malpassini
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

Michael Paus

2016-10-19 13:07:04 UTC

Permalink

I'd appreciate such a solution too.

Michael

Post by Kevin Rushforth
Jim Graham suggested the same thing to me privately, so he and Laurent
are currently looking into that possibility.
-- Kevin

Post by Davide Malpassini
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

Markus KARG

2016-10-19 15:16:03 UTC

Permalink

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-***@openjdk.java.net] On Behalf Of Michael Paus
Sent: Mittwoch, 19. Oktober 2016 15:07
To: openjfx-***@openjdk.java.net
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX

I'd appreciate such a solution too.

Michael

Post by Kevin Rushforth
Jim Graham suggested the same thing to me privately, so he and Laurent
are currently looking into that possibility.
-- Kevin

Post by Davide Malpassini
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

Michael Paus

2016-10-20 07:44:13 UTC

Permalink

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

Post by 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-----
Sent: Mittwoch, 19. Oktober 2016 15:07
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX
I'd appreciate such a solution too.
Michael

Post by Kevin Rushforth
Jim Graham suggested the same thing to me privately, so he and Laurent
are currently looking into that possibility.
-- Kevin

Post by Davide Malpassini
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

Laurent Bourgès

2016-10-20 11:37:08 UTC

Permalink

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

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

Post by Markus KARG
-Markus
-----Original Message-----
Sent: Mittwoch, 19. Oktober 2016 15:07
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX
I'd appreciate such a solution too.
Michael

Post by Kevin Rushforth
Jim Graham suggested the same thing to me privately, so he and Laurent
are currently looking into that possibility.
-- Kevin

Post by Davide Malpassini
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

Kevin Rushforth

2016-10-20 12:34:26 UTC

Permalink

Post by Markus KARG
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.

Early benchmark results look very promising, too.

Post by Markus KARG
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...

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.

-- Kevin

Post by Markus KARG
Cheers,
Laurent

Michael

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

Post by Markus KARG
-Markus
-----Original Message-----

Behalf Of Michael Paus

Post by Markus KARG
Sent: Mittwoch, 19. Oktober 2016 15:07
Subject: Re: Fwd: Re: Marlin-Renderer and JavaFX
I'd appreciate such a solution too.
Michael

Post by Kevin Rushforth
Jim Graham suggested the same thing to me privately, so he and Laurent
are currently looking into that possibility.
-- Kevin

Post by Davide Malpassini
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

Laurent Bourgès

2016-10-21 16:51:45 UTC

Permalink

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.

Post by Kevin Rushforth
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...

Post by Kevin Rushforth
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

Laurent Bourgès

2016-11-02 21:54:11 UTC

Permalink

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=true if
(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

Sergey Bylokhov

2016-11-03 00:27:42 UTC

Permalink

Probably the logging should be enabled only if we pass the upper case
"True" to "-Dsun.javafx.marlin=True". I do not know is it correct to
write to the system output unconditionally, can this affect application?
And instead of "sun." can we use something different like "jdk." I guess
the same question can be applied to jdk?

Post by Laurent BourgÃ¨s
Jim,
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/
- 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
if (PrismSettings.doNativePisces) {
shapeRasterizer = new NativePiscesRasterizer();
} else {
// Enable Marlin-FX by setting -Dsun.javafx.marlin=true if
(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
-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

--
Best regards, Sergey.

Kevin Rushforth

2016-11-03 12:11:19 UTC

Permalink

Hi Laurent,

Great progress.

I agree with Sergey about avoiding unconditional logging, and about
wanting a different name for the property (work with Jim on the property
name).

Post by Laurent BourgÃ¨s
Does it look acceptable as a low risk RFE ?

I would need to see the final diff against FX 9-dev, but if the only
change to the current control flow in the existing logic is the
additional "if" test for the existence of the new property, and if the
Marlin code base itself is basically a copy of what is in Java2D, then I
think it is low-risk enough to propose it. I can't guarantee that it
will be accepted.

Post by Laurent BourgÃ¨s
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) ?

The former. It will add risk and complexity to wrap the version of
Marlin in Java2D for JDK 9.

Post by Laurent BourgÃ¨s
I can make separate patches for all these changes concerning jfx Path2D or
Marlin changes for OpenJDK9 first, then MarlinFX.

Please do file a new JBS bug for Path2D and let's fix that separately.
As a bug fix it will not need to go through the feature request
extension process.

Post by Laurent BourgÃ¨s
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.

We will need a patch based on FX 9 before we can propose this for 9, so
this sounds like a good plan.

Post by Laurent BourgÃ¨s
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 ...

I recommend whatever is easiest to get to a patch that will apply to FX
9-dev and build using JDK 9.

-- Kevin

Post by Laurent BourgÃ¨s
Probably the logging should be enabled only if we pass the upper case
"True" to "-Dsun.javafx.marlin=True". I do not know is it correct to
write to the system output unconditionally, can this affect
application? And instead of "sun." can we use something different like
"jdk." I guess the same question can be applied to jdk?

Post by Laurent BourgÃ¨s
Jim,
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/
- 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
if (PrismSettings.doNativePisces) {
shapeRasterizer = new NativePiscesRasterizer();
} else {
// Enable Marlin-FX by setting -Dsun.javafx.marlin=true if
(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
-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

Jim Graham

2016-11-03 21:40:51 UTC

Permalink

We currently control the configuration logging with prism.verbose, and
we already have a place in PrismSettings where we dump out the
configuration including which rasterizer we're using (native or
java-based) if verbose is set. We should probably consolidate this
along with the TODO to move the setting to PrismSettings.

With 3 choices it might make sense to use a "prism.rasterizerorder" type
of property like we use for the general pipeline (es2 d3d sw), but for
the sake of keeping the changes fairly localized, I'd recommend:

prism.marlinrasterizer=true|false
(overrides prism.nativepisces=true|false)

(It might seem natural to use "useMarlin" or something like that, but
most of the other prism.* settings in that file are of the form
"mechanism=true/false" to mean "useMechanism"...)

If set to true, use Marlin regardless of "nativepisces" value. If not
set to true, consult nativepisces or use the default as the code already
does. Also, change the print statement in the "verbose" block in that
same method to indicate we are using Marlin, printing out one of the
following:

"Using java-based Pisces rasterizer"
"Using native-based Pisces rasterizer"
"Using Marlin rasterizer"

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.

In MarlinProperties we should probably use prism.marlin.* as the prefix
for these settings to keep them isolated from the java2d settings...?

...jim

Post by Sergey Bylokhov
Probably the logging should be enabled only if we pass the upper case
"True" to "-Dsun.javafx.marlin=True". I do not know is it correct to
write to the system output unconditionally, can this affect application?
And instead of "sun." can we use something different like "jdk." I guess
the same question can be applied to jdk?

Post by Laurent BourgÃ¨s
Jim,
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/
- 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
if (PrismSettings.doNativePisces) {
shapeRasterizer = new NativePiscesRasterizer();
} else {
// Enable Marlin-FX by setting -Dsun.javafx.marlin=true if
(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
-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

Laurent Bourgès

2016-11-04 18:33:48 UTC

Permalink

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.

Post by Jim Graham
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

Jim Graham

2016-11-04 18:55:19 UTC

Permalink

Post by Laurent BourgÃ¨s
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...

...jim

Laurent Bourgès

2016-11-07 22:55:02 UTC

Permalink

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

Post by Jim Graham

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

Laurent Bourgès

2016-11-08 08:50:37 UTC

Permalink

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

Post by Jim Graham

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

Jim Graham

2016-11-09 23:47:37 UTC

Permalink

Hi Laurent,

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

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

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.

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?

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

...jim

Post by Laurent BourgÃ¨s
Jim,
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/
- 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
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

Post by Jim Graham

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

Laurent Bourgès

2016-11-10 13:35:49 UTC

Permalink

Jim,

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

Thanks.

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

Will fix and also remove all tile related properties.

Post by Kevin Rushforth
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.

Post by Kevin Rushforth
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/

Post by Kevin Rushforth
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

Jim Graham

2016-11-04 01:17:38 UTC

Permalink

There are basically 2 isolated changes to the existing code base and
then a set of added source files.

The first change is to use Marlin if the appropriate property is
specified, and those changes are very localized and easy to verify that
they won't hurt anything.

The second change is to modify the growth pattern of Path2D. While
these changes are live in AWT already and have already been code
reviewed, it would probably be better to submit them as a separate FX
fix if they are only performance oriented and not strictly required for
Marlin to function. That way we compartmentalize anything that could
possibly result in a regression into a separate bugid so we don't have
to pull everything if someone complains that the new growth pattern is
having negative consequences for their app. I doubt that will happen,
but it is simple enough to break them into 2 separate fixes so it
couldn't hurt to do that.

After that, this just boils down to adding a bunch of code that has
already been vetted elsewhere and a small and simple change to use it
only optionally and conditionally, which is a very low risk fix.

That would take this change from "no obvious drawbacks" to "obviously no
drawbacks" (or, more precisely, one "obviously no drawbacks" fix and one
related "no obvious drawbacks" fix)...

...jim

Kevin Rushforth

2016-11-04 15:21:02 UTC

Permalink

Hi Jim,

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.

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.

Thanks.

-- Kevin

Post by Jim Graham
There are basically 2 isolated changes to the existing code base and
then a set of added source files.
The first change is to use Marlin if the appropriate property is
specified, and those changes are very localized and easy to verify
that they won't hurt anything.
The second change is to modify the growth pattern of Path2D. While
these changes are live in AWT already and have already been code
reviewed, it would probably be better to submit them as a separate FX
fix if they are only performance oriented and not strictly required
for Marlin to function. That way we compartmentalize anything that
could possibly result in a regression into a separate bugid so we
don't have to pull everything if someone complains that the new growth
pattern is having negative consequences for their app. I doubt that
will happen, but it is simple enough to break them into 2 separate
fixes so it couldn't hurt to do that.
After that, this just boils down to adding a bunch of code that has
already been vetted elsewhere and a small and simple change to use it
only optionally and conditionally, which is a very low risk fix.
That would take this change from "no obvious drawbacks" to "obviously
no drawbacks" (or, more precisely, one "obviously no drawbacks" fix
and one related "no obvious drawbacks" fix)...
...jim

Post by Laurent BourgÃ¨s
Jim,
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/
- 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
if (PrismSettings.doNativePisces) {
shapeRasterizer = new NativePiscesRasterizer();
} else {
// Enable Marlin-FX by setting -Dsun.javafx.marlin=true if
(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
-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

Jim Graham

2016-11-04 19:15:33 UTC

Permalink

FX enhancement: https://bugs.openjdk.java.net/browse/JDK-8169270

...jim

Post by Kevin Rushforth
Hi Jim,
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.
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.
Thanks.
-- Kevin

Post by Laurent BourgÃ¨s
Jim,
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/
- 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
if (PrismSettings.doNativePisces) {
shapeRasterizer = new NativePiscesRasterizer();
} else {
// Enable Marlin-FX by setting -Dsun.javafx.marlin=true if
(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
-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

Laurent Bourgès

2016-11-04 19:48:10 UTC

Permalink

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

Jim Graham

2016-11-09 23:39:07 UTC

Permalink

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.

That's just for conversational purposes, I'm not proposing that we formalize those into formal project names, but this
will keep discussions smaller?

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?

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

Is your plan to propose a patch for Marlin2D soon?

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?

...jim

Laurent Bourgès

2016-11-10 13:29:16 UTC

Permalink

Jim,

Post by Jim Graham
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.

Post by Jim Graham
That's just for conversational purposes, I'm not proposing that we
formalize those into formal project names, but this will keep discussions
smaller?

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.

Post by Jim Graham
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.

Post by Jim Graham
Is your plan to propose a patch for Marlin2D soon?

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

Post by Jim Graham
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

Jim Graham

2016-11-09 23:30:29 UTC

Permalink

Post by Laurent BourgÃ¨s
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 ?

One of the big hurdles here is that Java2DMarlin is in a very large module in the JDK and we currently run independently
of it. We'd have to break Marlin out into a separate module shared by both and I think that is outside our scope right
now...?

...jim

Jim Graham

2016-11-09 23:27:48 UTC

Permalink

Post by Laurent BourgÃ¨s
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...

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.

Also, such a parallelization of the javafx pipelines would be a fairly large task.

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

...jim

Felix Bembrick

2016-11-09 23:57:14 UTC

Permalink

Post by Jim Graham

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.

Also, such a parallelization of the javafx pipelines would be a fairly large task.
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...?
...jim

Felix Bembrick

2016-11-10 00:02:23 UTC

Permalink

If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me.

If, of course, this email gets moderated...

Post by Jim Graham

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.

Also, such a parallelization of the javafx pipelines would be a fairly large task.
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...?
...jim

Tobias Bley

2016-11-10 07:35:09 UTC

Permalink

Do you have started any parallelization?

Post by Felix Bembrick
If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me.
If, of course, this email gets moderated...

Post by Jim Graham

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.

Also, such a parallelization of the javafx pipelines would be a fairly large task.
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...?
...jim

Tobias Bley

2016-11-10 10:56:42 UTC

Permalink

What about performance benchmark? Did you already tried to benchmark your prototype with DemoFX from Chris Newsland?

https://github.com/chriswhocodes/DemoFX <https://github.com/chriswhocodes/DemoFX>

Started? I have a fully working prototype!
And it's not just "parallelised" but it greatly improves the efficiency and utilisation of both the CPU (and cores) and the GPU(s).

Post by Tobias Bley
Do you have started any parallelization?

Post by Felix Bembrick
If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me.
If, of course, this email gets moderated...

Post by Jim Graham

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.

Also, such a parallelization of the javafx pipelines would be a fairly large task.
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...?
...jim

Laurent Bourgès

2016-11-10 11:15:50 UTC

Permalink

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

Felix Bembrick

2016-11-10 11:30:39 UTC

Permalink

If Oracle are interested in it (and permit me to be part of the JavaFX community on a level playing field), I would be more than happy to!

(Such as not having to wait for every post to be moderated for example).

Post by Tobias Bley
What about performance benchmark? Did you already tried to benchmark your prototype with DemoFX from Chris Newsland?
https://github.com/chriswhocodes/DemoFX <https://github.com/chriswhocodes/DemoFX>

Started? I have a fully working prototype!
And it's not just "parallelised" but it greatly improves the efficiency and utilisation of both the CPU (and cores) and the GPU(s).

Post by Tobias Bley
Do you have started any parallelization?

Post by Felix Bembrick
If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me.
If, of course, this email gets moderated...

Post by Jim Graham

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.

Also, such a parallelization of the javafx pipelines would be a fairly large task.
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...?
...jim

Laurent Bourgès

2016-11-10 13:04:47 UTC

Permalink

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

Laurent Bourgès

2016-11-10 13:13:20 UTC

Permalink

Jim,

Post by Jim Graham
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

Jim Graham

2016-11-10 18:35:05 UTC

Permalink

Another thought on multi-threaded scan-line rasterization would be to pre-scan the node tree and pre-rasterize all
shapes into masks before we run through and render them to the destination. Again, that would be outside the scope of
9, but it would be a change only to the rendering process (and dealing with the caching of alpha masks) that would
leverage your ability to create multiple Marlin contexts without any changes to MarlinFX...

...jim

Post by Jim Graham
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.
- 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