You are here

SVG graphics in Tk

The whiteboard in Coccinella has now come one step further to use SVG graphics. Well, it's not there, yet, but an important step has been taken.

The canvas widget in Tcl/Tk is way too limited to use as a basis to implement SVG support on the scripting level. For some time I have therefore developed the tkpath package which adds all needed drawing elements from SVG, see some shots, using the C plug in structure. However, this is too limited for SVG and its underlying XML tree structure. I have therefore made a new canvas widget, based on code from the existing Tk canvas, but instead of having a flat display structure, I have now implemented a complete tree structure, including a permanent root group item, which mirrors the XML structure. Some code come from the existing ttk::treeview and TreeCtrl widgets which have a similar tree layout.

Added to this widget is then all the items, styles, gradients etc. from my tkpath package. My aim is to keep 100% compatibility with the old canvas, which is needed to get acceptance from the Tcl community. All items from tkpath, which have SVG counterparts, also have a -parent option which can be reconfigured to be any group item. Such an option hasn't been added to the standard canvas items which instead, by default, always will be child of the root item.

Not all things have been implemented. One major part is the inheritance mechanism where elements get there style and display options from its parent group items. In principle, each item, or element, must keep track of its own options as well as its inherited display options. These are kept in a Tk_PathStyle struct but having two of these would become much to heavy. On the other hand, recomputing the inheritance chain each time an item is displayed, or hit tested etc., is too cpu intensive.

So while most things are in place, other need some more thoughts. Nothing released yet, and nothing in cvs, yet.


As I'm strongly in favour of SVG technology development and implementation I've been recently keeping track of your work on the canvas widget. I must admit that the result so far are great. Hope to see this project developed further in near future. Keep up the good work!

Best Redards,
Greg Hardy

Some progress has been made the last weeks. The existing code is now in cvs and the new widget tkp::canvas is in place. But the code is just a snapshot of my dev work, and many parts are unfinished or subject to rewrites. Some of the abstractions I have made aren't directly reflected in SVG as far as I can understand. While SVG is a description (document) format, Tcl/Tk is a programmig language, which is therefore more dynamic. There are currently two different abstractions: styles and gradients. I create these as separate objects within the canvas object (widget), and any item using a style or a gradient must create one first. Styles and gradients can then be configured (options change) which must be reflected in all the items using them. This notification system was a bit hard to figure out but is now in place. The cost in terms of memory is just a few words per item. Since a style can also use a gradient object, if that gradient changes, all styles (and items) using that gradient are updated, and all items using these styles are also updated. Do you get it? Hope I've got all memory handling OK.

The X11 emulation layer used by Tk sucks! As an example, each item must setup its own drawing environment for each display which can be very slow. I'd like to move this setup to the canvas display function instead, which is possible for all "my own" items that use native drawing directly, but all the "old" item types are implemente differently. Reimplementing all of them is not an option right now.