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. :stuck_out_tongue:

[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).

[Tymewalk]

@IronManMark20 Yeah, they do specify a file path. With split it shouldn't be too hard to check.

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

I was asking if GTK comes pre-installed, but I'll take that as a no. 165 MB is a little much. Maybe there could be a no-SVG version of Slither that doesn't require it?

Or maybe it checks if GTK is installed, and if not, doesn't support SVGs, but still lets you use Slither without them.

[emmatyping]

I was asking if GTK comes pre-installed, but I'll take that as a no. 165 MB is a little much. Maybe there could be a no-SVG version of Slither that doesn't require it?

Or maybe it checks if GTK is installed, and if not, doesn't support SVGs, but still lets you use Slither without them.

Yeah, the answer is no to that too, with the minor exception of Linux distros that come with GTK.

We could go the if it has it, use it approach, but I'd rather see if I can wrap something first, as that would be much smaller.

[Tymewalk]

@IronManMark20 As you said, it might be possible to wrap nanosvg. I'm afraid that's out of my league, I've never wrapped anything into Python before.

[BookOwl]

Me neither.

[ghost]

No clue at all. lol

[emmatyping]

So, actually, if I forgot I forked this a while ago. The issue as I remember was it was made for linux, so it uses make files (I dev on Windows). I think I can translate it to a cmake build system (fingers crossed) as I am now much more familiar with C++ and build systems.

EDIT: I have cmake going, and I have a Windows solution, I will try to see how well this will integrate with the project. Now I just have to find the right includes.

Also, do we care how easy it is to build? Or can we just provide whls?

[BookOwl]

@IronManMark20, we are currently uploading whls to PyPi, if that answers your question.

Also, do we care how easy it is to build? Or can we just provide whls?

I think that we should focus on making it as easy as possible for end users to install, since we are targeting beginning programmers.

[emmatyping]

I think that we should focus on making it as easy as possible for end users to install, since we are targeting beginning programmers.

The reason I ask is that it generally isn't easy to build C/C++ extensions on Windows (or period). So I am trying to think about how we can make it the easiest. If we provide whls, then people can just use pip, and won't have to worry about building.

If we want of ease of install, this shouldn't be a problem, I can just build whls for Windows and Linux for the supported Python versions, and help someone with a Mac build. It would be pip installable, just harder to build from sources.

[Tymewalk]

Also, do we care how easy it is to build? Or can we just provide whls?

I think that we should focus on making it as easy as possible for end users to install, since we are targeting beginning programmers.

Yes, we are targeting beginning programmers, but I also think that if it only requires one or two extra steps, that's OK. The general idea is that when you use Slither, you (normally) fall into one of these three categories:

• Moving on from Scratch to Python
• Starting off with Python and Pygame, but with basic Python knowledge
• Trying to make Pygame easier

All three groups will probably know enough to install .whls with pip.

If we want of ease of install, this shouldn't be a problem, I can just build whls for Windows and Linux for the supported Python versions, and help someone with a Mac build. It would be pip installable, just harder to build from sources.

Then I say go for it :smiley: 90% of the users will use pip anyways, the other 10% probably know what they're doing.

[BookOwl]

Also, do we care how easy it is to build? Or can we just provide whls?

I've had another idea related to this. Why don't we split the svg c/c++ extension into it's own package and provide whls for that. That way we can make it easy for people to build slither from source, while still giving us SVG support.

[BookOwl]

@Tymewalk @IronManMark20

[Tymewalk]

@BookOwl Sounds OK to me. But if they don't install the SVG extension, what will Slither do when it tries to import a package that isn't installed, or try to load an SVG?

[BookOwl]

If we put the svg extension on pypi, it can automatically be installed along with slither, but in case that is not possible, slither could recover from the ImportError and disable svg support.

[emmatyping]

@BookOwl sounds good. I'll see what I can do.

[emmatyping]

Alright, no completed module yet but today I was able to get the dependencies of SDL-SVG to build on Windows, which is a feat in of itself. I found some Windows ports which were poorly documented, but with the dependencies built, I should be able to build SDL-SVG, which is the main blocker to using Pygame-SVG. I have to re-write all the build logic, as it is written for Linux, but it should be doable. I'll post when I have PyGame-SVG building.

[emmatyping]

Well, I just remembered what made porting SDL-SVG such a pain. There are many points where I will have to re-write the code, as the VS 2010 compiler doesn't support it (Microsoft is bad at supporting C/C++ standards). I think I did it in a few hours last time, but I don't think I kept a copy. :sob: I'll keep working till I get SDL-SVG to compile. Then getting pygame-svg to compile should be a piece of cake :cake:

[BookOwl]

@IronManMark20 sounds like great progress to me! :+1: Keep up the good work!

[Tymewalk]

If we put the svg extension on pypi, it can automatically be installed along with slither, but in case that is not possible, slither could recover from the ImportError and disable svg support.

OK. The Slither-side code should go like this:

svgsEnabled = True
try:
    import slither-svg
