New svg renderer

[redhog]

• https://github.com/turran/egueb
• https://github.com/micahpearlman/MonkSVG

[IanTrudel]

This should be in #51! We had a lengthy conversation about it.

Skia/CEF are most likely the best option in terms of reliability, robustness and performance. They are essentially the backbone of Chrome and Chromium.

I have been experimenting with libcef in C here and there. It needs a proper wrapper because it's written in C++.

[redhog]

It would be advantageous to have one where the DOM is accessible via the API, and DOM and CSS can also be changed via the API (and the image rerendered). Can Skia do this?
I remeber looking at Skia and discarding it because of C++, but writing a wrapper might be worth it?

[IanTrudel]

It would be advantageous to have one where the DOM is accessible via the API, and DOM and CSS can also be changed via the API (and the image rerendered). Can Skia do this? I remeber looking at Skia and discarding it because of C++, but writing a wrapper might be worth it?

Skia would be an excellent replacement for cairo. It would be worth writing a wrapper for it. As far as DOM and CSS are concerned, what you have in mind would be using CEF (Chrome Embedded Framework). CEF also includes Skia anyway. It would also need a wrapper but the possibilities for us would be endless if we get that in InfiniteGlass.

We would have access to the DOM, Canvas/SVG, HTML, JavaScript, and a blazing fast rendering for anything we use it for. That's essentially why so many applications are embedding CEF.

[redhog]

How much RAM does CEF eat though? It is a bit scary to put too heave stuff in the renderer, esp. as it is a single process...

[IanTrudel]

How much RAM does CEF eat though? It is a bit scary to put too heave stuff in the renderer, esp. as it is a single process...

The short answer would be this has to be checked.

It's widely used in a variety of applications, which likely means memory usage is acceptable. It may tend to grow over time but it can be mitigated in various ways such as using cgroups.

Running this in a single process shouldn't be a problem but it has risks. Chrome/Chromium, for example, are running tabs in independent processes, allowing restoring a tab when it crashes without crashing the browser. GIL will however be removed and multiple processes are coming to Python.

I don't want to oversell CEF. The highlights are the features it provides, e.g. everything on your wishlist. There is perhaps a tradeoff here where the library is widely used, well maintained and efficient but with the cost of higher memory usage.

The alternatives we have talked about in the past would mean using several libraries that wouldn't even come close to the features offered by CEF.

InfiniteGlass is considerably leaner than GNOME, KDE and the likes. GNOME uses the Firefox JavaScript engine for its shell extensions. How concerned should we be about memory usage?

[redhog]

I think my main issue is that this has to live in the renderer. I rather do more complex stuff in separate processes, that are written in python (or other languages), than in the renderer with is pure C. But: It might be worth it. Having CSS is definitely nice. JS isn't a bad thing either.

One thing to note is that we are rendering the same SVG at multiple zooms and pans, so this must be easily available in the API.

[redhog]

I'd say give it a try! Worst thing that can happen is you spend some time to wrap it, and then it turns out not to work very well...

[IanTrudel]

I'd say give it a try! Worst thing that can happen is you spend some time to wrap it, and then it turns out not to work very well...

Exciting! I will finish up with the rsvg and build issues first and provide a new branch or PR. Those are currently necessary to run InfiniteGlass on my machine.