Re: GtkCanvas requirements?

[Federico Mena Quintero <federico ximian com>]

El lun, 23-04-2007 a las 18:50 +0200, Carlos Garnacho escribi�> On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
> >   canvas = new Canvas ();
> >   svg = canvas.load_svg ("foo.svg");
> >   handle = svg.get_object_by_id ("bouncing-ball");
> >   handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));
> 
> I see this more as a higher level abstraction over the canvas rather
> than an intrinsic feature.

Oh, yeah, definitely.  I just want to avoid architecture-astronauting;
it's pretty easy to do with a canvas.  [In the Piccolo site, look for a
paper about a comparison between a "scene graph canvas" and Piccolo's
current architecture.  They wrote two canvases, one very layered and
abstract which was impossible to use, and a more direct one which was
okay --- they found about this by porting the same software to both
canvases.  Talk about academia having nothing better to do than...] :)

> > The canvas also needs to have performance goals defined up front.  We
> > don't want the case where people avoid using the canvas because it is
> > too slow (like what happened with the antialiased GnomeCanvas).
> 
> hmm, right, what should be a reasonable/feasible goal? visualizing a
> bunch of thousand items with little/no noticeable delay? moving a few
> tenths/hundreds around? I guess that making performance studies on the
> current canvases could help here.

It's very hard to predict what people will put inside a canvas.  I like
the idea that someone posted on cairo-list; unfortunately I don't
remember whom:  it's basically to compare the performance of
swfdec/cairo versus the proprietary Flash player.  We could compare the
performance of our canvas with an equivalent Flash drawing.

[Obligatory mention of http://www.clayloomis.com/Tetka.html - sorry for
the imagery.]

  Federico