> > Ok, so here is the big problem I am noticing. If you put an image > iterator object into an image, you end up with circular references. > Because of this, it is unclear to me how to make an ImageData manage an > image iterator with out creating a lot of problems when it comes time to > free up the memory. ImageIterators dont go in Image objects. Image objects shouldnt have any references to ImageOps, ImageData or ImageIterators. Just to the underlying tiles (and hence data buffers). And anything that holds references to the Image objects will ref and unref just like any other GObject. So multiple Iterators holding references to an Image would be fine (with appropriate read and write locks though) > > Another way of handling this is to pass the Data objects to process and > let process() choose the best iterator _and_ loop over the data > (including incrementing the iterator). I was thinking along these lines. > We could also pass both the data inputs and the data iterators. I don't > like this because it feels like we are passing pointers and pointers to > the pointers, which is pointless. Agreed. We shouldnt have to pass both. Im hoping input and output Data objects is enough. > Finally, we could generalize data iterators (which is what we need to do > eventually, anyway) so that you can create iterators for other types of > data, even ones that don't necessarly need the concept of iteration > (like scalars). I kinda don't like the idea of faux iterators (cause > they don't do what they should), Agreed again. Doesnt make sense. > so this is what I suggest: > Move ImageIterator to a subclass of ImageData. Something like this might be okay. So far the Data object is a wrapper of a generic value (a union essentially) and a param specification that will be used to check the value when setting up evaluations (in validate_inputs and validate_outputs). > This makes sense, > because an image iterator presents a subset of ImageData (and thus, > valid image data). This also makes sense because an ImageIterator is > just an image, with a smaller rectangle, that also happens to know how > to move the rectangle around the larger image. Sure. But what happens if you want to change to another iterator type? (rook iterator or column scanline iterator) Its difficult to change the type(class) of your ImageData subclass, right? Calvin
