Re: Scene graphs in user interfaces

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 15 August 2013 12:43, Zenaan Harkness <zen freedbms net> wrote:

> > we already have a fairly well understood set of requirements for
> > adding a scene graph API in GTK.
> >
> > my suggestion is to download and watch my GUADEC talk about the topic:
> > http://www.superlectures.com/guadec2013/future-in-the-past-designing-and-implementing-the-gtk-scene-graph
> >
> > if you can get past my annoying voice, I detail the constraints and
> > design tenets for the scene graph API work that I'm currently doing.
>
> Cool thanks. Are there any slides/transcript etc? I have a rural
> dialup only at the moment, so probably can't dl a video.

there are my notes:

  
https://wiki.gnome.org/EmmanueleBassi?action=AttachFile&do=view&target=guadec-2013-future-in-the-past-notes.pdf

which sadly don't follow exactly what I said because I couldn't read
them while giving the talk (long story). I also have a bunch of wiki
pages for Clutter:

  https://wiki.gnome.org/Clutter/Apocalypses
  https://wiki.gnome.org/Clutter/Future

it should give you an overview of where Clutter is, and where it's
going to be in the future.

> > > Of note to my mind is Evas:
> > > http://docs.enlightenment.org/auto/evas/
> > >
> > > which appears surprisingly simple in its API, yet enough for UI
> > > building, and is a scene-graph with all sorts of benefits that
> > > entails, and given the design decisions made with Evas in particular.
> >
> > my thoughts on the overall design and implementation quality of Evas
> > (and the overall EFL set) are probably well known, so I won't comment
> > on that.
>
> Ah ok. Can you refer me/us who are not appraised of your thoughts, to
> any links on the subject? I'm only interested in the technical side of
> things...

not really: it's more a collection of thoughts that I developed after
examining the current state of Evas and EFL for work, a year ago.
let's just say it left some scars, and this mailing list is
*definitely* not the right place to rant about another project
(especially one that I don't have any intent or desire to contribute
to).

> > > I hope the starting list of canvas's at wikipedia is useful. Dunno if
> > > there's an appropriate QT -dev list to forward this email to, or if
> > > there might be some cross-project mutual interest between qt/gtk/evas.
> >
> > a scene graph API is pretty much integral to how a toolkit is
> > developed and implemented. trade-offs are made, as well as design
> > decisions, based on the existing code base — especially since the
> > general idea is to *not* break API. I don't foresee any chance of
> > collaboration, here.
>
> Thanks for the feedback.
>
> I am only a Java programmer, and have no experience either way outside
> of Java's libraries. I am wondering - have you managed to catch up
> with Carsten at any conference and talk design together?

I've met Carsten — as well as meeting with the Qt developers that
worked on QGraphicsView and the Qt5 scene graph and rendering API.
I've also looked extensively at the equivalent API in MacOS/iOS
(CoreAnimation), Android, and Windows. if you actually look at the
Clutter API you'll easily recognize concepts, terminology, and even
API from all those implementations.

creating a generic scene graph is not something worthwhile. there are
other projects that try to achieve that — OpenSceneGraph comes to
mind. generality and performance are pretty much at odds. also, all
the platforms and libraries you suggested are neither using the GNOME
base libraries or even the same language that GTK+ is written in. we
definitely want to use all the core facilities provided by our core
libraries, exactly like other projects want to do the same with their
*own* core libraries; this would imply creating a generic,
unoptimized, library with virtually no dependencies — as well as
convincing other projects which already have their own solution to
switch to ours. I've been working, both as a professional and as a
hobbyist, in the free and open source software arena for too long to
know that not only adding these requirements upfront is a guarantee
for a dead project that will have barely produced a line of code in 6
months time, and that it is never going to work in the first place.

what we can, and should do, is to work on making GTK and its API kick
ass, for the people using GTK already and for the people that will use
GTK in the future.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/