> > Also, I feel like I am being pushy about the direction I think Gegl > should take, and I want to express some concern about stepping on your > toes. I am not trying to work without you (all?, how many people are > around anyway?), but since I have no idea what anyone else is working > on, I am unable to incorporate anyone elses goals or ideas. Please > consider this something close to my best suggestion and recommendation. You arent stepping on any toes. Its fine to think about everything you have been raising on the list so far. And this is the right place to hash out all the details of architecture that we can. I am working on details of validate_inputs and validate_outputs at the moment like I described in the previous email. > Current envisioned class list > > <interface> > *class* > -abstract_class- > > Some iterfaces. A GeglCacheable object can be moved between caches > by a cache manager > <GeglCacheable> > ImageProducers are Nodes that have outputs > <GeglImageProducer> > ImageConsumers are nodes that have inputs. > <GeglImageConsumer> Cacheable would make a fine interface, agreed. What are some of the methods you would put on an ImageProducer and Image Consumer interface, and why do you need these? > This represents some area of memory (not the same as the Current > GeglStorage) Also, here, GeglTile is just a portion of a two-dimential > block of memory. GeglBuffer is actually a continuous portion of memory. > > -GeglStorage- implements <GeglCacheable> > *GeglTile* > *GeglBuffer* I dont see why both Tile and Buffer are here. I envision the Tile has a swappable Buffer. > > -GeglData- > (GeglChannel behaves like a continuous block (through a good *non > existant* api :-) It's backed by tiles.) > *GeglChannel* > *GeglScalar* > *GeglPixel* > -GeglDataContainer- > *GeglImage* (this is because Images can be > seen as a set of channels or set of pixels) > *GeglScalarArray* > *GeglPixelArray* This is based on the current GeglData hierarchy, correct? If so, this is sort of the right idea, at least for the Data hierarchy. Except I think you are confused what GeglChannelData is. The current GeglChannelData is similar to a scalar, except it is restricted to the channel data space. eg 0-255, 0.0-1.0, 0-65535, etc. If you are going to pass an array of these things you would probably pass that as a grayscale Image with that channel data type. > This is similar to the exsisting setup, but makes use of the cleaner > (I think anyway) interfaces defined above. > -GeglNode- > *GeglGraph* > -GeglImageSource- Implements <GeglImageProducer> > -GeglReadImageFile- > *GeglReadPNG* > -GeglReadImageSequence- > *GeglReadMpeg* > *GeglSingleColorImage* > *GeglPatternedImage* > -GeglImageSink- Implements <GeglImageConsumer> > *GeglXViewer* > -GeglWriteImage- > *GeglWritePNG* > -GeglWriteImageSequence- > *GeglWriteMpeg* > -GeglPipe- > *GeglPrint* > -GeglFilter- Implements <GeglImageProducer> and <GeglImageConsumer> > -GeglPointOp- > -GeglUnary- > -GeglBinary- > -GeglComp- > *GeglConvolve* > *GeglBlur* But you need something abstract above ImageSource, ImageSink, and Filter, since you will have Ops that have nothing to do with images, and they will still have process, inputs and outputs, just they arent image inputs or outputs necessarily, etc. Also I still dont know what methods you might have in ImageProducer and ImageConsumer. What do you see in those interfaces exactly? Calvin
