JEP submitted: Update Java2D to use the Marlin Renderer as the default Graphics Rasterizer

[Laurent Bourgès]

Gerard,

Here are my comments:

2015-08-31 17:29 GMT+02:00 gerard ziemski <gerard.ziemski at oracle.com>:

> It's very exciting to see that we're addressing the performance issues of
> our currently existing Pisces 2D engine.
>

Thanks for your interest. FYI I am working on Marlin (improving Pisces) for
2 years and since march 2015, I am working with Jim Graham & Phil race to
its openjdk integration as a standalone pure java renderer to add it easily
into OpenJDK 9 asap.

>
> I'm not sure how detailed we want to have the JEP, but the following are
> the issues I would love to see the JEP go into a bit more detail:
>
> #1 In the "Success Metrics" we say "significantly outperforms", but we're
> not committing to any hard numbers - do we have an expectation on how much
> better the new engine will be, that can be stated? Especially since we
> claim that the development version already meets this goal?
>

We deliberately gave no numbers: Marlin is already faster than Pisces in
all Map rendering benchmarks I made and often as fast or faster than ductus
(closed source's Oracle JDK renderer):
=> my goal is to achieve at least ductus's single-threaded performance but
with very good scalability.

FYI here is a comparison report made in february 2015 (Marlin 0.5.6) before
starting the integration process:
http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/2015-March/000077.html

These benchmark results use my MapBench tool that perform map rendering
using draw/fill(Path2D).


>
> #2 What is the expected CPU usage allowed when scaling up in a
> multi-threaded environment - 2 threads probably do not mean 2x performance?
> Is Merlin allowed to use all threads, or does it have a limit on how many
> will be used? Can/should this be controlled via some sort of a runtime flag
> available to developers?
>

Marlin has a very low memory footprint (low GC overhead) and uses a
rendering context per thread => it does perform any thread management but
is purely thread safe (ThreadLocal storage).
MT support means that Marlin supports well parallel rendering requests like
in a map web server: each server thread can perform Graphics2D rendering
(using Marlin) on its own BufferedImage at maximum performance.


>
> #3 Is Merlin's quality and accuracy high enough that it could one day
> replace the font rendered as well?
>

It is still not good enough for font rendering: mainly 8x8 supersampling
with proper subpixel alignment.
However, I expect in the future to implement Exact Pixel Coverage (like
freetype or agg) that would provide higher accuracy.


>
> #4 Is Merlin performing well on both desktop and mobile platforms? Is such
> platform separation still needed?
>

 I only made benchmarks on desktop platforms.


> #5 Would it be helpful to find an external use case scenario, in addition
> to the internal ones (ie. Pisces and Ductus), such as the performance of
> Adobe's Flash to compare Merlin's performance?
>

Why not ?

FYI, I developped also a map rendering benchmark tool to perform both
regression tests and benchmarks on real-application datasets provided as
serialized drawing commands.

 I could improve it to use other input formats (or just convert them) to
let us perform comparisons with other benchmark tools.


>
> #6 In the "Alternatives" section, shouldn't we at least mention a GPU
> based 2D rendering?
>

Probably.
However, I do not know any RenderingEngine implementation based on GPU yet.

Cheers,
Laurent