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

[Philip Race]

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