Converting clipped object to pattern produces rasterised pattern

[dopelover]

Converting clipped object to pattern produces rasterised pattern.

How to reproduce:
1) Create object (eg. spiral, star, etc.)
2) Create another object (eg. rectangle) overt the previous one.
3) Select both objets and set clipping
4) Convert produced object to pattern
5) Create just another object and set filling to previously created pattern

The another problem is that some resulting patterns looks differently. Some of them are the size of clipping path (see attached file - example on the left side) and some of them are size of clipped object ( see attached file - example on the left side).

This issue doesn't affects the stable version 0.42.2 so it is another regression.
Tested with Inkscape r11083 on Windows XP.

[su_v (suv-lp)]

Related reports (see latest comments in each of the them):
Bug #168014 "Redraw fails with clipped object patterns "
<https://bugs.launchpad.net/inkscape/+bug/168014>

Bug #643093 "In imported PDF, some objects not rendered / partially rendered "
<https://bugs.launchpad.net/inkscape/+bug/643093>

and this sub-thread on inkscape-devel:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37131/focus=37257>

[su_v (suv-lp)]

Already mentioned and reproduced with trunk in bug #168014 and bug #643093.

Related to (or maybe duplicate of) reopened bug #168014.

[su_v (suv-lp)]

> The another problem is that some resulting patterns looks differently.
> Some of them are the size of clipping path (see attached file - example
> on the left side) and some of them are size of clipped object ( see
> attached file - example on the left side).

I haven't been able yet to reproduce this part: redoing the pattern (black stroked spiral) on the right (which seems to have taken the dimensions of the unclipped original object) produces the same result as your example with the red stroked spiral on the left (pattern uses the dimensions of the clip-path/clipped object).

[su_v (suv-lp)]

>> The another problem is that some resulting patterns looks differently.

This can happen if the visual bounding box of the newly clipped path hasn't been updated after applying the clip (e.g. by nudging the clipped object with the arrow keys).

Does not happen if the preferences for clip-paths and and masks are set to "put all clipped/masked objects into one group" before applying the clip or mask.

An earlier comment of mine in reply to a related question about clipping in the Inkscape user forum has the links to related threads on the mailing list 'inkscape-devel':
<http://www.inkscapeforum.com/viewtopic.php?f=29&t=11374#p41608>

[su_v (suv-lp)]

The issue with the
- cached (outdated) visual bounding box for newly clipped/masked objects
  (related AFAICT to changes in r10618 for minimal visual bbox caching)
is unrelated to the reported problem
- clipped objects in patterns are rasterized
  (related AFAICT to changes in r10451 merging the gsoc-caching branch)
and probably ought to be tracked in a separate report

[su_v (suv-lp)]

Issue with cached visual bounding box values after setting a clip has been filed separately as
Bug #1005085 “Clipping path not set clipped object to its new size immediately.”

[su_v (suv-lp)]

Adding information from bug #168014 here as well:
Based on tests with archived builds, the regression initially seems to have been introduced between r10450 and r10454:

Patterns with clipped objects seem to render as bitmaps and do not scale when zooming in (the pattern fill looks pixellized when zoomed in or even at zoom 1:1 with a PDF file from bug #643093).

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 11652.

[Tavmjong Bah (tavmjong-free)]

I am guessing that this is due to a problem in display/drawing-item.cpp where the "intermediate" DrawingSurface is created without accounting for any scaling. Contrast this line in sp-pattern.cpp

Inkscape::DrawingSurface temp(pattern_tile, c.ceil());

to this line in drawing-item.cpp

DrawingSurface intermediate(*iarea);

The second (optional) argument gives a scaling to the surface (that then must be accounted for later). If there is no scaling, the bitmap representing the pattern will be the same size as the default pattern size regardless of any zoom or pattern transformation. I don't know enough to see a quick and obvious way to fix this.

[Tavmjong Bah (tavmjong-free)]

I've investigated this a bit further. After a bit of effort I was able to compile r10450 and nearby revisions (required replacing glib header files by the single glib.h and commenting out a couple of small non-relevant png related code). The problem is definitely introduced in the commit r10451. Prior to this commit, clipping and masking are handled differently in display/nr-arena-item.cpp; this commit changes that to handle them in the same way. r10450 has the same kind of problem with masks (as well as non-clipped edges of objects with in the clipping region).

I've attached an SVG file that tests both clipping (blue circle clipped by square) and masking (purple circle masked by square).

[Tavmjong Bah (tavmjong-free)]

Fix committed (r11914). Please test.

Problem was as suspected, the intermediate drawing surface didn't account for scaling between "logical" and "physical" spaces.

[su_v (suv-lp)]

It appears that r11914 introduces a regression with patterns which use filter effects (noticed when testing Bug #618954 “no filters view mode doesn't affect patterns” with current trunk build):

Steps to reproduce:
1) open attached file in Inkscape in current trunk
--> original zoom level 1:1 looks ok
2) zoom in (or out):
--> the pattern used for the fill seem to get scaled incorrectly and are partially cut off.

On OS X 10.7.4 (GTK+/X11 + cairo 1.12.2, GTK+/Quartz + cairo 1.12.8):
- reproduced with r11914
- not reproduced with r11913

[su_v (suv-lp)]

AFAICT likely related regression (similar artifacts may occur with sample file attached to comment #13):
Bug #1085422 “Black box artifacts with provided svg”
<https://bugs.launchpad.net/inkscape/+bug/1085422>

[Tavmjong Bah (tavmjong-free)]

Hmm, I'll have a look in the next few days. We may have to back out the "fix".

[Tavmjong Bah (tavmjong-free)]

Just checked in a second attempt at fixing this bug (r955141).

[Tavmjong Bah (tavmjong-free)]

Oops, that was r11914.

[Tavmjong Bah (tavmjong-free)]

Double oops, try r11942.