Re: the canvas quest

[Lauris Kaplinski <lauris kaplinski com>]

Hello!

If you want to mix sodipodi into the pot:
* nrarena
- not bound to GUI library (only uses RGBA buffers and GObject)
- renders into SPCanvas (cleaned up and stripped GnomeCanvas)
  via lightweight proxy object
* libsodipodi (non existent as independent entity at moment, althoguh
  I have heard about the use of sodipodi code to render sprites in
  game :-/)
- model view based
- lighweight view
- HEAVYWEIGHT model (and still growing)

Other than that - I'd suggest to define the target audience
first. I do not believe big projects like gnumeric, sodi, abi
will ever make much use of stock canvas.

IMHO having aa/Gdk split is killing GnomeCanvas. It makes API
and internals extra complex and cumbersome, while very little
other than object type and arguments is actually shared.
If RGBA rendering is needed, separate tree can be constructed,
talking to base widget via proxy (like nrarena does).

Best wishes,
Lauris Kaplinski


On dim, 2003-03-30 at 02:11, Jody Goldberg wrote:
> On Sat, Mar 29, 2003 at 07:39:17AM +0100, Tim Janik wrote:
> > an evaluation of available canvas implementations revealed:
> > * dia-newcanvas (v0.6.10):
> >   - aa renderer not implemented
> >   - text not zoomable
> >   - doesn't use pango to render text
> Last I looked it also had a model view split which is a nice
> feature.
> 
> > * foocanvas (recent CVS):
> >   - no aa rendering (probably not planned even)
> not that I know of.  Although the rect-ellipse does have some RENDER
> extension magic to do alpha blending of content.
> 
> >   - text aparently doesn't zoom with other objects
> A good point.  This behavior would be a nice extension, but it would
> need to be optional.
> 
> > * libgnomecanvas
> >   - gets little maintenance if at all
> It gets maintenance ??
> 
> > * a wild variety of cut-n-paste versions of the above
> >   implementations in third-party projects (eel, gnumeric, etc...)
> eelcanvas == foocanvas
> and gnumeric derives from foocanvas to add a few utilities for
> grabs.
> 
> > i see a fundamental problem here in terms of effort duplication,
> > maintenance, and development platform consistency (i doubt i'm the
> > only person unsure about what to pick). so i'd like to see the
> > following issues being adressed:
> > - is there consensus about what the feature set of a future
> >   GNOME canvas platform will provide?
> 
> Hard to say.  I don't see AA as a requirement but I suspect you
> would.  It always seemed kludgy to have the aa and non-AA code share
> implementation when the rendering mechanisms were so different.
> 
> > - (assuming "no" to the above) what are peoples opinions on:
> >   a) replacing lbgnomecanvas with say foocanvas
> http://bugzilla.gnome.org/show_bug.cgi?id=79286
> 
> I'd be happy to see foocanvas become GtkCanvas.  At this point it is
> a delicate balance working on the canvas, whether to do the work in
> the core or just tack on the extensions in gnumeric's derivation.
> 
> >   b) merging foocanvas code/fixes back into libgnomecanvas
> >      (kinda defeats the idea of foocanvas being "leaner"
> >      than gnomecanvas in the first place, though that may
> >      be a questionable design goal in itself)
> 
> The main benefit of foocanvas was not 'leaner' so much as better
> integration with the gtk2 rendering framework.  The gnome2 port of
> the canvas was a performance beast.  The issues seemed to stem from
> using AA representations for the non-AA mode.
> 
> >   c) implementing an aa renderer for dia-newcanvas, adding
> >      pango support to it so it becomes a suitable replacement
> >      for libgnomecanvas
> 
> The diacanvas does have some nice features.  Chief among them being
> the model view split.  For office apps, like gnumeric, having a nice
> library of drawing objects _with_ pref dialogs.   Would be a huge
> win.  I have not done any serious work to do such a port though.
> Having a libdia or libsodipodi would be quite nice for alot of
> applications.
> 
> > - are there any other efforts currently being persued to reduce
> >   the rediculous cut-n-paste orgies of canvas code across
> >   various projects?
> 
> sodipodi.
> I've corrected lauris' email on the cc list.
> 
> None of us appear to be ready to step up to the plate and drive the
> work forward.  I've been too selfish for years and just fall back on
> Gnumeric work.
-- 
Lauris Kaplinski <lauris kaplinski com>