Re: canvas notes

[Juhana Sadeharju <kouhia nic funet fi>]

Hello. I did read this nearly two months old discussion.

It would be nice to have one scenegraph. Such scenegraph
can handle both 3D and 2D. See modern game engines how
they handle 3D and 2D renderings.

GTK already has a some sort of scenegraph built-in, because one
can trace all widgets starting from the top window. A code
was (re)posted recently in gtk lists somewhere. A better
scenegraph could be written. (Could openscenegraph, openinventor,
coin3d, etc. be used? 3D comes free.)

Scenegraph is very easy to use if the user operates on the graph
explicitly. Compare Glade and XXL (graph editor) for GUI authoring.
With Glade they suggest to predesign the GUI (on paper?).

Custom widgets can be built using existing nodes, but more
efficient widgets can be hardcoded later. Compare to Csound's
instruments (script) and opcodes (C coding of script).
This gives means to easily test new widget ideas.

Two different zoom modes can be found: one where the whole
rendering is scaled and another where individual objects are
scaled (fonts in Mozilla). In scenegraph, the first means
that the doc's top node is affected, and the second means that
individual objects under the doc's top node are affected.

Resolution-independent font renderings can be nowadays performed
in GPU.


david.bellot wrote:
>On the other handl, it is very seducing to think about an underlying
>canvas for the whole desktop (evas, display pdf, etc...) but that would
>mean we must rewrite almost all GTK lower levels. Not very productive at
>all.

Game engine authors have done the same when they switched to
OpenGL or to DirectX. Switch was very productive.


From: Damon Chaplin <damon karuna uklinux net>
>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!

Scenegraph is very modular as one may first have a basic set of nodes
and then may later expand the set of nodes. I have always kept 3D
side easier to implement first. Then 2D is programmed with constraints
and/or with special nodes. Openscenegraph etc. have already extensive
3D nodes and some 2D nodes.


From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
>2. (like Jean Br��afort says) OpenGL is not printable, and IMHO all
>applications should have a print option for any useful data they
>produce. (by print I mean either on paper or to PDF file).

I'm not exactly sure what you mean by printable.
The scenegraph is nice in sense that objects may have different
interpretations. How otherwise 3D animators could edit and save
their animations? How otherwise a renderer or a editor could output
alternatively an image or a line drawing?


From: Alexander Larsson <alexl redhat com>
>Interestingly, this is pretty much how Microsoft seem to be handling 3D
>in Avalon, as can be seen in this blog entry:
>http://blogs.msdn.com/greg_schechter/archive/2004/05/22/139744.aspx

Not all of scenegraph needs to be rendered with one method.
Not every node need to have built-in support for every rendering
architecture. The system may modify the scenegraph for managing
different architectures. All 2D nodes may be moved out of 3D
part if needed. In comparison, GTK now has a fixed "scenegraph"
built by the application programmer. So, GTK is quite limited.


From: Alexander Larsson <alexl redhat com>
>All programs that exist can be programmed on a universal turing machine.
>That is interesting, but doesn't mean that people actually develop on
>turing machines. OpenGL as an API is clearly targeted towards drawing of
>3D scenes, and is not at all what you want when you're writing a
>predominantly 2D graphical user interface, whereas Cairo is an ideal API
>for this.

Popular widget system FLTK was earlier programmed with GL.
Then they re-wrote it in X/GTK-way.

Blender uses OpenGL for all rendering. That made Blender very
easy to port to other systems. I'm not exactly sure if 3D and 2D
are all in one scenegraph, but I remember reading such plans
recently.

In fact, the system which Blender uses (scenegraph plus dependency
graph) would be needed in GTK as well. I have already though if
I could use Blender as a GUI for my applications.

Juhana
-- 
  http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
  for developers of open source graphics software