| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
This currently does fetching, but not parsing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes bug #2251 which was caused by the svg:
<svg width="11" height="11" id="support-entry-icon"
y="3389"><g><g><path fill-rule="evenodd" clip-rule="evenodd"
fill="#D6D6D6" d="M0,0v11h11V0H0z M10,10H1V1h9V10z M9,3H2v1h7V3z
M9,5H2v1h7V5z M9,7H2v1h7V7z"/></g></g></svg>
The svg was causing more path elements to be generated in the internal
representation than space was allocated for and overrunning heap
blocks.
The path element parsing was using a fixed size allocation for the
path elements and never bounds checked. Further it did not cope with
zero length paths (which the spec says are permitted). It was also
grossly overallocating for the common case.
This changes the path element array to be bounds checked and then
extended if required, the initial allocation is generally sufficient
and in testing very few resizes occurred.
The reallocation strategy grows the element storage by 2.5 each time
this means even in the degenerate case very few reallocations are
required. In testing no more than a single reallocation has been
observed.
The final path element array will always be reallocted to the minimum
required size. This reduces overall memory usage which is useful with
complex scenes.
|
|
|
|
|
|
|
|
| |
The SVG spec for the transform attribute allows whitespace in places
that were causing the %n specifier in the ssanf to return 0 as the
match failed before it completed the parse.
http://www.w3.org/TR/SVG/coords.html#TransformAttribute
|
|
|
|
|
|
|
|
|
| |
Both 'M' and 'm' are moves and therefore start a new (sub)path. In
either case the location should be cached so that a later 'close path'
(z or Z) knows the location it is returning to. The location is not
written to 'p', since it is assumed that the client code remembers. If
the next move is relative (lowercase), then it's important that last_x,
last_y were correctly updated while processing Z/z.
|
|
|
|
| |
gradients.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
svn path=/trunk/libsvgtiny/; revision=11186
|
|
|
|
| |
svn path=/trunk/libsvgtiny/; revision=11140
|
|
|
|
|
|
| |
svgtiny_parse_length doesn't get confused about the remainder of the string. Contributed by Peter Korsgaard.
svn path=/trunk/libsvgtiny/; revision=10837
|
|
|
|
| |
svn path=/trunk/libsvgtiny/; revision=9771
|
|
|
|
|
|
| |
would be rounded to 0.
svn path=/trunk/libsvgtiny/; revision=9707
|
|
|
|
| |
svn path=/trunk/libsvgtiny/; revision=9706
|
|
|
|
|
|
| |
circumstances it doesn't get #defined. Catch this.
svn path=/trunk/libsvgtiny/; revision=9701
|
|
|
|
|
|
| |
gradient fill.
svn path=/trunk/libsvgtiny/; revision=9682
|
|
|
|
| |
svn path=/trunk/libsvgtiny/; revision=9423
|
|
svn path=/trunk/libsvgtiny/; revision=9419
|