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

[Roman Kennke]

Hi everybody,

> I go back to my previous comment that perhaps what we need is for 
> invalidatePipe to set the loops to null and then fix all the places 
> where we were relying on "old loops" by setting them intentionally in 
> the corresponding validate sequences...

I am completely in favour of that approach, even if it costs more time 
(after all, it's Mario's time in the end ;-) ). Relying on some more or 
less random old loop hanging around is asking for bugs, the subtle kind, 
  those that eat up all your time when the next deadline is lurking 
around the corner... ;-)

/ Roman


> 
>             ...jim
> 
> Phil Race wrote:
>> I don't think it is related to the LCD text work. I think it was the 
>> JDK 7 b17 fix:
>> 6263951: Java does not use fast AA text loops when regular AA hint is 
>> set.
>> So there's a requirement that renderLoops is non-null in some case when
>> they would not previously have been used.
>>
>> -phil.
>>
>> Jim Graham wrote:
>>> Ah, I think I see the problem.  Phil can chime in here if I'm wrong.
>>>
>>> Text now uses loops in most cases, but many of the validate methods 
>>> assume that they don't need the loops.  I don't think that used to be 
>>> the case, but it changed as a result of the LCD text loop work.  It 
>>> used to be that AA used the alphafill field of SG2D and not the 
>>> loops, and it still does for most rendering.  But now text rendering 
>>> will almost always go through the loops and it is only working 
>>> because of that call to getRenderLoops() in the constructor (and the 
>>> fact that we never set it back to null.
>>>
>>> I'd like to see invalidate() set the loops to null and see how far we 
>>> get - I'll bet that we'd get NPEs all over the place, especially with 
>>> AA rendering.
>>>
>>> In the long run, this is another straw on the camel's back as far as 
>>> rethinking the validation framework.  It's been tweaked and hacked 
>>> quite a lot over the past 10 years and so there are a lot of issues 
>>> that arise like this that aren't readily obvious from the code.  I 
>>> don't think the camel's back is broken yet, but it is becoming more 
>>> and more confusing for new engineers to start tinkering with it 
>>> without seeing things break from seemingly innocuous changes.  :-(
>>>
>>> For now, I'm wary of removing that call without a lot of testing.  I 
>>> think putting a "loops=null" line in invalidatePipe() might 
>>> accelerate some of that testing, though.
>>>
>>> And Phil might want to chime in with a description of the new 
>>> requirements on loops in light of the post-LCD text work...  Phil?
>>>
>>>             ...jim