Rendering cache committed
Hello
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely by defining the environment variable _INKSCAPE_DISABLE_CACHE. For example, run inkscape as: $ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering data. It can be set in the "Rendering" page of the preferences (renamed from "Filters").
As usual, problem reports are welcome.
Regards, Krzysztof
On 25/8/11 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely by defining the environment variable _INKSCAPE_DISABLE_CACHE. For example, run inkscape as: $ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering data. It can be set in the "Rendering" page of the preferences (renamed from "Filters").
A) Rendering artifacts with text objects (regular text, Sans, 40px) [0]:
1) When moving text objects with the arrow keys (select tool), sometimes old remnants stay behind and are not cleared on-canvas. Often triggered by zooming in/out (closer than 100%) while the text object is selected with the select tool and subsequently moving it (or a duplicate) e.g. with 'Shift+arrow key' (default steps).
2) Create a (multi-line) regular text: Delete the last letters of a line or the paragraph with backspace: the letters remain visible on the canvas though no longer part of the text. Zooming in /out removes the remnant parts. Insert a newline into a long word: the text moved to the next line appears duplicated because the canvas at the prior position is not fully cleared/updated.
Disabling caching as described does not prevent the rendering errors.
B) Questions not specific to the merge (style, color-interpolation, "superfluous" markup):
1) While testing above artifacts with the latest builds from trunk, I noticed that when removing a newline in a regular text object with backspace (<tspan> gets deleted?), as well as e.g. when copying a selection to the clipboard, recent builds give these console warnings:
WARNING **: Inkscape currently only supports color-interpolation-filters = sRGB
These messages seem harmless (and not related to any of the operations at all), but I wonder why they occur when manipulating text objects without any filter effects in use.
The new warning reminded me of this question: 2) Why is the number of style attributes added to a path created by converting a simple black stroke to path increasingly longer [1] and adds a lot of apparently unrelated attributes (text, filters, etc)? Similarly, additional style attributes are added when pasting a style from the clipboard (Shift+Ctrl+V) - though pasting does not add the text-related attributes:
Why are e.g. the attributes
"color-interpolation:sRGB;color-interpolation-filters:linearRGB;"
added each time when pasting a style (e.g. red fill, black stroke, width 1px) or converting a stroke to path, without any filter effects in use in the current document? Are they required for each individual object or could they be removed [2]?
~suv
[0] Tested on Mac OS X 10.5.8 (i386) with r10579-10600 GTK+/X11 2.24.4 with cairo 1.10.2 GTK+/Quartz 2.24.4 with cairo 1.11.2
[1] these 32 style attributes are created in r10799 each time a black stroke (fill:none; stroke:#000000) is converted to path (Ctrl+Alt+C): font-size:xx-small; font-style:normal; font-variant:normal; font-weight:normal; font-stretch:normal; text-indent:0; text-align:start; text-decoration:none; line-height:normal; letter-spacing:normal; word-spacing:normal; text-transform:none; direction:ltr; block-progression:tb; writing-mode:lr-tb; text-anchor:start; baseline-shift:baseline; color:#000000; color-interpolation:sRGB; color-interpolation-filters:linearRGB; fill:#000000; fill-opacity:1; stroke:none; stroke-width:10; marker:none; visibility:visible; display:inline; overflow:visible; enable-background:accumulate; clip-rule:nonzero; font-family:Sans; -inkscape-font-specification:Sans
[2] related reports ("superfluous" markup) in the bug tracker: https://bugs.launchpad.net/inkscape/+bug/212077 https://bugs.launchpad.net/inkscape/+bug/171983 https://bugs.launchpad.net/inkscape/+bug/170184
On 30/8/11 11:59, ~suv wrote:
On 25/8/11 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely by defining the environment variable _INKSCAPE_DISABLE_CACHE. For example, run inkscape as: $ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering data. It can be set in the "Rendering" page of the preferences (renamed from "Filters").
A) Rendering artifacts with text objects (regular text, Sans, 40px) [0]:
(...)
[0] Tested on Mac OS X 10.5.8 (i386) with r10579-10600 GTK+/X11 2.24.4 with cairo 1.10.2 GTK+/Quartz 2.24.4 with cairo 1.11.2
Just got reported in the bug tracker, too, for Ubuntu Natty:
Bug #837291 "Text artifacts after character deletion" https://bugs.launchpad.net/inkscape/+bug/837291
~suv
W dniu 30 sierpnia 2011 11:59 użytkownik ~suv <suv-sf@...58...> napisał:
Why are e.g. the attributes
"color-interpolation:sRGB;color-interpolation-filters:linearRGB;"
added each time when pasting a style (e.g. red fill, black stroke, width 1px) or converting a stroke to path, without any filter effects in use in the current document? Are they required for each individual object or could they be removed [2]?
Those are the default values, so they are superfluous.
I think this is because there is a risk that non-default values will inherit from ancestors and cause the pasted object to look differently than it did when copying. Most of those attributes are unnecessary and the paste code should determine which of the attributes differ from the parent, and only explicitly set those.
The text glitches are caused by missing calls to _markForUpdate() and/or _markForRendering() in the rendering tree.
Regards, Krzysztof
On 25/8/11 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely by defining the environment variable _INKSCAPE_DISABLE_CACHE. For example, run inkscape as: $ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering data. It can be set in the "Rendering" page of the preferences (renamed from "Filters").
Regressions not reproduced with r10577, reproduced with r10581, r10612 (latest revision tested with cairo 1.10.2 and cairo 1.11.2):
Bug #839748 "Inkcape doesn't render gradients in blurred objects" https://bugs.launchpad.net/inkscape/+bug/839748
Affects text objects with gradients (tested with r10612): - on-canvas: errors depending on transforms (text or gradient) and zoom level - bitmap export: transformed gradients on transformed texts render filled with the color of the first gradient stop
~suv
On 25/8/11 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
Regression probably related to the first part merged earlier in July: r10451 Merge SPCanvasArena caching layer work
Pattern fills with clipped groups of vector objects in the pattern definition seem to be rendered as bitmaps and do not scale when zooming in, even looking slightly blurry or pixellized at zoom level 1:1.
I have reopened
Bug #168014 https://bugs.launchpad.net/inkscape/+bug/168014 "Redraw fails with clipped object patterns"
and attached a screenshot for comparison [1] after noticing the regression when testing PDF import in current trunk with various files from the bug tracker, namely using the attached sample '60-drift-estimate.pdf ' from (also affected)
Bug #643093 https://bugs.launchpad.net/inkscape/+bug/643093 "In imported PDF, some objects not rendered / partially rendered"
Please revert the changes to the bug status of bug #168014 if you think the issue should be tracked in a newly filed report.
(All tests & screenshots done on Mac OS X 10.5.8 (i386), GCC 4.2.1, cairo 1.10.2, but also reproduced with quartz builds of trunk using cairo 1.11.2)
~suv
W dniu 10 września 2011 19:32 użytkownik ~suv <suv-sf@...58...> napisał:
Pattern fills with clipped groups of vector objects in the pattern definition seem to be rendered as bitmaps and do not scale when zooming in, even looking slightly blurry or pixellized at zoom level 1:1.
I noticed that as well, but I'm not sure why it happens yet. I doubt it's related to the revision you mentioned because later updates remove that in favor of a different (per drawing item) caching mechanism.
Regards, Krzysztof
On 13/9/11 02:20, Krzysztof Kosiński wrote:
W dniu 10 września 2011 19:32 użytkownik ~suv <suv-sf@...58...> napisał:
Pattern fills with clipped groups of vector objects in the pattern definition seem to be rendered as bitmaps and do not scale when zooming in, even looking slightly blurry or pixellized at zoom level 1:1.
I noticed that as well, but I'm not sure why it happens yet. I doubt it's related to the revision you mentioned because later updates remove that in favor of a different (per drawing item) caching mechanism.
I had done the tests with these revisions:
ok: 10326 10400 10450
not ok: 10454 10460 10473 10490 10577 10589 10626 10627
There might have been later internal changes I failed to notice - just that the earliest occurrence of rasterized pattern fills I found was between r10450 and r10454.
All these builds are un-optimized debug builds (-g -O0) without OpenMP support, compiled with Apple's GCC 4.2.1, using cairo 1.10.2.
~suv
On 13/9/11 02:20, Krzysztof Kosiński wrote:
W dniu 10 września 2011 19:32 użytkownik ~suv <suv-sf@...58...> napisał:
Pattern fills with clipped groups of vector objects in the pattern definition seem to be rendered as bitmaps and do not scale when zooming in, even looking slightly blurry or pixellized at zoom level 1:1.
I noticed that as well, but I'm not sure why it happens yet. I doubt it's related to the revision you mentioned because later updates remove that in favor of a different (per drawing item) caching mechanism.
Related to these types of pattern fills (Alvin just recently filed a new report): Inkscape (or cairo 1.10) fails to handle those on export to PDF as well:
Bug #847168 https://bugs.launchpad.net/inkscape/+bug/847168 "crash when saving a clipped pattern to pdf
which is probably the same issue as
Bug #767010 https://bugs.launchpad.net/inkscape/+bug/767010 "Segfault after enormous memory consumption when exporting to pdf"
~suv
On 13/9/11 08:24, ~suv wrote:
On 13/9/11 02:20, Krzysztof Kosiński wrote:
W dniu 10 września 2011 19:32 użytkownik ~suv <suv-sf@...58...> napisał:
Pattern fills with clipped groups of vector objects in the pattern definition seem to be rendered as bitmaps and do not scale when zooming in, even looking slightly blurry or pixellized at zoom level 1:1.
I noticed that as well, but I'm not sure why it happens yet. I doubt it's related to the revision you mentioned because later updates remove that in favor of a different (per drawing item) caching mechanism.
Related to these types of pattern fills (Alvin just recently filed a new report): Inkscape (or cairo 1.10) fails to handle those on export to PDF as well:
Bug #847168 https://bugs.launchpad.net/inkscape/+bug/847168 "crash when saving a clipped pattern to pdf
which is probably the same issue as
Bug #767010 https://bugs.launchpad.net/inkscape/+bug/767010 "Segfault after enormous memory consumption when exporting to pdf"
With regard to patterns, clipping and cairo, these reports have some recent comments by Adrian Johnson (cairo developer):
Bug #486259 https://bugs.launchpad.net/inkscape/+bug/486259 "Custom stripe pattern breaks pdf export" https://bugs.launchpad.net/inkscape/+bug/486259/comments/6 https://bugs.launchpad.net/inkscape/+bug/486259/comments/7
Bug #336638 https://bugs.launchpad.net/inkscape/+bug/336638 "PDF export adds page-sized clipping masks for objects with opacity < 100%" https://bugs.launchpad.net/inkscape/+bug/336638/comments/20
Bug #523285 https://bugs.launchpad.net/inkscape/+bug/523285 "exported PDF 50 times as large as before" https://bugs.launchpad.net/inkscape/+bug/523285/comments/10
Bug #813886 https://bugs.launchpad.net/inkscape/+bug/813886 "Save as EPS or PS incomplete with cairo >= 1.10" https://bugs.launchpad.net/inkscape/+bug/813886/comments/11 https://bugs.launchpad.net/inkscape/+bug/813886/comments/14
~suv
p.s. the links to specific comments are not permanent (Launchpad sometimes inserts comments from linked upstream bug trackers later on, as has happened in bug #168610, the original report about (cairo-)based exports of patterns (and gradients))
On 10/09/2011 19:32, ~suv wrote:
On 25/8/11 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
Regression probably related to the first part merged earlier in July: r10451 Merge SPCanvasArena caching layer work
Pattern fills with clipped groups of vector objects in the pattern definition seem to be rendered as bitmaps and do not scale when zooming in, even looking slightly blurry or pixellized at zoom level 1:1.
I have reopened
Bug #168014 https://bugs.launchpad.net/inkscape/+bug/168014 "Redraw fails with clipped object patterns"
and attached a screenshot for comparison [1] after noticing the regression when testing PDF import in current trunk with various files from the bug tracker, namely using the attached sample '60-drift-estimate.pdf ' from (also affected)
Bug #643093 https://bugs.launchpad.net/inkscape/+bug/643093 "In imported PDF, some objects not rendered / partially rendered"
Please revert the changes to the bug status of bug #168014 if you think the issue should be tracked in a newly filed report.
This regression in current trunk just got filed as new separate report:
Bug #955141 https://bugs.launchpad.net/inkscape/+bug/955141 "Converting clipped object to pattern produces rasterised pattern"
~suv
On 25/08/2011 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
Bug #930593 "Grouping/ungrouping of filtered objects (groups|texts|clones) makes them disappear temporarily" https://bugs.launchpad.net/inkscape/+bug/930593
Steps to reproduce: 1) draw a shape or path 2) group it 3) blur the group 4) group the blurred group
-> content disappears, and reappears after forcing a screen update (show/hide current layer, or nudge the group with arrow keys up and back down again).
Same occurs when (un-)grouping filtered text objects (bug #243729) and filtered clones (bug #304407).
The old renderer and the initial cairo-based renderer simply did not render the filter effects after grouping/ungrouping without forcing a screen update - the objects themselves remained visible.
The disappearing of the objects altogether seems to have been introduced with the initial merge of the rendering cache work in revision 10579 (based on tests with archived builds): - Not reproduced with r10577 - Reproduced with r10781
~suv
On 11/02/2012 13:20, ~suv wrote:
On 25/08/2011 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
Bug #930593 "Grouping/ungrouping of filtered objects (groups|texts|clones) makes them disappear temporarily" https://bugs.launchpad.net/inkscape/+bug/930593
<snip>
The disappearing of the objects altogether seems to have been introduced with the initial merge of the rendering cache work in revision 10579 (based on tests with archived builds):
- Not reproduced with r10577
- Reproduced with r10781
Sorry, typo:
- Not reproduced with r10577 - Reproduced with r10581
On 25/08/2011 21:26, Krzysztof Kosiński wrote:
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely by defining the environment variable _INKSCAPE_DISABLE_CACHE. For example, run inkscape as: $ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering data. It can be set in the "Rendering" page of the preferences (renamed from "Filters").
“Inkscape encounters internal error when opening a valid SVG file” Bug #1071328 https://bugs.launchpad.net/inkscape/+bug/1071328
Crash seems to be triggered by <symbol> elements outside of the <defs> section (the provided sample SVG file has them in document root).
Based on my tests with archived builds (not reproduced with current stable 0.48.3.1, not reproduced with trunk <= 10577, reproduced with trunk >= 10581, up to current head r11826), the regression is likely to have been introduced with the merge in r10579.
participants (2)
-
Krzysztof Kosiński -
~suv