You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2001/01/16 23:47:23 UTC

[Regression] feDisplacementMap

Hi all,

   This is more or less to document a regression in feDisplacementMap.
If I had to guess I would put the blame on me, but who knows.  Here is
the stack trace (looks nasty, something is blowing up in the g2d
renderer, ugg! - bad transform?)

svgviewer:
     [java] java.lang.NullPointerException
     [java]     at sun.java2d.loops.LockableRaster.findRasterType(LockableRaster.java:226)
     [java]     at sun.java2d.loops.LockableRaster.<init>(LockableRaster.java:84)
     [java]     at sun.java2d.loops.RasterOutputManager.compositePaintLoop(RasterOutputManager.java:801)
     [java]     at sun.java2d.pipe.AlphaPaintPipe.renderPathTile(AlphaPaintPipe.java:71)
     [java]     at sun.java2d.pipe.SpanClipRenderer.renderPathTile(SpanClipRenderer.java:103)
     [java]     at sun.java2d.pipe.DuctusShapeRenderer.renderPath(DuctusShapeRenderer.java:107)
     [java]     at sun.java2d.pipe.DuctusShapeRenderer.fill(DuctusShapeRenderer.java:52)
     [java]     at sun.java2d.pipe.ValidatePipe.fill(ValidatePipe.java:115)
     [java]     at sun.java2d.SunGraphics2D.fill(SunGraphics2D.java:1616)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteFillShapePainter.paint(ConcreteFillShapePainter.java:44)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteCompositeShapePainter.paint(ConcreteCompositeShapePainter.java:62)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteShapeNode.primitivePaint(ConcreteShapeNode.java:108)
     [java]     at org.apache.batik.refimpl.gvt.filter.ConcreteGraphicsNodeRable.createRendering(ConcreteGraphicsNodeRable.java:230)
     [java]     at org.apache.batik.refimpl.gvt.filter.ConcreteAffineRable.createRendering(ConcreteAffineRable.java:99)
     [java]     at org.apache.batik.refimpl.gvt.filter.ConcretePadRable.createRendering(ConcretePadRable.java:128)
     [java]     at org.apache.batik.refimpl.gvt.filter.ConcretePadRable.createRendering(ConcretePadRable.java:128)
     [java]     at org.apache.batik.refimpl.gvt.filter.ConcreteDisplacementMapRable.createRendering(ConcreteDisplacementMapRable.java:189)
     [java]     at org.apache.batik.util.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:250)
     [java]     at org.apache.batik.util.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:203)
     [java]     at org.apache.batik.util.awt.image.GraphicsUtil.drawImage(GraphicsUtil.java:242)
     [java]     at org.apache.batik.refimpl.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:453)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteCompositeGraphicsNode.primitivePaint(ConcreteCompositeGraphicsNode.java:128)
     [java]     at org.apache.batik.refimpl.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:418)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteCompositeGraphicsNode.primitivePaint(ConcreteCompositeGraphicsNode.java:128)
     [java]     at org.apache.batik.refimpl.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:418)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteCompositeGraphicsNode.primitivePaint(ConcreteCompositeGraphicsNode.java:128)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteCanvasGraphicsNode.primitivePaint(ConcreteCanvasGraphicsNode.java:77)
     [java]     at org.apache.batik.refimpl.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:418)
     [java]     at org.apache.batik.refimpl.gvt.ConcreteCompositeGraphicsNode.primitivePaint(ConcreteCompositeGraphicsNode.java:128)
     [java]     at org.apache.batik.refimpl.gvt.AbstractGraphicsNode.paint(AbstractGraphicsNode.java:418)
     [java]     at org.apache.batik.refimpl.gvt.renderer.StaticRenderer.repaint(StaticRenderer.java:207)
     [java]     at org.apache.batik.refimpl.util.JSVGCanvas$RenderBufferAOIRunnable.run(JSVGCanvas.java:1204)
     [java]     at java.lang.Thread.run(Thread.java:484)

Re: [Regression] feDisplacementMap

Posted by Vincent Hardy <vh...@eng.sun.com>.
Thomas,