except ImportError:
    print("WARNING: The slither-svg package is not installed. SVG support will be disabled.")
    svgsEnabled = False
finally:
    # Continue here

This way all you have to do in your Slither code to test for SVGs is this:

if slither.svgsEnabled:
    # Import an SVG as the costume
else:
    # Import a PNG as the costume

[Tymewalk]

@IronManMark20 Wow. A round of applause and thanks for you! :clap: :+1: By the way, isn't gcc available for Windows somewhere? I searched about it and I found a few things that say it is and a few that say it isn't.

[emmatyping]

@Tymewalk gcc is available, but the binaries that it compiles are not compatible with those generated by the MSVC compiler (provided by Microsoft). The official Python distribution is built using specific versions of the MSVC compiler/runtime, and extensions/libraries/etc must also be compiled using the same compiler (even the same version annoyingly). So unless we want to ask people to use an unofficial version of Python compiled with the gcc available on Windows, sticking with MSVC is the way to go. Also, I use the official Python distribution, and have been meaning to port this over anyway. :smiley:

[Tymewalk]

@IronManMark20 Oh, OK. Good to know. Do you plan on submitting the code to PyPi when it's done?

[emmatyping]

@Tymewalk yes. I think I'll work on getting things working on Windows first (this might be a couple of weeks, so don't hold your breath). As I remember, when I built on Ubuntu it was quick and painless, but I will have to see if my changes break anything. I don't have a mac, so I can't test that.... I will grab the name on PyPi soon. I should be able to upload the current (working on ubuntu but not Windows) sources to hold the name on PyPi.

[emmatyping]

Well, quick update. I haven't had a lot of time to work on this recently, but today I am very close to getting SDL_svg to compile. I have to deal with a couple of the dependancies being outdated, and I will have to manually recompile them. After that it should be about a week or so before I will have a whl for very alpha testing for Windows. I will see if I can build a wheel for Linux sooner...

EDIT: Also, for the sake of sanity, I am only going to support Python 3.5 on Windows. The compiler used for previous python versions don't support some of the C constructs used in the library, so... On Linux and Mac, it should be fine for earlier versions.

[BookOwl]

@ethanhs great job! supporting 3.5 only on windows sounds fine to me.

[Tymewalk]

@ethanhs (Sorry for the late reply) Sounds awesome! I don't care about having to only support 3.5 on Windows, to be honest I didn't even expect to support Python 2 and 3 for long on any platform.

[Tymewalk]

Bumping this to see where we are. @ethanhs?

[emmatyping]

Yeah, so... I moved computers and lost the progress I had made. :( However, I will def. keep working on this. Give me a week to wrap up finals and graduate, then I can get back to this. Sorry not to work on this for so long.

[Tymewalk]

@ethanhs It's fine, everyone kinda had their own things for a while :smiley: Now that I'm kind of getting back in the swing of things I'm just recapping everything we had open.

[ghost]

Yeah, I kind of wandered off with my assignments...

[Tymewalk]

How are we on this?

[emmatyping]

Ah, um. So I'm going to say that the easiest route would be to either use pyrsvg or offscreen render using glsvg. Too many of the c++ dependencies just aren't written to run on Windows. I'd rather have an optional GTK dependency than port the several files. And I'm sorry I don't have time to work on this atm, I am working on a different program and I want to focus on that. What free time I had, I have no longer. :/

[Tymewalk]

@ethanhs That's all right. It's probably best that we don't try to port everything, there'd still be some issues regardless.

Thanks for trying, though. It's a help to at least know we could get this far :smile:

[BookOwl]

If we can rely on users having node.js installed, we could use this to rasterize the SVGs to PNGs.

[Tymewalk]

@BookOwl Then what to do if they don't have it installed?

Will we just warn them or is it a hard dependency?

[BookOwl]

We could say that if they have node.js installed we will be able to handle svgs, otherwise we will throw an error when the user tries to use a svg just like we do now.

[Tymewalk]

OK. In the installation instructions we can also include that they have to install that module.

Where would the rasterized PNGs go, though?

[BookOwl]

We could create a cache dir to put the pngs in and then delete it when we exit. Also, I think that it should be possible to get the setup.py to install it for us.

[Tymewalk]

@BookOwl OK then.

Should we remove the "hard" label? It seems like it's just a matter of getting a new program to play nice with our code.

[emmatyping]

You can run arbitrary python code in setup.py, so installing it shouldn't be a problem

[BookOwl]

@Tymewalk @ethanhs, I just found out that if we restrict ourselves to just Python 3.4+, we can use CarioSVG to rasterize the SVGs to PNGs. They say that it works on all platforms, and installing it is as easy aspip install cairosvg, so we could add it as a dependency.

[BookOwl]

OK, it turns out that the user still needs to have cairo installed, BUT, I've found out that it should be easy to build a stand-alone cairo DLL that we can include for Windows, and we just need to run a simple shell command to get it to install on OS X and Linux.