Gtk Canvas

This page tries to collect highlights and drawbacks for the most known canvases around, plus some other information that hopefully will be useful to determine a sensible feature set and the best candidates to fill the canvas gap in GTK+.

Potential candidates for a new GtkCanvas are marked with a colored row. Other canvases are just for comparison.

WARNING: This is not a list of all canvases in the entire world; it's just meant to list potential canvases that can be used by, or folded in, GTK+ for a future release. Do not add your favourite pet canvas library.

Use Cases

• Interactive diagrams
  • plots
  • UML editor, entity-relationship, ...
  • Desktop publishing app
  • Multi-track audio editor
  • Air traffic controller simulator.
  • Database relationship viewer.
  • PIM Synchronizer connection viewer.
  • ...
• Possibly several views on the same data
• Printing

• Creating fancier UIs for apps, possibly with embedded widgets (control-center shell, MugShot, something like GMail, ...)

• Animations and games
• show and manipulate pre-drawn graphical content (i.e. load from a .svg, get objects by their name, ...)
• Having a concept of "scale" for zoomable UIs.

Some Links

GnomeCanvas

This is the existing (unloved) GNOME canvas, included here for reference. We should try to avoid regressions when choosing functionality for a new canvas

• API Reference: http://library.gnome.org/devel/libgnomecanvas/unstable/index.html

• Repository: http://git.gnome.org/cgit/libgnomecanvas

libccc

A potential candidate for the new GtkCanvas

• Project Page, Roadmap: http://live.gnome.org/Criawips/CriaCanvas/

• API Reference: http://kenny.imendio.com/~sven/apis/libccc [link broken]

• Repository: http://cgit.freedesktop.org/~herzi/ccc/

GooCanvas

A potential candidate for the new GtkCanvas

• Project Page: http://live.gnome.org/GooCanvas

• API Reference: http://library.gnome.org/devel/goocanvas/unstable/

• Repository: http://git.gnome.org/browse/goocanvas/

• TODO-List: http://git.gnome.org/browse/goocanvas/tree/TODO

FooCanvas

Unmaintained

• Repository: http://git.gnome.org/browse/foocanvas/

Hippo-Canvas

Unmaintained

• Project Page: http://live.gnome.org/HippoCanvas

• Repository: http://git.gnome.org/browse/hippo-canvas/

• TODO-List: http://git.gnome.org/browse/hippo-canvas/tree/TODO

• Tutorial: http://developer.mugshot.org/wiki/Hippo_Canvas_Intro [link broken]

GeoCanvas

Uses an internal copy of FooCanvas, seems unmaintained

• Project Page: http://sourceforge.net/projects/geocanvas/

• API Reference: http://geocanvas.sourceforge.net/crcanvas/crcanvas

• Repository: http://geocanvas.cvs.sourceforge.net/geocanvas/

clutter

3D canvas, hardware accelerated, used by GNOME Shell

• Project Page: http://www.clutter-project.org/

• API Reference: http://docs.clutter-project.org/docs/clutter/unstable/

• Repository: http://git.clutter-project.org/?r=clutter

• Cookbook: http://docs.clutter-project.org/docs/clutter-cookbook/unstable/

• Tutorial: http://www.openismus.com/documents/clutter_tutorial/1.0/docs/tutorial/html/index.html and repo here: http://git.gnome.org/browse/clutter-tutorial

Qt4 Graphics View Framework

Added only for reference

• API Reference: http://doc.trolltech.com/4.5/graphicsview.html

Rapicorn

Written in C++

• Project Page: http://testbit.eu/wiki/Rapicorn-Introduction

• Repository: http://git.testbit.eu/Rapicorn/

Concepts

Notes

• Primary Layout model: How items are layed out on the canvas:

  • "scene graph": the entire scene is constructed free-form, with every component of the scene declaring its spatial and dimensional attributes; the whole scene is a graph (hence the name) where every node might have children and at least one parent (often just a single parent). Layout constraints are usually implemented inside containers. See Scene graph on Wikipedia.

    • Roughly like GtkFixed or SVG.

  • "boxed": the scene graph is constructed only following layout constraints, usually following a "box model". See Box modeling on Wikipedia.

    • Roughly like GtkBox, GtkTable, etc. or HTML/CSS.

