Memory leak in SKIA drawSVG

  1. nifty little fkr.

memory leak 2.vl (19.1 KB)

would you care to write a few more words, regarding how we can see what you see here?

svg path was absolute. the patch should work now. if I activate the toggle my vram starts filling up. (7.9 KB)

Hi @schlonzo,

here again (like in this thread), setting the Skia’s GRContext's cache to 16MB strangely stops the leak.


1 Like

hi, I still have the same problem with preview 0850. this makes svgs quite unusable for me. it seems to be connected to svgs moving around and getting redrawn.
I also use a lot of textures, so setting the grcontext back to 16mb is no option for me.

I can confirm that the rendering performance gets extremely bad in case the pictures are being moved on the screen. But really no idea why it would behave that way. I had pretty good experience with SKPicture the last couple of weeks. The drawing itself probably also has a huge impact on the performance? Like what styles are used, what paths are drawn, how many etc. The SVG is basically a huge list of drawing commands. Maybe pre-rendering is an option?

Of course - pre-rendered is an option. It’s just a pity because there are a lot of cool vector tools and we would prefer to work with them.

You can render it once on load in the resolution you need and then only use the image instead of rendering the SVG every frame.

I’m thinking that there maybe also possible to keep only one root frame and set it contents somehow, as I know from web each svg is quite expensive…

I used very simple SVGs with few points, one image and one colorfilter.

<svg id="Ebene_1" data-name="Ebene 1" xmlns="" width="437.67508" height="412.57903" viewBox="0 0 437.67508 412.57903">
      .cls-1 {
        fill: #fff;
        stroke: #1d1d1b;
        stroke-miterlimit: 10;
  <polygon class="cls-1" points="174.765 1.054 0.765 412.054 436.765 398.054 174.765 1.054"/>

Had it running now for ~17hours with simulated user inputs. It seems to be stable, just the vram is completely full.

Rendering all svgs to pixel images at the beginning would be an option. But then- why bother exporting svgs in the first place?

The only reason to use vectors ATM are the path effects. Those are really cool and can just be done with SVG.

I tried to convert svg to skpath and draw these. There seems to be no memoryleak there, and performance is ok.

HowTo Sample the paths of an SVG.vl (87.6 KB)

I guess this is going to be my workaround at the time.