GSVGtk is a library to provide GTK+ widgets you can use to access SVG files. It is powered by GSVG, in a way it can access each shape and its properties using a GObject API based on W3C SVG 1.1 specification.
Currently, GSVGtk uses Clutter to encapsulate SVG shapes, render them inside Clutter Actors, through librsvg, and maps events to source SVG in order to eventually modify original definitions, like its position.
In the following video, you can see GSVGtk’s Container based on Clutter, loading an SVG file, take some shapes from it to show on the scene.
Shapes can be moved around, with feedback about its position in millimeters. If it is moved out of the stage, you can pan the scene to reach it.
GSVG allows to add SVG transformations to shapes, like scale and translate; matrix, skew and rotate are a work in progress. Once finished, they can be used with Clutter Actors to render transformations on screen with GSVGtk.
All CSS properties required in the standard are present in GSVG, but a good UI to modify them is required, may some of you want to create mockups to be implemented.
GTk4 and GSVGtk
On GTK+’s IRC, I asked for GTK4 and the future of Clutter, I get some recommendations from GTK+ developers. I’ll keep Clutter for backward compatibility and to able to use GSVGtk in LTS distributions, but add interfaces, a la GDK, to be able to have different backends.
Clutter based backend will be the first to be finished; next or in parallel, I’ll port GSVGtk to GTK4, in order to eventually drop Clutter support when GTK+ 4.0 reach long term stability, around 4.6 release.
GSVGtk and PLogic
PLogic will be the first project to take advantage on GSVGtk and GSVG, in order to render logic diagrams, with basic edition capabilities.
All basic edition capabilities required for PLogic, will push ahead GSVG development to implement new features from specification, as long as GSVGtk to provide graphical tools to archive them.
SVG Rendering
GSVGtk, no GSVG, uses librsvg to render SVG shapes and text on screen. librsvg is fast, but for large projects I think the pipeline used currently will find a bottle neck.
For rendering, GSVGtk ask GSVG to generate string representation of SVG in XML, then pass it to librsvg for rendering. This can be avoided if librsvg exposes internal rendering methods in order to call them directly using GSVG structures and objects.
A solution is to take a dive into librsvg source code, extract that methods, import to GSVG or GSVGtk (thanks free software), so rendering can get a speed up. Yes create MR for librsvg to expose them is an option, but I need C methods and maybe this is not in line with the progress of Rustify work in librsvg.
Rendering directly, will help to avoid rendering to Clutter Canvas, which imposes semi-transparent backgrounds for shapes, see the video. More importantly, a direct rendering, will help on shapes selection as their sensitive area can follow its own form to avoid square areas and allow to select objects behind other with transparent fill out.
Again GTk4 will be a very interesting thing to checkout for SVG rendering, may it will expose a good API, a la Cairo or similar, to help implement or port librsvg methods on. No sure, because no time to check that API now.
> For rendering, GSVGtk ask GSVG to generate string representation of SVG in XML, then pass it to librsvg for rendering. This can be avoided if librsvg exposes internal rendering methods in order to call them directly using GSVG structures and objects.
You may want to have a look at Lasem, which, contrary to librsvg, has a DOM interface that allow you to change node properties without having to reparse the whole file.
I don’t really maintain lasem anymore, but I do think this project has a good potential compared to librsvg: the last time I did some tests, it was faster and used less memory, and it is more or less on par with respect to SVG feature support.
https://git.gnome.org//browse/lasem
GSVG already provides a DOM interface, plus SVG 1.1 API. DOM comes from GXml.
So GSVGtk needs a renderer where all already parsed nodes from GSVG, can be pushed directly.
From lasem initial study, I think is possible:
a) Add a lasem renderer to GSVGtk
b) Try to access directly to lasem’s cairo renderer in lasem to push it nodes.
In order to do so I can do:
a) Add directly in lasem an interface, implemented by current lasem DOM, in order to expose cairo renderer requesting that interface to render from, so GSVG can implement that interface in order to avoid re-parsing issues.
b) Take lasem cairo code into GSVG, to expose same functionaliny described above, taking in account lasem is going to unmaintenance and prefer to not maintain C code without help from lasem maintainer.
May you can file an issue on GSVG or bug report to lasem, in order to outline prefered strategic from lasem maintainer.
GTK 4 stable at 4.6.. what are you talking about? https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
I mean, version from:
https://wiki.gnome.org/Projects/GTK%2B/Lifecycle