feBlend rendering problem

[Will Pittenger]

Please examine the attached image. Notice Turn 2 (with the circle). The circle is in FRONT of the yellow line with both in the same layer. But the yellow is on top of the circle's stroke. I can show the circle is indeed on top because the fill is on top of the line.

Somewhere, something about this image is confusing Inkscape. To really show how confused it gets, move the circle's group (includes the arrow nearby) so that the arrow is over the yellow line. Inkscape will be unable to decide whether to put the arrow over or below the line. There is just one line. But Inkscape acts like there is two.

[Will Pittenger (will-pittenger1)]

Sorry. Turn 2 is fine. It's Turns 1 and 4 that are over the lines.

[sas (sas-sas)]

The circle has a filter on it which sets the blending mode set to "screen". This means that the white part (the fill) will always be white, but the black part (the stroke) will disappear against opaque backgrounds. (In fact, the stroke is not quite black, and you can see it in ghost form against the yellow line if you look closely.) So, no problem here.

But the arrow really does suffer from rendering problems when moved over the yellow line - the rendering is different at different zoom levels. This arrow uses the same filter as the circle, so the yellow line (and its white edge) should be fully visible through the arrow. It works correctly if the object is ungrouped.

[sas (sas-sas)]

Here's a simplified file showing the problem. The triangle (with an feBlend filter) renders incorrectly over the yellow line, and the rendering depends on zoom level. If the group containing the arrow and the circle is ungrouped, then the triangle renders correctly.

[Jaspervdg (jaspervdg)]

Amazingly enough the test file posted above is probably rendered correctly, if I interpret the SVG specification correctly at least... This seems to be a particularly strange part of the specification, intended to make renderers more efficient. See http://www.w3.org/TR/SVG11/filters.html#AccessingBackgroundImage

However, with an enable-background:new on the svg element and an enable-background:accumulate on the group that contains the triangle it still doesn't work, so I suppose the real bug here is in the support of enable-background. (And perhaps the UI that probably doesn't make this very easy on the user.)

I've put a test case in SVN (with a pass and a fail reference), see http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html (it's bug254321.svg, which is nearly identical to the file posted earlier).

[su_v (suv-lp)]

Changing status to 'Confirmed' - see comment #5

[su_v (suv-lp)]

Possibly same or similar issue reported in bug #502170 "rendering artifacts with feBlend ".

[su_v (suv-lp)]

Rendering errors of objects with a feBlend filter inside a group (depending on zoom level) as described in and attached to comment #4 no longer reproduced with Inkscape 0.48+devel r9685 on OS X 10.5.8.

The rendering of the racetrack of the original reporter (comment #1) is also correct with Inkscape 0.48+devel r9685 (assuming the blending mode 'Screen' is intentionally used for the labels [circle+arrow] of the turns).

[jazzynico (jazzynico)]

Setting milestone to 0.49.
Feel free to change it again if you commit the fix to the 0.48.x branch.