Calvin Williamson wrote:
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).
Oh damn. I am confusing Image and ImageData. What is the relationship
between the two? ImageData is what is passed into the scanline
processing function and what we want to pass to process(). What is an
Image then?
I was confused. I saw that ImageIterators asked for a reference to an
Image, and that I was storing an ImageIterator in an ImageData, and I
confused ImageData with Image. (though I hope this doesn't invalidate
this discussion :-)).
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.
Ah. I was thinking you made process() handle one scanline at a time so
that you could hand off work to multiple process() threads.
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?
I am not thinking of keeping ImageIterators (as a subclass of ImageData)
around in place of ImageData, but to just keep them around long enough
to iterate though the data. This is really no different than what we do
already, except it exploits the fact that a subset of an image is still
an image.
I was thinking of changing the data_inputs to the kind of interator (as
a subclass of ImageData) in ScanlineProcessor. I don't see a need to
change an iterator type after that point. You make the iterator,
iterate though your data, and then get rid of it.
This would still have the benefit of being able to pass in a list of
GeglData, since these different interators would be peachy keen in the list.
I can see ways the iterator could be designed to allow it to be passed
to a factory function for another iterater in order to change the type
(it would just have to keep track of the rectangle of the ImageData it
was created from).
I am not thinking of keeping ImageIterators (as a subclass of ImageData)
around in place of ImageData, but to just keep them around long enough
to iterate though the data. This is really no different than what we do
already, except it exploits the fact that a subset of an image is still
an image.
This would hold true for an ImageTile as well.
Of course, now that I have noticed my misunderstanding between Image and
ImageData, I need to go back and rethink my ideas, which I will do when
not on lunch break. Likely I will discover that this discussion is moot
to the question of actually modifing process() to accept the entire list
of data, and one solution might work as well as another.
Since this is probably no longer a circular reference problem, it
probably it just a matter of prefrence.
I'll talk more when I get a better grip on whats needed.
--
Dan
P.S. What is a rook iterator?
