Future

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.