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
