Calvin Williamson wrote:
The purpose of a graph is to express algebraic relationships between
different data types. This is where I have trouble finding examples of
where we would best be served by generalizing data inputs. When would
you want to use this infrastructure to, say, add two scalars, or take
the dot product of two vectors. You might use some kind of object to
generate your animation parameters, but you don't need all this
algebraic stuff to do that.
Im not sure what you are talking about when you say you
dont need all this "algebraic stuff". What exactly are
you referring to?
The execution graph can be thought of an algebraic statement about
images. (let capital letters be images and lowercase be scalars).
f*Blend(A+B*C,A+(c+D))
can be broken down into an execution graph in gegl.
Thus, you can use the graph to represent algebraic relationships. It is
the same reason why gcc breaks the C and C++ parsed file into tree.
If you are not representing algebraic relationships, the graph is
overkill. Consider an animation system where you need to change some
parameters every frame. Presumably you have some object that generates
the parameter based on the frame number. If all you are doing is
generating parameters with one object and setting parameters in another
object, you are not doing anything that requires a full fledged graph.
Since you are not algebraicly manipulating the parameters (which is the
equivlent to passing them through the graph) you can achieve the same
result by providing an alternate, simpler means of setting the
parameters (like signals, as I suggested).
While using the graph to manipulate all parameters works, using only
images as the sole datatype that is passed through the graph is far
simpler and thus easier to achieve. We already have the signal system
(since we get it for free with GObjects) and we can use that to set
parameters that don't required the complication of a graph representation.
--
Dan
