Marlin renderer patches for jdk8u integration
Hohensee, Paul
hohensee at amazon.com
Sat Jan 18 01:07:57 UTC 2020
Fwiw, backporting Marlin meets my criterium for a major feature backport, namely that there are commercially supported implementations used in production. That means there's a risk of fragmentation if we don't upstream it, and that the reliability risk is reasonably low because it's battle-tested. Compare against aarch64 and Shenandoah, both of which I support for the same reason.
Thanks,
Paul
On 1/17/20, 4:25 PM, "jdk8u-dev on behalf of Laurent Bourgès" <jdk8u-dev-bounces at openjdk.java.net on behalf of bourges.laurent at gmail.com> wrote:
Hi Andrew,
Marlin renderer provides better performance (mean: 2x faster, up to 4x in
complex cases) over Pisces and higher quality, see my talk:
https://github.com/bourgesl/bourgesl.github.io/raw/master/javaone2017/slides/javaone-marlin-talk.pdf
Benchmark results start at slides 27.
And azul blog post (latency study):
https://www.azul.com/performance-rendered-visual/
Marlin rdr code resides in the marlin package and can be viewed as a Pisces
rewrite with very low overlap, like a jdk plugin: it is loaded by the
ServiceLoader in jdk8 from the java2d RenderingEngine class.
Github releases are used for years by the GeoServer community with openjdk
8.
Azul Zulu8 binary release provide zulu8 with Marlin rdr enabled for several
years.
It is also integrated in JetBrains JRE that powers IntelliJ & PyCharm... as
I did provide PRs on github.
If you need, I can give more details.
PS: please tell me if it is worth my free time to prepare patches, RFR...
Cheers,
Laurent
Le ven. 17 janv. 2020 à 16:05, Andrew Haley <aph at redhat.com> a écrit :
> On 11/2/19 12:43 PM, Laurent Bourgès wrote:
> > Finally I am ready to work with any jdk8u reviewer on the formal review
> > process (jdk8u label, individual patch RFR...).
> > Let me know how to proceed. Who could help me on the reviews and run
> > validation tests...
> >
> > Question: do you agree to enable the Marlin renderer by default in
> OpenJDK8
> > ? or prefer staying with the former Pisces renderer ? It consists in a
> few
> > line change in the RenderingEngine class.
>
> I'd like someone to explain the justification for this backport. Given the
> amount of churn, this should not be approved without a convincing argument.
>
> --
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
More information about the jdk8u-dev
mailing list