Calvin Williamson wrote:
I think the difference between GeglImageData and GeglImage becomes a little
more clear when you say that GeglImageData stands for a rect on an image
(the result rect) that you want computed. If there were several threads
computing different parts of an image, I think there will be several
GeglImageData objects all pointing to the same underlying GeglImage,
just each one is computing different parts based on their result
rects.
Ahh, ok.
You could try to coelesce ImageData and Image, but you will have
to find a new place for information like the result rects,
and the synthesized color models that are computed during
the pre-passes of the graph. I dont think you should keep that
information in the GeglImage object directly.
ok, I was thinking the process worked differently. So the original
paper suggested that all those rects be stored in an image, but that
obviously breaks down if you want to have multiple threads working on
different parts of the image. Though if you have multiple threads
working on the same image, doesn't that mean they all have to have a
different GeglData? How is that implemented?
It makes sense to me though that images pass between operations. I
think it might be clearer to not have Image and ImageData. Let
GeglImage contain everything about buffers of pixel data. The let some
other object (perhaps GeglExecutionPlan?) contain all the state
information necessary for execution. This could also be where all
differnt kind of hints and optimizations be collected. I think these
names make it clear that GeglImage is all things image and
GeglExecutionPlan is used to help plan out how you are going to execute
things.
I am not sure if this is correct in your view, but I see image
operations passing around objects that behave as images (e.g. the
buffers that image operations operate on are contained in actual
GeglImage objects).
--
Dan
