Re: Canvas API proposal

[David Bellot <bellot inrialpes fr>]

 Hi,

I started to work on a GTK canvas widget some time ago (it's still a 
work in progress so be patient). So far, I'm designing something which 
is in the spirit of things like Gnomecanvas/Evas/Jazz/QCanvas ( ;-) ), 
i.e. I think the basic functions of a canvas are :

- items management and representation of simple AND complex objects. 
Examples of simple objects are : simple geometric primitives, SVG 
objects (that is you create an item by loading a svg file without tears 
and pain). Examples of complex objects are : infinitely sized objects 
(background pictures, grids, game's landscape, animated item, 
hierarchical objects (item of items like in gnomecanvas), external 
objects like a frame with a gstreamer stream, like a GTK widget, like a 
Pango text objects (so that not to care about text rendering as Pango 
does a good job). This list is not exhaustive of course. Feel free to 
add things I forgot,

- scene-graph like representation. Many examples are provided by systems 
like Jazz, Piccolo and gnome-canvas. Hashtable are interesting but can 
be optimized in many ways by considering the topology and placements of 
objects in the canvas. A scene graph leads directly to MVC features,

- local displays, i.e. views in the MVC framework based on the scene 
graph leading to possible optimizations so that to speed up and smooth 
the rendering of objects. Local views can be used to render the canvas 
to something different than a screen as Cairo is already able to render 
to PDF, PS, SVG and so on. This function is important to reduce the 
programmer's job and brings some sort of printing unification (no ? ;-) ),

- scheduler : used to manage what, where and when to render (especially 
in the case of animated objects). This is not a big deal to write but 
could help the programmer a lot. The programmer defines several views 
(or local displays), insert animated objets with a function like 
gtk_canvas_load_svg_file(.... blah blah blah ...) and don't care about 
the animation anymore as gtk_canvas manages everything for him/her,

- coordinates system : for a programmer, tracing a curve should as 
simple as drawing a polyline with the real values and not transformed 
value. There are many applications where the programmer would like to 
define its own coordinate system or at least use to non-classical 
coordinates system like polar coordinates for example.

Other functions could be (i.e. functions that would be in the version 2 
of gtk_canvas for example) :
- painting servers
- infinite zoom to deal with hierarchical and embeded documents,
- plugin-based objects (maybe I could unify external objects with that),
- OpenGL objects (why not ! We can dream of a canvas able to display 3d 
objects mixed with the classical 2d objects. This is not completely 
stupid since the integration of OpenGL and Cairo (and thus GTK) through 
the glitz layer,
- XML canvas content's description so that to instantiate a canvas with 
something like gtk_canvas_create_with( <a xml file>) like in glade (by 
the way, that could be a extension of the glade file format, for example),

Actually, extensibility could be achieved through an external type-like 
object like the one I told before.
In my work, the three main goals are :
- optimized and fast scene-graph representation. This is why I said 
before hashtable could be limited for that purpose (even if I currently 
prefer hashtables ;-) ),
- basic functions and helpers functions. The first are all the objet's 
method, the second are used to simplify programmer's job,
- code re-using : Cairo, Pango, <what-you-wish>o and so on... For 
example, I don't care about rendering objects. Cairo does a good job for me.

A link that everybody is welcome to discuss: gtk-canvas-design 
<http://david.bellot.free.fr/canvas/design_of_the_GTK_canvas.html>. I'll 
update this page as my work on gtk_canvas goes further.
And, oh yes, I forgot, I need a canvas for two purposes: to draw graphs 
(with nodes, edges and so on...) and for a svg-based game that I'm 
working on.

Best  Regards,
David Bellot
bellot stat berkeley edu