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

[Jim Graham]

Hi Gerard,

Marlin was developed as an evolution of Pisces when neither Ductus or 
Pisces performed well in an MT server environment.  Laurent then set out 
with Pisces as a starting point to make one that worked in an 
MT-scalable manner and enhanced all aspects of its performance in the 
process.  It was already being offered as a 3rd party alternative plugin 
that had already met those goals.

Nobody said "we need the renderer to meet these numeric goals", they 
simply said "Pisces is bad in these areas and lets see what we can do 
about it".

We are integrating it already having bested Pisces in every way except 
for exposure (in terms of bugs that are found when something is used in 
the field over time).  Even then, it has had a bit of use in the field 
in limited use as a plugin 3rd party replacement so even that drawback 
is arguable.

It also already blows away Ductus in MT scalability, but it hasn't quite 
yet beaten Ductus in single threaded performance.  The only reason we 
list beating Ductus as an optional goal is that it would let us drop 
it's closed source implementation and reduce our proprietary 
technologies by 1, but Marlin wasn't created specifically to achieve 
that (it was more like a goal on the horizon to aim for).  While we are 
preparing it for integration we are starting with a base that already 
met most of its stated goals and we're simply seeing how much more we 
can get out of it (as well as cleaning up various contributed code style 
and maintainability issues).

This isn't an issue of "we are changing the renderer period" - this is a 
"we are changing the renderer because we need one that meets these 
performance goals and btw, we have one called Marlin that already meets 
them which is why we are integrating it"...

			...jim

On 9/1/15 12:19 PM, gerard ziemski wrote:
> hi Phil.
>
> I'm not challenging the JEP nor attempting to change its scope. I am
> genuinely interested in more technical details on how Merlin is
> achieving the promised, though not exactly stated, improvement. I wish
> there was bit more technical detail explaining how it offers the
> performance other than nebulously saying that it uses threads. I also
> offered some background that I believe could be considered in adding to
> the "Alternatives" section.
>
> But maybe I misunderstood the JEP - if all that it's stating is that we
> are changing the renderer period, on assumption that the technical
> review of the new renderer's merits has been already done, then this JEP
> is rather straightforward and requires no more discussion.
>
>
> cheers
>
>
> On 09/01/2015 01:47 PM, Philip Race wrote:
>> All,
>>
>> The scope of this JEP is already set.
>> Marlin originally started from (forked) the pisces code and for JDK 9
>> is intended as a
>> drop-in replacement which addresses performance problems seen relative
>> to the closed ductus.
>> This is not just a client-side library. Server-side software rendering
>> will benefit
>> greatly from any MT boost.
>>
>> To further continue any technical discussion on this or future directions
>> I think it is best to move over to gr-dev at openjdk dot java dot net.
>>
>> -phil.
>>
>> On 9/1/15, 9:47 AM, gerard ziemski wrote:
>>>
>>> hi Laurent,
>>>
>>>>> #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.
>>>
>>> Are we saying that the way Merlin uses threads is only for offscreen
>>> rendering (ie. BufferedImages)? So an app that
>>> renders directly to the screen will not see any performance improvement?
>>>
>>> Do we create a rendering thread per offscreen? Is there any cap on
>>> how many of those threads we are allowed to create?
>>> Are we aware of any use cases where this approach results in lowered
>>> performance (an app creating new BufferedImage
>>> every frame - old good Plasma benchmark)?
>>>
>>>
>>>
>>>>> #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.
>>>
>>> There is a rich history of people trying to use GPUs in order to
>>> accelerate Java2D. Back in around 2000 while I was at
>>> Apple, John Burkey and I implemented OpenGL based renderer that
>>> successfully worked for specific use cases: apps using
>>> lots of static images, non path based primitives and text using
>>> cached bitmapped for Apple's own JDK implementation,
>>> which we shipped.
>>>
>>> Later, Chris Campbell, back then at Sun Microsystems, did a similar
>>> implementation (which also used Windows D3D) for
>>> Sun's own JDK, which also shipped.
>>>
>>> 5 years ago, I along with Chris Oliver, Ken Russell, Anthony Rogers
>>> and Sven Goethel (of jogl fame) implemented
>>> SlimShady - a 2D resolution independent renderer leveraging GPU for
>>> JavaFX, which was later replaced by Prism, by
>>> Chris Campbell, Kevin Rushford, Jim Graham, Morris Mayer and others
>>> including myself.
>>>
>>> So yeah, lots of people tried, with some success, to do Java2D on GPU
>>> :-)
>>>
>>>
>>> cheers
>>
>>