Re: the canvas quest

[Alexander Larsson <alexl redhat com>]

On Sat, 29 Mar 2003, Jody Goldberg wrote:

> On Sat, Mar 29, 2003 at 07:39:17AM +0100, Tim Janik wrote:
> > * 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.

Yes. And I don't plan to add any. The reason is that when you say AA you  
really mean a totally different rendering model. Normally something like 
postscript style bezier paths and general matrix transformation of 
objects. This is not at all what foocanvas is meant to do. Its for 
implementing much more widget-like objects, such as the nautilus icon 
view, not to build a high-quality vector graphics app.

I personally think it will be hard to come up with a design for an AA 
canvas that will be used by the major users of AA. Vector graphics 
application for instance need much better control of the rendering 
pipeline than what a canvas library would give them.
 
> >   - 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.

Its useful for some things, but it is very hard to do right. Font metrics 
don't scale linealy, so you can't just scale the font size. That may be 
good enough for some apps, but certainly not for all. The moment some 
other geometry depends on text measurements you're gonna see weird things 
happening when zooming.
 
> > * libgnomecanvas
> >   - gets little maintenance if at all
> It gets maintenance ??

No.

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

Yeah. foocanvas is a libegg style library, apps are meant to cut-and-paste 
it instead of depending on the installed shared lib. This is mainly due 
to political reasons. I just need something that works, and didn't want to 
conflict with the official canvas or introduce more modules in the gnome 
framework.
 
> > 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.

Yes. The typical model when you do AA is very different than otherwise. 
I think it is a very bad idea to do both AA and non-AA with the same 
widget.
 
> 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.

This does seem to be a large part of the canvas problem...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a Nobel prize-winning skateboarding master criminal who hides his scarred 
face behind a mask. She's a blind hypochondriac museum curator fleeing from a 
Satanic cult. They fight crime!