Calvin Williamson wrote:
On Sun, Mar 09, 2003 at 09:12:08PM -0800, Daniel Rogers wrote:
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).
Tell me a little more on exactly what you wanted to do. Im not
sure I completely understand. I dont think that data type independence
is trivial exactly. But maybe Im not understanding what you are thinking.
Do you mean you just want to convert incoming 8bit and 16bit data to float, call
the float routines, then convert back to 8bit or 16bit on the way
out? That way we are just coding the float versions only in the
beginning for gegl, and dont have to change any 8bit and 16bit
versions.
That is precisely what I mean. Except you still keep in place that
get_scanline_function system, so that when we decide this is too slow,
we can write more specialized functions. get_scanline_function (I am
getting the name wrong, I know, but I am at work and don't have the gegl
code) should return the best (fastest) function for a given datatype.
There might also be some kind of execution optimization, where operators
declare the type they prefer, and the system decides if and when to
convert datatypes before passing data to process (but I envision this
last step to be a ways off).
I started thinking about it a few nights ago and I seem to remember
concluding that it might be harder than I first thought. I was thinking
you could just add functions like get_sample_float and set_sample_float,
but any proper design should be incorporated into an object system, so
that pixel data is able to identify it's type (otherwise you need to
write get_sample_float_uint8, but that seems sloppy). (at the moment
there is no way to determine the type of data you are handed. The
current process functions just assume the system is handing them the
proper type).
In any case, I think this change is worth putting into effect earlier,
rather than later, as it is a potential time saver (and the time saving
benefits are lost and gegl gets more and more completed).
--
Dan
