Re: canvas notes

[Havoc Pennington <hp redhat com>]

On Sat, 2005-09-10 at 10:29 +0100, Damon Chaplin wrote:
> On Fri, 2005-09-09 at 20:23 -0400, Havoc Pennington wrote:
> > On Fri, 2005-09-09 at 09:53 +0200, Alexander Larsson wrote:
> > > * OpenGL
> > 
> > Any thoughts on that 3D vs. 2D thing? i.e. it seems like we want to be
> > able to mix OpenGL and Cairo at will, but it isn't clear to me what that
> > really means.
> > 
> > Kind of a similar question to is a compositing manager best done with
> > RENDER or GL as the foundation maybe...
> 
> I think you should take it one step at a time, i.e first get a 2D
> zoomable, printable, cairo canvas working, then think about 3D.
> 
> Otherwise you'll probably spend the next year just discussing what
> features should be in it!
> 

I'm not suggesting blocking on anything like ultimate-3D-canvas, but I
do think it's worth thinking about how the two relate.

One idea is a sort of 2.5D, where the canvas is only designed for a 2D
scene really (you can't move the camera arbitrarily, it's always the
straight-on view of a big plane) but you can use e.g. pixel shaders and
other "3D" effects. This means defining that the canvas always has a GL
visual maybe, don't really know.

The simple approach is that you'd make your 2D canvas and then embed
that in 3D scenes later, or embed a 3D scene in the 2D canvas, and then
there isn't much relationship to worry about.

How does it work on OS X or Windows Vista for example? They are
primarily 2D but use some 3D effects.

Just continuing my campaign to be sure the canvas is interesting enough.
What I'd like to see is: _better_ graphics easy enough for the
programmer to use that people regularly use them to enhance the UI
beyond where it is today. But better doesn't mean higher quality
rendering, it means more user feedback and direct manipulation and that
kind of thing. Thus the focus on animations, being able to mix in
widgets, layout capabilities, and being able to trivially implement
behaviors like drag-and-drop of items. I think zoomable/printable are
pretty easy to do even without a canvas, now that we have Cairo. So that
bar may be too low to be worthwhile. GnomeCanvas was mostly about
"improving rendering" and to me that by itself doesn't merit a
canvas-type API; just write your expose handler! The point of the canvas
is programmer convenience in making custom not-just-stock-widgets
interfaces. It's largely a convenience API. Or another way to think
about it is that it's a different widget system core (gtkwidget.c,
gtkcontainer.c) that encourages more "free form" apps.

I do think 3D effects are a good bit lower priority than some of the
other stuff like animations and behaviors and widget embedding though so
agree with your basic sentiment.

Havoc