[OpenJDK Rasterizer] Marlin renderer contribution for review

[Jim Graham]

Hi Laurent,

I'm not sure how my approach would impact the number of calls to 
TL.get().  TL.get() is used to get the RC instance.  That must be done 
before either code can be executed.  After TL.get() you then either do 
one of the following:

Renderer r = rdrCtx.renderer.init(...);

or:

Renderer r = rdrCtx.getRenderer(...<same args>...);

In both cases, rdrCtx came from somewhere prior and I see no call to 
TL.get() in either calling sequence.

The distinction is that in the first case rdrCtx is just used to hold a 
bare field which exposes the specific mechanism of caching (i.e. we 
cache a single reference and there it is), and we add an init call to 
Renderer that returns a value even though the typical design of an 
"init()" call tends to not return a value.  In the second case, the 
RenderContext class takes a more active role in how cached Renderers are 
managed internally (even if it really is just a single cached reference 
for now) and the RenderContext object supplies a getRenderer() method 
whose return value makes sense because it is a getter method...

			...jim

On 3/19/15 10:09 AM, Laurent Bourgès wrote:
> Jim,
>
>> I would have solved this by having a RenderContext.getRenderer(clip, rule) method in which case you would write:
>>
>> r = rdrCtx.getRenderer(clip.getLoX(), ..., pi.getWindingRule());
>>
>> RenderContext.getRenderer() would initialize the renderer and return it.  In the general case, that leaves the RenderContext object open to new ways to manage cached instances in the future should our needs change since the cache management logic is internal to the object...
>
> It looks better but in practice there are many other reused instances in
> a RendererContext that need initialization too.
>
> For performance my current approach make a single call to
> getRendererContext () that uses TL or CLQ for context storage and
> handles once the liveness check: Hard / Soft / Weak references.
>
> I wonder if your approach would lead to many calls to TL.get () ...
>
> I agree it is not very clean but just efficient.
>
> Laurent
>