Top layer, Blend mode is multipy, Pattern disappear

[pRototype]

OS: Both XP and W7 affected
Inkscape 0.48+devel r10627

Steps to reproduce:
* New document
* Make two layers, Layer1 and Layer2 where Layer2 is the upper one.
* Set Layer2 blend mode to "multiply".
* Draw an object (or add picture) in Layer2
* Convert that object into pattern.

The pattern will now disappear. It should stay visible, and to get it visible, I found two ways to achieve that:
* Select the invisible object/pattern and move it
* Change Layer2 blend mode to something else.

[su_v (suv-lp)]

Not reproduced with Inkscape 0.48.2
Reproduced with r9598 (cairo-rendering branch) and 0.48+devel r10634

Objects converted to pattern inside filtered groups (or layers) are initially not rendered on-canvas.

[su_v (suv-lp)]

To confirm a regression with the new renderer:
Not reproduced with Inkscape 0.48+devel r10325 (last revision before the merge of the cairo-rendering branch).

(All tests done on Mac OS X 10.5.8 (i386))

[su_v (suv-lp)]

Does not depend on specific filter effect, test attached sample with the same Gaussian blur effect applied to a
a) path
b) group

If the path inside the blurred group is convert to a pattern, it initially disappears from the canvas.

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 11649.

[Martin Owens (doctormo)]

There's a quicker way to get this bug to rear. Just try and group some objects in a multiplied layer.

[Martin Owens (doctormo)]

This bug is beating me. I wonder if we can get some of the feBlend experts to have a look. For now I'm resetting stats.

[Krzysztof Kosinski (tweenk)]

This bug is caused by an interaction between finding the bounding box and updating the group that exposes bugs in shape implementations.

When a new group is created, its SPGroup::update() method chains up to SPItem::update() before updating the children. If the group is filtered, SPItem::update() needs to find the group's bounding box to compute the filter region, and so calls visualBounds(). This in turn calls the children's SPItem::bbox() virtual function. SPShape::bbox() uses _curve to compute the bounding box. Unfortunately, most shape implementations only set _curve from their parameters when update() is called on them, and do not reimplement SPItem::bbox(). As a result, the group receives an empty bounding box and sets that as the filter region, which causes the group to disappear until updateDisplay() is called again.

This bug can be fixed in 3 ways:
1) Update _curve in shape implementations in response to the set() virtual method.
2) Provide implementations fo bbox() that do not rely on _curve.
3) Last resort hack: chain up twice in SPGroup::update(), once at the beginning and once at the end. This might break various other things.

[Krzysztof Kosinski (tweenk)]

PS: it might also be possible to fix the breakage which happens when the chain-up in SPGroup::update() is moved to the bottom of the function (filter region of the group does not update when the group is moved). This would be the ideal solution.

[Krzysztof Kosinski (tweenk)]

Should be fixed in r12643.