Re: Canvas API proposal


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 <>. 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]