4:26 a.m.
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
6:59 p.m.
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>
8:52 p.m.
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
7:23 a.m.
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
11:45 a.m.
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
2:32 a.m.
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
[1]
<https://bugs.launchpad.net/inkscape/+bug/168014/+attachment/2382247/+file...
9:20 a.m.
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
3:16 p.m.
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
3:24 p.m.
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
3:50 p.m.
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))
2:06 a.m.
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
9:20 p.m.
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
9:21 p.m.
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
4:44 a.m.
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.
3869
days inactive
4296
days old
inkscape-devel@lists.inkscape.org
14 comments
2 participants
participants (2)
-
Krzysztof Kosiński -
~suv