SVG support

[emmatyping]

So as not to clog up the Scratch topic.

Summary of previous discusion:

Our options are:
glsvg, which is easy and should work. Maybe be issues with multiple svgs at the same time (which is a problem).

pyrsvg, a standard for vector raserization. Requires the hefty GTK libraries though.

Wrapping a C++ solution? nanosvg seems like a possibility, but at this point it might even be easier to write a rasterizer (and use an existing Python parser).

pinging @BookOwl and @Tymewalk please fill in anything I missed.

[Tymewalk]

I think we should start with glsvg and then try to push as many SVGs into the program as we can. If the maximum number turns out to be something like 1000, we can probably say "It's OK" since I doubt anyone would use 1000 SVGs anyways. 😛

[emmatyping]

So, you aren't getting 1000 SVGs. You get one. I just tested glsvg, and well, the bug reported here is accurate. I will see if I can maybe fix this bug, but that is a significant issue. Also, if your curious, my code example that only renders one SVG.

I'll report back if I make any progress

Oh, or as an utter hack, we might be able to try off screen rasterization using glsvg, then deal only in bitmaps. Either way, I will experiment with what is possible.

[BookOwl]

So, you aren't getting 1000 SVGs. You get one.

That's really bad.

Oh, or as an utter hack, we might be able to try off screen rasterization using glsvg, then deal only in bitmaps

That sounds like it could work.

I'm starting to think that writing our own rasterizer might be the best option.

[Tymewalk]

So, you aren't getting 1000 SVGs. You get one.

YIKES.
How big are the GTK libraries, and do they come installed by default? I'm considering pyrsvg.

Oh, or as an utter hack, we might be able to try off screen rasterization using glsvg, then deal only in bitmaps

Will it slow things down if we use it a lot? Or if a sprite constantly rescales itself?

[BookOwl]

@Tymewalk, if we do offscreen rasterization, I think that we would do it once and scale and rotate the rasterized image.

[Tymewalk]

@BookOwl OK, so here's how I understand the workflow:

• User makes a Slither sprite
• User adds an SVG costume to it with height and width
  • glsvg rasterizes it
  • The rasterized image goes into the costumes list
• Continue as if it was just a bitmap

[emmatyping]

If we go the route of rasterize once, we will need to rasterize at a high resolution, else we might get bad scaling. Which would increase time to rasterize. I will try to work on this today and tomorrow. The documentation for PyOpenGL is not the best, but I think I can piece things together.

@Tymewalk I think we can just add a little bit to where people add the costume (I assume they must give a file path), if it has an svg or svgz file extension, we use glsvg and off screen rendering.

[BookOwl]

If we go the route of rasterize once, we will need to rasterize at a high resolution, else we might get bad scaling. Which would increase time to rasterize

It might be a good idea to look into creating our own SVG renderer.

will try to work on this today and tomorrow. The documentation for PyOpenGL is not the best, but I think I can piece things together.

Thanks for working on it!

[emmatyping]

It might be a good idea to look into creating our own SVG renderer.

Whew, that would be a lot of work. Maybe. I would rather wrap a C++ one for speed.

Also, as for speed of the rasterization, I have no idea. I will have to experiment. OpenGL uses the GPU, so it should be fast, but with Python.... I don't know.

As for pyrsvg, it is not included in the Python distribution, and depends on the GTK+ runtime (I just checked install size ~165mb).