Thanks again for tracking this one down. Given your description of 
the situation, I would go with the second option you list (using 
TileRed directly) and get rid of the AOI hint altogether as it is
brittle and will come back to bite us.

I will add a bug in bubzilla to that effect (under my name).
V.

Thomas E Deweese wrote:
> 
> >>>>> "TD" == Thomas E Deweese <th...@kodak.com> writes:
> 
> TD>    This is more or less to document a regression in
> TD> feDisplacementMap.  If I had to guess I would put the blame on me,
> TD> but who knows.  Here is the stack trace (looks nasty, something is
> TD> blowing up in the g2d renderer, ugg! - bad transform?)
> 
>     This is mostly directed at Vincent.
> 
>     This bug does still exist and I have tracked this down to the
> ConcretePatternPaintContext.  The problem is that
> ConcretePatternPaintContext.getRaster sometimes returns null.  The
> reason and how to fix it are much more complex.
> 
>     The PatternPaint stuff bases it's self on the AOI during the
> render, this is in an attempt to avoid generating lots of data that
> isn't needed.  However The GraphicsNodeRable wasn't updating the AOI
> Hint when it constructed it's Graphics2D to call the paint method for
> the Patterned rectangle.
> 
>     This means that the AOI was the same one that was used at the
> start of the rendering chain, so it didn't account for the growth of
> the AOI due to the needs of feDisplacementMap (it can pull data that
> was out of bounds into the rendering bounds).
> 
>     I have fixed GraphicsNodeRable8bit so it updates this hint.  This
> has fixed the bug and made feDisplacementMap behave correctly when the
> displaced object is partly off screen.  However I have concerns about
> this hint in general:
> 
>      1) Don't we need to ensure that anyone who adjusts the usr2dev
>         transform adjusts this hint?  Hard to do now, and _very_ hard
>         to ensure into the future (in fact I'm guessing adding a few
>         transform attributes into the chain will blow the current
>         code out of the water).
> 
>      2) Would it be better to replace the use of TileRable (Which
>         needs a good estimate of the needed tiled area) with TileRed
>         which only ever generates the areas requested (which means
>         that we can setup TileRed to cover the entire bounding box of
>         the filled object and AOI processing will just "drop out").
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

[Regression] feDisplacementMap

Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TD" == Thomas E Deweese <th...@kodak.com> writes:

TD>    This is more or less to document a regression in
TD> feDisplacementMap.  If I had to guess I would put the blame on me,
TD> but who knows.  Here is the stack trace (looks nasty, something is
TD> blowing up in the g2d renderer, ugg! - bad transform?)


    This is mostly directed at Vincent.

    This bug does still exist and I have tracked this down to the
ConcretePatternPaintContext.  The problem is that
ConcretePatternPaintContext.getRaster sometimes returns null.  The
reason and how to fix it are much more complex.

    The PatternPaint stuff bases it's self on the AOI during the
render, this is in an attempt to avoid generating lots of data that
isn't needed.  However The GraphicsNodeRable wasn't updating the AOI
Hint when it constructed it's Graphics2D to call the paint method for
the Patterned rectangle.

    This means that the AOI was the same one that was used at the
start of the rendering chain, so it didn't account for the growth of
the AOI due to the needs of feDisplacementMap (it can pull data that
was out of bounds into the rendering bounds).

    I have fixed GraphicsNodeRable8bit so it updates this hint.  This
has fixed the bug and made feDisplacementMap behave correctly when the
displaced object is partly off screen.  However I have concerns about
this hint in general:

     1) Don't we need to ensure that anyone who adjusts the usr2dev
        transform adjusts this hint?  Hard to do now, and _very_ hard
        to ensure into the future (in fact I'm guessing adding a few
        transform attributes into the chain will blow the current
        code out of the water).

     2) Would it be better to replace the use of TileRable (Which
        needs a good estimate of the needed tiled area) with TileRed
        which only ever generates the areas requested (which means
        that we can setup TileRed to cover the entire bounding box of
        the filled object and AOI processing will just "drop out").