GitLab

The gtk engine is deprecated itself, so don't bother fixing its use of GCache but
just define GLIB_DISABLE_DEPRECATION_WARNINGS here.

On gtk3, use a GtkBox.

Since we depend on glib 2.24 where g_type_init() already calls
g_thread_init(), just use g_type_init() here instead.

... instead of adding the same array to librsvg as well.

Update GIO req to 2.24, and just always use GIO for gzip support.

It's deprecated.

Instead of building the string and parsing it to a path every time
we render this node, just store the parsed path instead.

Store the parse cairo_path_t instead of re-parsing the string
every time we render this path!

This will be used to avoid going through building a string then
parsing the string into a path in rsvg-shapes.c.

Pass the cairo_path_t to the render funtion, instead of a string.

Just call cairo_append_path() instead of duplicating it (twice!).

Parse the path into a cairo_path_t structure instead of inventing
an own one.

I've checked this quite carefully, but it still might contain
stupid typo bugs ;-)

To do this, remove RSVG_END element from RsvgBpathDef.

Although it appears this property is only parsed, but not used
when rendering...

Although it appears this property is only parsed, but not used
when rendering...

This fixes the crash, but the rendering of masking-path-04-b.svg
is still wrong, not matching the reference rendering.

https://bugzilla.gnome.org/show_bug.cgi?id=630733

Otherwise we get an invalid read when freeing this node.

librsvg doesn't depend on these anymore.

ctx->render is a RsvgCairoClipRender here, and NOT a RsvgCairoRender.
I think the right thing here is to use the render->cr,
and not render->parent->cr.

==10734== 19 (8 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 1,325 of 2,962
==10734==    at 0x4026EB4: malloc (vg_replace_malloc.c:236)
==10734==    by 0x4B3B823: g_malloc (gmem.c:164)
==10734==    by 0x4B40A76: parse_arg (goption.c:1242)
==10734==    by 0x4B42123: g_option_context_parse (goption.c:1572)
==10734==    by 0x804C39B: main (test-display.c:784)
==10734==
==10734== 40 (24 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 2,103 of 2,962
==10734==    at 0x4026EB4: malloc (vg_replace_malloc.c:236)
==10734==    by 0x4B3B823: g_malloc (gmem.c:164)
==10734==    by 0x4B51726: g_slice_alloc (gslice.c:842)
==10734==    by 0x4B07158: g_array_sized_new (garray.c:185)
==10734==    by 0x4B07275: g_byte_array_new (garray.c:1402)
==10734==    by 0x4034F0C: rsvg_acquire_file_resource (rsvg-image.c:109)
==10734==    by 0x403512A: _rsvg_acquire_xlink_href_resource (rsvg-image.c:174)
==10734==    by 0x804C59B: main (test-display.c:837)

This reverts commit 9333f2da.
It didn't work as intended and needs more work.