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

[gerard ziemski]

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