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. > > 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. Of course. I completely agree. > 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). Agreed again. Calvin
