Just a little update on what I am working on. So, I started with wanted to add a mask input to unary operations. I thought that mask's should be optional inputs, so this led to a discussion about how to change scanline_processor_process and the operator processing functions so that GeglData is passed, instead of pointers to images. At this point, I have an untested, but believed to be complete version of scanline_processor_process that passes the GList of GeglData pointers after properly initializing image iterators. What I need to do now though is change every single operators' process functions. This is a sucky about of highly repetative, yet straight-foward changes that I have yet to tackle. Because of this huge change to so many files, I started looking at what else may need to affect how these functions are writtin, so we can minimize the number of times all the functions are re-written. The first thing I decided is to put in a slower, but simplier system that would allow these functions to be rewrittin more quickly, yet easilly replaced when the time comes to make decsions about optimizations. This is to put an abstraction over pixels that allows processing functions to get away with not knowing what datatype the pixel is stored as. THis would allow floats to be a general processing space, where the data is converted to floats, processed, and converted back. I was concerned about the additional overhead of this conversion, but you exsisting code already provided an answer to this. First, suppose that we can provide an interface to pixel data such that you can request and set the pixel data in whatever form you like, but if the pixel data is already in your requested form, it returns the pixel with nill overhead. Then you tell the operator what type your pixel data is in and the operator returns the best function it has for processing that kind of data. (this is nearly identical to what you already do now, except we can provide a best, instead of exact fit). This would allow us, as developers to focus on getting this working at first by only providing the function that operates in the largest (most accurate) data type we have available (float) and then later, after the code changes have settled down (or perhaps only when necessary) we can write versions of the processing functions specialized for data types. I already have a pretty good idea about where to go with this idea, but I procced to think about the problem a little further. After a little thought, I concluded that the tiling and caching system were very likely to affect how the above system was constructed as well as the best way to go about rewriting some of the operators' process functions. This prompted me to do a lot of research into caching systems (hence the cross posted email to gimp-developer). I really think I am on to a descent design for the tiling and caching system. So here is my current todo list. Flesh out tiling, cacheing system api. Write data-type independent accessor functions. Rewrite all the operators' process functions to take advantage of the last two steps, as well as the changes to scanline_processor_process. Write support for an optional mask input to Unary operators. I do expect it will be a while before I start producing a working system incorporating all these features. 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. 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). I hope this is satisfactory (e.g. I am not stepping on stuff you are working on) -- Dan
