Calvin Williamson wrote:
On 15/01/04, Daniel Rogers wrote:Oh. I love all these graphs of nodes and ops in emails. They are hard to do, aren't they? You raise a lot good points in all of your emails.
Does that mean you agree with them?
Now images are one example of a kind of data that passes through the graph. There are other kinds of data that you will want to pass through the graph as well... scalar data, sound data, geometry data, animation data, anything. So its good to separate outthese two types of things so it is not confusing. The system determines dependencies for data to be passed along a graph. Any data can be passed with the right set of nodes.This is just what maya does, with its dependency graph, its just one big fat property connecting system.
again, at gimpcon, we agreed. Images are the _only_ kind of data we should be worried about. GStreamer already handles sound, scalar, and geometry data. Even animation data is not something that needs to be handled at the "graph" level. It can be handled at a higher level, even outside of gegl.
Basically data moves through the graph by passing from property to property, so at its most fundamental level it is really a graph of property connections: those are the primary thing. The node connections are there too but really those node connections are there and determined by virture of how the various properties are connected.
I don't what we gain, except overlap with other projects and undue complexity by over-generalizing the graph. Gegl should only be an image processing library. When we want to handle sound and image we can write adaptor classes for gstreamer.
That given, there is no reason to mix up the connections with the other, arbitrary properties. For one thing, there will be properties that we don't want to be able to connect to one another, so keeping the pads seperate from the properties seems like a good idea. Futher, there is no need for all the property machinery for representing node connections. Finallay, I don't believe that the property model fits will the the graph connection model. There is a lot more than simply the existtance of a point of connection (like how many connections, how many connected, ROI's, DOD's, the GeglImage that is shared between the endpoints, etc).
Lets do away with these overly complex abstract data processing models and stick to our goal of being an image processing library.
So we have an evaluation manager set up everything after a call to the root property, it does preliminary propagation of inherited and synthesized attributes down and up the graph and queues up whatever multi-threading tasks there will be, and descriptions of those tasks. Of course these tasks are arranged so that they are done in a way consistent with the dependency graph, but that is really the only restriction. I think that leaves a lot of freedom to decide how to break up your evaluation and calls on the nodes and properties for them to do their thing.
All you have is a name and you say "the evaluation manager leaves us a lot of freedom." I just wrote a long email explaining precisely why I think things should be done a particular way, given design constraints. Did you have any coment on that?
If you want to install a completely different evaluation manager from whatever gegl one we have and with a different execution model you can do that easily (within the limits of the dependency graph again, and callbacks on the nodes and properties to their "evaluate" methods.) Like it is great that gegl can be used on top of whatever image library you want to put behind it, not just ours. Suppose you have a lot of image code that doesnt use any of gegl's approach to color models, sample models, tiles, images or whatever, then you can still hook up your system and get some graph processing mileage out of it. (Dont make me extend GeglImage or GeglImageOp, that brings in all your color models, and tiles, and data buffers... Ill pull this car over...). All you'd have to do is write yourwrapper nodes, define your properties, figure out how to serialize outyour properties, and there you have it. You can call your own image processing routines during evaluate.
If we are not subclassing GeglImageOp what is the point? If you want to do image processing outside of gegl, don't use gegl? Why should be be accomdating different kinds of image processing library that will likely want to do things completely differently anyway. I don't see how you could get that "graph processing mileage" without all the machinery of it. The machinery _is_ the graph processing mileage.
Now, I think you might be saying that you don't want to use color models, tiles, data buffers, etc. Well you are stuck with data buffers, sorry. But they are bone-dead simple that is not good reason not to. Fine. So you don't want to use color spaces? fine. You don't have to. Just don't attach one, though you can't use some nodes that depend on their existance. So you don't want to use the gegl color models? Fine. But you need to subclass your own, and you can make it as efficient as neccssary. And you need to subclass GeglImageOp, because you need to write hooks into your library anyway, so I don't see how your objection is valid. The "graph processing" machinery works with these concepts, if you abandon them, you might as well not use gegl at all.
This example doesn't do your api justice however, because you have the problem that sometimes, your property is an image, and sometimes your property is an op, and they are treated differentlyI call this a plus. Every property comes directly from being set on the node, or from the output of another node. Bothare possible.
ug. But why? How do you intend to implement this? Did you read any of my objections to this model? Do you have any rebuttal? What advantages does it give? I don't even see how the sentence "Every property comes directly from being set on the node, or from the output of another node. Both are possible," is at all relevent.
Im just trying to emphasize that the property, node and data passing framework should be kept minimal and general at the highest level. I think that you can arrange the image passing subsystem of ops in most anyway you want really within this framework.
But you are doing exactly the oppositing. Your data passing framwork can't be minimal, it is trying to do so much, and I don't see why we need that much generality. It just makes things so complicated. (and I mean complicated to implement).
-- Dan
Attachment:
pgpwj2FlrsFMZ.pgp
Description: PGP signature
