[OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised

[Jim Graham]

Whoops!  I abbreviated and sent you off on a wild goose chase.

There are many different loops!

There just happen to be (I think!?) only 1 kind of *TEXT* loop in the 
system for a given surface.  I left out that qualifier below and 
misdirected you.

Thus, if the text loops were split out then it "may be" that they can be 
created once per SurfaceData, but that is definitely *NOT* true of the 
other loops that reside in the RenderLoops, and it may not be true of 
the text loops in the future, it just happens to be "probably" true for 
text loops for now...

			...jim

Roman Kennke wrote:
> Hi Jim,
> 
> If only one instance of the loops is used during the lifetime of a 
> Surface, then we can easily keep this instance there instead of the 
> SG2D, validating would not initialize any new objects, but only put 
> stuff together that is already present in the SurfaceData anyway. Or did 
> I get something wrong here?
> i
> / Roman
> 
> Jim Graham wrote:
>> That makes a lot of sense since I think the introduction of the 
>> GlyphListLoopPipe in its current form was where the original 
>> methodology of "always install loops if you plan to use loops" was 
>> first (and only time) violated.
>>
>> I think I raised the issue at the time and Phil pointed out that, in 
>> practice, the loops never really change for a given surface type (as 
>> in, if a different compositing mode is set or if a non-color paint is 
>> set then we use entirely different mechanisms to render so the only 
>> loops that exist for these are "solid color" loops and those loops are 
>> always valid for all cases that use these pipes).
>>
>> While that may mean we don't have a practical bug yet, the weakness of 
>> that argument in general, and the desire to resolve the issue from the 
>> original bug report may mean we should revisit this practice.
>>
>> One solution would be to always set the loops for the validations that 
>> install one of these pipes.  That could have potential performance 
>> impact, but it would be no worse than the validation sequences that 
>> already set the loops every time so I don't think it would be serious, 
>> or even measurable.
>>
>> Another solution could involve splitting these loops out into a 
>> separate structure that can be set once in the lifetime of an SG2D and 
>> then reused as appropriate.  But this is banking on the "only one 
>> version of these loops really exists anyway" constraint and some day 
>> that constraint is likely to disappear and then we really will need to 
>> pick new loops on every validate.
>>
>> As such, I think I'd prefer the first solution - to just pick new 
>> loops every time they are needed (i.e. unless the pipeline really 
>> doesn't use the loops directly, or indirectly through these text 
>> pipes)...
>>
>>             ...jim
>>
>> Mario Torre wrote:
>>> Il giorno gio, 18/06/2009 alle 00.34 +0200, Mario Torre ha scritto:
>>>
>>>> But I'll debafterug it a little further and send you some updates asap.
>>>>
>>>> Cheers,
>>>> Mario
>>>
>>> Hello!
>>>
>>> The pipelines that use a loops after being invalidated without checking
>>> if it's valid or not (null) are those so far:
>>>
>>> LCDTextRenderer
>>> GlyphListLoopPipe
>>> AATextRenderer
>>>
>>> Those all are subclasses of GlyphListLoopPipe.
>>>
>>> The LCDTextRenderer never fails if I don't explicitly set to null the
>>> loops in invalidatePipe, same happens for instances of GlyphListLoopPipe
>>> which don't fail immediately as when I set the loops to null, so I think
>>> some of those calls use loops there were initialised somehow from
>>> validatePipe in some previous call to this method, but that should not
>>> be valid anymore.
>>>
>>> There are no other places where I get NPE, but I've tested only with the
>>> Java2D demo so far.
>>>
>>> Cheers,
>>> Mario
>