Re: Canvas API proposal

[David Bellot <bellot stat berkeley edu>]

Juhana Sadeharju wrote:

> I would agree on the scenegraph as the storage of objects.
>
> Canvas or not, I need a system which both draws objects (e.g.,
> polygons) and provides interactive control of the objects.
>
> Perhaps polygons are poor example because they make people
> think GtkDrawingArea. What if I want make a slider which is
> drawn with OpenGL, probably drawn and moved in 3D (e.g.,
> a lever). That lever should have equally simple API as
> the GTK slider has; both are widgets.
>  
Yes, I'm thinking to such things. But, I'd like to understand better
this notion before incorporating it into my framework.
Basically, having a 3d scene graph like to represent a 2d interface is
definitely not a good idea as it would put more complexity than needed.
Having a simple list-like (or tree like) scene graph like those commonly
used in regular canvas is a bit poor to represent things like the one
you said before.

A use case could help : what you want to have is a few OpenGL (or 3d)
objects on your screen and you want them to be treated equally as other
"classical" 2d objects.
For example, I'd like to have a 3d pinguin on my screen showing me what
button to click because as a beginner I'm lost with this new
Make-your-foobar "Computer-Aided"  application.
The pinguin is 3d and, that would be nice to say to that pinguin object
: " go and point to an object named "button_32" without having to
program that. What would it mean ? It means that "button_32" is a known
object, its position is know and as a programmer, I just have to code a
loop to translate my pinguin from point A to button_32 asking the canvas
to tell me when a collision with button_32 occurs so that to finish my
translation loop.
OK, it's just an example, and maybe, you guys, have smarter examples and
use cases. Go ahead.

Anyway, storing objects in a scene-graph allows many operations that
would be impossible before. Of course, it consumes more memory and more
processing power. This is why Intel and AMD engeeners have a so good
salary ;-)

> Consider a moment that the canvas would be an OpenGL only.
> The canvas should have a system for simultaneous handling of
> 3D objects and of 2D GUI objects. Both drawn with OpenGL.
> In scenegraph this would probably mean perspective and orthogonal
> transformation nodes, and a drawing order node.
>  
I'm not sure that we want to reinvent the wheel and mix 3d scene graph
and 2d scene-graph as well. It introduces an unneeded complexity that is
far from the real goal of GTK+. But people want to have 2d and 3d in the
same application now. So, I finally guess that we must consider that.
(such an answer is called  a Norman-French answer : you answer yes and
no to the same question ;-) ).

My question is still the same : what are the needs in term of 3d objects
in a GTK application ? As soon as we have an answer to that, I guess we
will have a good idea how to introduce 3d into a GTK canvas.
Having OpenGL in the interface is one thing : at least you can think
about having Cairo themes and glitz behind it. That's opengl. At most,
you want to have a 3d world like the Sun's one or even like those in
Sci-fi movies.
It seems people want to have a bit more 3d in their interface. Why ?

David