• Infinite scrolling should be defined or removed; as far as I understand, it's the ability to wrap around the viewport, which is expected from a canvas displaying maps but it's not really a requirement. many canvases can implement this functionality right on top of their own API. EmmanueleBassi

  • It's the ability to scroll beyond the "core document", just like in gnumeric where you can scroll to the last row available in a spreadsheet and beyond that.

Basic Features

Notes

• Generic Positioning: Whether items can be positioned via a base class interface, instead of only via specific APIs for derived shape classes.
• Accessibility: Whether it uses ATK to provide information about the items.

• Printing Support: For instance, make it easy to render to a cairo context in a GtkPrintOperation.

• Item Grouping: TODO: This should be more clearly defined.
• Unit Support: Whether distances can be specified in real units rather than just pixels.

• Embedded GTK+ Widgets: Whether the canvas can show, for instance, a GtkEntry. Ideally, the widget would scale/rotate/etc just as other canvas items do when they are transformed.

• GTK+ CellRenderer: Whether the library offers a GtkCellRenderer objects that can render the canvas into a treeview cell.

• Pixel Alignment: Whether attempts are made to align items on display pixels for better appearance.

• Automatic Layout: What modes are used, when automatic layout is offered - that means any automatic layout (like GtkBox) rather than just exact positioning (like GtkFixed):

  • WxH: Width for Height
  • HxW: Height for Width
  • NaS: Natural Size
• Primitives: The basic items offered by the library.

Highlevel Features

Notes

• Built-in DnD support: Whether items can be moved on the canvas without needing to implement much code.
• Serialization: Whether the state of the items (including its children) can be saved (e.g. to a text markup) and reloaded later.

• Rapid Prototyping: Whether the GtkBuilder API (and glade in future) can be used to place items on the canvas. Probably related to Serialization.

• Inline text editing: Support for text editing without an embedded GTK+ widget. This provides better visual feed back, as you see what you get when editing.
• Non-scaled items: Whether items can be marked as not-for-scaling when the entire canvas (or maybe group) scales. For instance, graph axis names, place names on maps.

API Details

Notes

• Opaque Data Structures: Whether the C struct may be accessed directly, or if only functions should be used.
  • Doesn't seem unfixable, so it doesn't seem very relevant to the choice. murrayc.

    • It's unfixable without breaking API/ABI, so it should be done before integrating any code in GTK+. EmmanueleBassi

• Initial Object Ownership: C Convenience API to reduce repetitive code.

  • For instance, GtkWidget uses an initial floating reference, in combination with GtkContainer which sinks that initial reference.

  • Not relevant to most language bindings.

Metrics

• Lines of code regarding sloccount, without auxiliary code like test suites, examples or similar.

Comments

• A lot of desktop apps that render into a canvas, will eventually want to export/render to HTML as well and in this case it might make sense to keep the two implementations in sync by simple always exporting to HTML and just using a webkit "webview" to render the HTML in the desktop app. HTML5 has webgl and canvas for non-retained mode drawing, it offers nice interaction and if you prefer scene graph you can always use plain HTML with CSS animations/transitions.

• Another thing to compare is performance: for instance, to how many canvas does each implementation scale? (a bench could be tring to draw 1000, 10000, 100000 etc simple rectangles, both with and without intersactions etc) - PaoloBorelli

  • I'm working on some benchmarks for - at least - goocanvas and libccc (as these seem to be the two candidates with maintainers who like to see a GTK+ inclusion) - SvenHerzberg

  • Evas performance is done with a tool (named Expedite) which compares the speed of each feature for all the supported engines. It could be used to compare the different canvases.
• "Items Grouping" should be more clearly defined, or split into sub-features. For instance, in goocanvas, child items use the transformation and style of their parent group. What does it mean for the other canvases? murrayc

  • the same happens for Clutter as well: the transformation matrix of a container actor is also applied to its children (or should be: it's not enforced, so you can override this behaviour). - EmmanueleBassi

    • sounds like the typical scene graph model - MathiasHasselmann

• A minimal code example (preferably in Python) that does the same thing for each canvas widget would be most interesting.

Any thoughts/comments? please write them here