rendering artifacts with feBlend

[Frederik Elwert]

With Inkscape 0.47 on Ubuntu 9.10, I experience problems with the feBlend filter. I tested it a bit with the example graphic of the SVG 1.1 spec <http://www.w3.org/TR/SVG11/images/filters/feBlend.svg>. It turns out that while Inkscape seems to support blend modes in general, it often doesn’t render them correctly.

Attachment 1 shows Inkscape rendering the example image on screen. Only the “lighten” mode seems to work. As attachment 02 shows, it seems to be a problem of properly updating the image, since some parts of the image are properly rendered, while others are not. Updating the image, e.g. scrolling the drawing outside the visible canvas and back, causes the problem to appear on different parts of the image, seemingly random.

This also doesn’t only happen with on-screen rendering, but also with the bitmap export, as shown in the third attachment.

I don’t know if the graphics hardware is involved in this. I’m using an ATI Xpress 200M, with the radeon driver.

[su_v (suv-lp)]

Could you attach the SVG file as well?

[su_v (suv-lp)]

oops, sorry, missed the link.

[su_v (suv-lp)]

reproduced with Inkscape 0.47+devel r8930 on OS X 10.5.8

- rendering glitches also appear to depend on zoom level (to reproduce: use the scroll wheel of the mouse while hovering over the zoom entry box in the lower right corner and zoom in and out to see different variations of the rendering bug)
- bitmap export (90 dpi) shows the same error.

[su_v (suv-lp)]

This seems to be similar to or the same issue as described in bug #254321 in Inkscape: “feBlend rendering problem”, especially as noted in comment #4 "If the group containing the arrow and the circle is ungrouped, then the triangle renders correctly." applies here as well.

Bitmap image of the filter effect from the SVG specification:
<http://www.w3.org/TR/SVG11/images/filters/feBlend.png>

Attached: Bitmap export with Inkscape 0.48+devel r9673 on OS X 10.5.8 after ungrouping the text objects which have the feBlend filters applied (keep bug #243729 in mind when ungrouping filtered text objects).

[su_v (suv-lp)]

modified SVG source file (ungrouping of filtered objects)

[Jaspervdg (jaspervdg)]

I don't think this is necessarily the same issue as bug #254321 (at least not completely, there may be some overlap). In this bug there is a difference in how appearance of the effect across a single shape (which is likely to be a rendering bug), in the other bug it looks like it's mostly about Inkscape's support for enable-background and how the UI exposes this. Or am I missing something?

[su_v (suv-lp)]

I see the same rendering issue here as described in comment #4 of bug #254321 (including the same workaround).

[su_v (suv-lp)]

On 2/8/10 19:47, ~suv wrote:
> I see the same rendering issue here as described in comment #4 of bug
> #254321 (including the same workaround).

I stumbled over the issue while testing blending modes for recreating an
abstract CD-cover:

1) abstract-blending-4.svg
Using feBlend filters on objects which are on different layers (a layer
for each of the base colors used: yellow, purple, cyan) resulted in
incorrect rendering & artifacts depending on zoom level. Repainting the
canvas when panning sometimes restored the correct effect.
According to the manual, stack order should not make a difference when
using the blend modes multiply, screen, darken and lighten.

2) abstract-blending-4-layer-modes.svg
Using layer blend modes instead of applying the filter effect on the
individual objects works as expected and has no rendering errors or
artifacts on-canvas nor when exporting to bitmap.

3) abstract-blending-4-flat.svg
Using object filters with all objects within one layer or group (flat
structure) works without rendering errors and zoom-related artifacts
on-canvas and exports to bitmap as expected (producing the same visual
result as with using layer blend modes).

Note:
- All tests have 'enable-background' set to 'new' for the top-level
<svg> element.
- Adding 'enable-background:accumulate' on each layer in
'abstract-blending-4.svg' did not solve the rendering errors when
filtered objects are in different groups/layers and no layer blend modes
are used.

Is this the same issue as one of the two reports about the 'feBlend'
filter primitive (bug #502170, bug #254321) or should I file it separately?

[Jaspervdg (jaspervdg)]

Okay, it now looks like both issues are solved (see bzr revision #9685). But it's a little tricky as I'm not entirely sure why this solves the problem, so: any confirmation that you're not still seeing the same problems? (Also, with a bit of luck this kind of effect, using backgroundimage, is now a bit faster.)

[su_v (suv-lp)]

Fix tested and confirmed with Inkscape 0.48+devel r9685 on OS X 10.5.8:
All sample files attached to this report now render identically on-canvas and when exported to bitmap (don't know about other export formats: I have never succeeded to export any of the blend modes filter effects to PDF). I haven't yet tested with new drawings or other existing files which use feBlend filter primitives.

[jazzynico (jazzynico)]

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

[su_v (suv-lp)]

Reopening - broken again in current trunk:

Based on testing with available archived builds:
- Bitmap export broke in r10451 (Merge SPCanvasArena caching layer work)
- Rendering of filtered text in r10581 (Merge rendering cache branch (GSoC 2011))
  (the text is not rendered at all)
- Rendering of filtered text apparently partially fixed in r10620
  (the filtered text is rendered but not as expected and as in older revisions (before r10541)

Current revision 10682 doesn't render it nor export it to bitmap correctly:
Compare attached exported bitmap (identical to on-canvas rendering) with the reference image of the SVG specification:
<http://www.w3.org/TR/SVG11/images/filters/feBlend.png>

[su_v (suv-lp)]

> Reopening - broken again in current trunk:

Reconsidered -> the issue seems limited to text objects. Will further investigate and file separate report.