Inkscape

inconsistent behaviour of visual bbox width at different levels of blur % (regression)

Bug #1171208 reported by Alvin Penner
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Alvin Penner

Bug Description

the relationship of the visual bbox width to the blur % is not linear.
The attached file has a box of width 200. When using the Fill and Stroke dialog to increase the blur %, the following relationship is obtained between % blur and actual bbox width.

blur% bbox width measured
0 200
1-5 240
6 220
11 240
17 260
22 280
27 300

The behaviour at large % is linear, it is only the behaviour in the range 0 to 6 % that is unexpected. The bbox first expands, then contracts, then expands again, as the % is increased from 0.

- reproduced on Inkscape rev 12287
- not reproduced on Inkscape 0.48.4

Revision history for this message
Alvin Penner (apenner) wrote :
Revision history for this message
jazzynico (jazzynico) wrote :

Confirmed on Windows XP, Inkscape trunk revision 12296.
Not reproduced with 0.48.4.

tags: added: filters-svg
tags: added: regression
Changed in inkscape:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
su_v (suv-lp) wrote :

> Confirmed on Windows XP, Inkscape trunk revision 12296.
> Not reproduced with 0.48.4.

Not reproduced with r10588,
reproduced with r10589 and later revisions

AFAIU trunk now always uses the default minimal fallback FER size (120%) for the visual bbox of blurred objects unless one blurred dimension exceeds that default value of ±10% respectively 120% [*]: in this case Inkscape adds all coordinates and dimensions for the filter effects region explicitly to the filter definition, and thus uses it for the visual bbox as well (causing the reported inconsistency for non-square objects).
Before the removal of libnr, the dimensions of the visual bbox of blurred objects apparently used calculated values which matched the actual dimensions of the blurred object (even though no coordinates and dimensions for the FER are stored in the filter definition itself). At the time, AFAICT this could result in a different inconsistency because for other filter primitives the visual bbox already used the size of the fallback FER (120%) if it was not explicitly defined in the filter definition.

Based on tests with archived builds on Mac OS X 10.5.8 (i386), the change was introduced with the removal of libnr in r10589:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10589>

-----
[*] <http://www.w3.org/TR/SVG11/filters.html#FilterEffectsRegion>

Revision history for this message
Alvin Penner (apenner) wrote :

fix committed to rev 12305.

this will affect only the Blur filter bbox generated by the Fill&Stroke dialog, not the custom filters coming from the Filters menu

Changed in inkscape:
status: Triaged → Fix Committed
su_v (suv-lp)
Changed in inkscape:
status: Fix Committed → Fix Released
assignee: nobody → Alvin Penner (apenner)
su_v (suv-lp)
tags: added: selection
Revision history for this message
Pixel (dot.pixel) wrote :

It's still happening in 0.91pre4 r13712 on WinXP 32. The export is also affected.
See the attached image.

Revision history for this message
su_v (suv-lp) wrote :

On 2015-01-31 02:59 (+0100), Pixel wrote:
> It's still happening in 0.91pre4 r13712 on WinXP 32. The export is
> also affected.

@Pixel, the effect depicted in your attachment was originally reported in bug #1188336 (fix had later been reverted, see bug #1229971), and filed again recently as bug #1412035.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.