Development has been discontinued for a long time now!

I have now started the cairo port, and it is comming along nicely (modulo some cairo problems, that I worked around for now). Also I think that the speed is up to the one of the current engine (it does not feel slower, but I don't have any real test. Only thing that is slower is XDMCP to a slow computer ).

So I would really like some input about the stuff below, and suggestions on how to improve the engine. Please contact me benjamin@sipsolutions.net

Here is what I would realy like to do. But don't know yet how exactly.

GTK has now a direct dependency on cairo. I would like to render everything directly with cairo, for several reasons:

  • with cairo the drawing can be hardware accelerated
  • I want to add more features for drawing lines, SVGs (not as pixmap, but directly), etc.
  • Make most cairo features visible to the user. Masks, fills, strokes ... does this make sense? maybe it would be better to not export too much, and try not to create a bloated format/api.
  • speed (I hope)
But since I want to make most cairo functions available to the user, there might be a need to change the file format slightly. (Diffrent drawing operators, masks).
I would also like to have functions, or make it possible to embed one group into another. Need some format for embeding groups, or function calls. Suggestions welcome!

Here is a big sample config, which reflect my first ideas for the format. Any suggestions are welcome!

The following is not implemented and will likely change!

pattern "my_stroke_pattern" {
        /* a pattern can be anything. normal drawing, gradient, etc. */

        /* a color: */
        color = #00ff00
        /* normal drawing:*/
        path 10 {
        /* a gradient */
        gradient_type = RADIAL
        stop {
                pos = 1.0
                color = #00ff00

pattern "my_fill_pattern" = "my_stroke_pattern" { /* inheritance */
        /* here things can be changed. */
group {
        /* matching stuff */

        image 10 {
                /* normal image */

        fill 20 {
                opacity = 0.5 /* should accept opacity*/

        path 30 {
                /* ok, now this gets interesting.
                 * This is a path, so it needs to be stroked, filled */
                /* suggestion, the stroke, and fill tag */

                stroke 4 { /* number it? ie. support for stroking one path
                            * multiple times. */

                        /* setup for the stroke, caps, etc. */
                        start_cap = BLAH

                        /* dash settings */
                        dash = 3.2, 2, 1, 3 /* the dash pattern (does it need to be an even #?) */
                        dash_offset = 1.3 /* start offset */

                        /* a pattern for filling */
                        pattern = "my_stroke_pattern" /*defined above*/
                        /* or a color, for convencience */
                        color = bg[NORMAL]

                fill 5 { /* with the proposed format, this means the
                          * fill ist drawn after the stroke. */

                       opacity = 0.7 /* it should be possible to change the opacity for each operation (fill/stroke) */
                        /* setup the fill */
                        fill_rule = even_odd /* the fill_rule */

                        /* a pattern for filling */
                        pattern = "my_fill_pattern" /*defined above*/
                        /* or a color */
                        color = fg[NORMAL]


In this whole example is missing scaling. There should be direct access to the matrix with something like:

group "blah" {
        matrix = { ... }
        rotate = same as before, but allow any rotation.

But it probably makes sense to have some sort of convenience wrapers around matrix.



  • With images I have got the border, how could this be done with SVGs? How would that work? (The SVG standard would allow things like this, but the renderer won't be able to do this right now.)
  • How do you recolor SVGs? (It needs to be recolored before it is added to the cache, so the recoloring is only done once.)
  • At what point can they be cached, metasurface seems to be the best alternative.

Recoloring SVGs might be done by a simple search and replace for color values (#ff0000). This at least could be a temporary solution, until something better is found and implemented. (I realy have no idea. Problem is, that it needs to be easy to edit the SVGs.)

Speed. Should the rotation of the images be cached, or should this be achived by rotating them in cairo every time. The question is, how much slower will the software rendering be.