Re: the canvas quest

[Havoc Pennington <hp redhat com>]

On Sat, Mar 29, 2003 at 07:39:17AM +0100, Tim Janik wrote: 
> i'm still in the need of a capable canvas implementation for beast
> (http://beast.gtk.org) that basically supports:
> - libart based anti-aliased rendering

At this point you may also want to look at Xr/Xc as the rendering
engine, http://www.xfree86.org/pipermail/forum/2003-March/000032.html
http://www.xsvg.org/
 
The main advantage over libart is that it abstracts things such that
it can use hardware accel when available, and is being actively
proposed as the new standard X vector API. Disadvantage is it's
probably in more flux than libart and isn't *yet* standard in any way.

> - is there consensus about what the feature set of a future
>   GNOME canvas platform will provide?

People mistakenly (and over some protests) were using pre-2.0 canvas
as an implementation detail of other widgets, primarily for the
no-flicker capability. However, with GTK now supporting no flicker and
32-bit coordinates natively, the canvas just adds overhead in that
situation. Also, custom widgets are much more strongly discouraged
these days as we have better standard widgets and custom widgets tend
to hose accessibility and themes and keynav and so forth.

So canvas has become much less important, and perhaps now needs to
focus much more specifically on being useful for custom
displays/editors of various kinds.

At the same time, there's a standard programming proverb "don't use a
third-party component for the core functionality of your app," which
would seem to imply that trying to make the canvas cover apps such as
sodipodi may not make sense.

> comments, corrections etc. are aprechiated. after all there seems
> to be the need for a much larger problem to be solved than just
> finding a canvas implementation for beast.

My main comment would be that having "aa mode" and "regular mode" is
really broken; it was a bad idea in nautilus too, where it turned out
we could just optimize the AA stuff and make it fast enough and dump
the regular mode.

Using Xr/Xc, presumably the two modes are automatically the same as
the render library already abstracts them. But even without that,
libart vs. X primitives vs. whatever should be abstracted away by the
canvas widget, not leaking out as multiple modes. I guess the problem
here is to have a Drawable object to pass to the draw handler that can
be client or server side, instead of specifically exposing a
GdkDrawable or a byte array.

The other big issue with libgnomecanvas is simply having its own
double buffering and damage region stuff, that should all be dropped
in favor of using native GDK code. But this is a relatively simple
change presumably.

One does get the impression that Owen is right when he says it's
pretty hard to design this widget until we have a standard vector
graphics API to use - at least on the X level, if not in GDK.

Havoc