Calvin Williamson wrote:
I recommend for the time being, just think about the floating
point case, dont worry about abstractions like this just yet.
I know there are a few 8bit and 16bit data types there, we
should just keep them to a minimum until we are ready to
go further.
My point was that since I need to rewrite all the functions anyway, why
not put a little code elsewhere for data type independence (with, say,
just floats to start with) and then rewrite the process functions to
take advantage of this new api, while rewriting the process functions to
accept GList's of GeglData? It seems like a good time to implement the
feature, since all that stuff need to change anyway. I really think
that once you are changing all the processing functions, adding data
type independence is fairly trivial. (and in fact more efficient, since
someone doesn't have to go through all the code later on).
Like I said above, just concentrate on the float case for now for
all the stuff you are thinking about. The kind of technology you
are talking about will come later.
See above.
I really think I am on to a descent design for the tiling and caching
system. So here is my current todo list.
I believe thinking about the tiling is fine, and I think you might
want to do that separately from any caching. Just assume that all
tiles fit in memory for the moment. There is quite a bit of
work to do just to get Images that have multiple tiles,
and Iterators that are tile-aware, aside from any caching issues.
While I think tiling and caching should be mostly seperate, I think it
deserves thinking about how you would cache tiles, 'cause that may
effect what the best design for a tiling system is. I really just want
to think about them enough to determine how they might be connected, to
avoid having to rewrite them too much later, when the other system is added.
Flesh out tiling, cacheing system api.
I recommend Think about the tiling first, ignore caching for now.
See my comment above. Also to put my ideas any way, the only reason we
consider writing a tiling system at all it because of it's more
efficient cacheing potential. If we weren't cacheing things, then we
wouldn't need to tile things, so I believe that the best tile design
will reflect that. I.e. the best tile design is one that is the most
efficiently cached, and accessed (and in that order, since retrieving
from the cache is likly to be a bottleneck).
And while I am thinking about the tiling and caching stuff, I and really
just thinking from an api point of view. I want to determine how it
might affect other systems I am working on so that I can prepare these
in-flux systems for future changes as much as possible (with out going
too overboard). Like, for example, all the operator process functions.
(sort of a "I am changing it now, so what other changes can I stick in
while I am here" approach).
Write data-type independent accessor functions.
Just do floating point cases for the most part. Dont worry
about the data-type independent stuff right now.
I addressed this a few paragraphs above, I really think this is a simple
change while I am in there futzing with things.
Rewrite all the operators' process functions to take advantage of the
last two steps, as well as the changes to scanline_processor_process.
Rewrite them to be passed the data lists like we discussed would
be a good first step.
Write support for an optional mask input to Unary operators.
You can do this after you have the data lists passed the scanline
routines. Its independent of any tiling issues you mentioned above.
I think I may have already addressed this, but you are right. It is
independent. But since I am in there, I thought I might do some future
good by trying to figure out what else might need to be done in the same
area, since it is easier to make small changes to these functions while
I am in there already.
I do expect it will be a while before I start producing a working
system incorporating all these features.
Dont try to work on everything at once. Just do things
incrementally so we can re-factor it gradually and
figure out if we are doing the right thing as we go.
I just mean that it will take a while to feel comfortable with my vague
design for tiling and caching, and then it will take a while for me to
rewrite all the process functions. (I am thinking maybe a week or two,
depending on how much spare time I have).
The next thing I submit, will only be a change to
scanline_processor_process to pass GList* of gegldata, as well as
updated processes functions (that will, if possible contain a couple of
other, simple but important changes just cause I was already thinking
about them).
If you want, I can send you the changes I have made so far to
scanline_processor_process (and a few other files). This code,
however breaks gegl.
Email them to me and Ill have a look.
I do that soon.
I am starting to work on the tiling and caching system right now,
outside of the gegl source tree (to flesh out ideas). When I get
something working in that area, I will let you know, and you can take
a look at that (if you want).
And, I might add to what I said: I have just realized that this is a
distraction, I should focus on the operator process functions and not
work on the details of the caching system just yet (but soonn . . ..
yes. . .my precius (he he he) :-) I think all this tiling and caching
design is amusing me).
ok, I think what we are working on is mostly orthanganal, but I do have
some ideas about color space changes that you might be interested. I
post them when I get a chance.
--
Dan
