> > > Will there be other kinds of iterators in the future? E.g. will there > be a sliding-neighborhood iterator, or whole tile iterator? Yes. I think we need all of those you mention. > And if so, > should an ImageOp be allowed to have more than one iterator associated > with it at the same time? Primarily I think that each ImageData object would deliver back one type of iterator - say one of the types you mention. But if different threads (once multi-threading is there) were filling different areas on an image, then they would each need an iterator for the portion they are filling in. I think in that case each thread would be talking to a different ImageData object though. These different ImageData objects would be pulling data from the same underlying Image though. > Also, you mention that the instantiated op "knows" what order it's data > inputs and outputs are in. How does it know that? > During various object init methods, ops create and add input data objects to the data lists in the Op class. The order the input data is added in these init methods sets up the order they will be passed back from the evaluation visitor to the Filter and back down to the op subclass that is doing the pixel processing. Check the gtk-docs for GeglOp, the section called Data, to see an example. So when the op is passed back this list, its in the same order that was set up when the op created the input data objects to begin with. Calvin
