Here are my design notes on where I think the class structure should head.
This is just the result of my last week or so of research. They are
just ideas and notes, but I thought it might be useful to get an idea of
where I think things should go. None of this is really solid in my
mind, but things are starting to settle down.
The things I havn't really thought about yet are (under this slightly
different model anyway):
Iterators
Eval Managers
Color Management
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.
If no one has any problems with what I am doing (i.e. people are
willing to commit my code) something close to this design is what I will
submit.
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>
My plan for caches are a prioritized stacks of caches, managed by a
cache manager.
-GeglCache-
*GeglMemCache*
*GeglFileCache*
This is a Container for Caches
*GeglCacheManager*
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*
-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*
(what I suspect I will end up with on the iterators are
interfaces that decare what kind of data can be retrieved
from the Container, and individual subclasses that are specific
to a container. This is just brainstorming for now (i.e. not
well thought out)).
<GeglPixelIterator>
<GeglChannelIterator>
-GeglDataContainerIterator-
*GeglImageIterator* (implements PixelIterator and ChannelIterator)
*GeglPixelArrayIterator* (implements PixelIterator)
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*
This stays more or less the same.
-GeglVisitor-
-GeglBfsVisitor-
-GeglDfsVisitor-
*GeglDumpVisitor*
This is more or less the same as well, with the obvious super classing
-GeglEvalMgr-
*GeglSingeThreadedEval*
--
Dan
