On 22/09/04, Øyvind Kolås wrote: So far I agree with most of your comments on notation and conventions. More on this in a couple of days. Hopefully we can straighten those out once and for all. Thanks for uploading the html notation page. Also I have a checkin eminent that pares back some of the connection stuff to be more minimal and in line with how we imagined it a while back. Im shooting to get it checked in this weekend. > On 09/21/04 23:17:28, Øyvind Kolås wrote: > >The act I call processing is called evaluating in GEGL, I feel this > >is an issue where I probably have a stronger bias towards the > >terminology > >I have been using, both terms probably have merit, and I'll leave the > >term process in gggl for the time being. > > I after spending some time today looking closer at the GEGL api, I have > rediscovered more of the reasoning that it is called evaluate in GEGL, > in GEGL you are only able to evaluate a ROI (region of interest) on a > particular root node in the graph. The region of interest, and minimal > recomputation which this approach advocates is interesting, but it has > a shortcoming. Right. You do want to have some sort of minimal recomputation scheme and it would be great if it wasnt just setting one region of interest on a root node like it is now in current gegl cvs. This is not ideal. I agree you dont want just a single invocation style evaluation manager. How does gggl handle multiple regions of interest that come from pulling on different nodes in the tree? Or do you just recompute everything in all the dependencies? I had imagined that for a tile-based approach, you would be putting tasks on a work pile and these would correspond to tiles and an area desired on each tile. If multiple roots were requesting data then it could be that the same tile would have multiple regions being requested on it. Something like that seems like what you want. > The approach doesn't easily facilitate multiplie active sinks at the > same time, something that might be beneficial for rendering thumbnails > in the composition treeview in GIMP. The approach needed with the > current evaluation manager is to issue a seperate processing step for > each thumbnail that one wants to generate. In bauxite I have been doing > color correction of video where I render both color corrected > video,histogram and chromatic diagram, to facilitate this with the GEGL > approach you would have to composite theese images into a final larger > image to be able to get away with a single invokation of the evaluation > manager. Agreed. single invokation is not what we want. > gggl has the facility of setting the "active nodes", this is actually > just defining which sinks, and all their dependencies should be > rendered. Perhaps the GEGL api could somehow be extended to allow > multiple roots, and regions of interest? I fear the consequence would > be a more complicated API. Active nodes is a great idea. Each active node means that is a node that is currently interested in pulling data from all its dependencies, right? The other thing you mentioned in your previous email about GIL is completely true as well. The GIL approach is not something to think about right now I think. It would be nice if you could write generic image processing code with ease, but it is not an easy approach to think about for gegl. There are a few image processing projects around that are trying to do it (vigra, olena are two), but they of course are using C++ meta-programming techniques and they are far from intuitive or simple to use. (They might claim different though). Anyway I think we commit to stick to double or float as the default, and decide which other types to support as well, and try to make it as easy as possible to add new types, but without burdening it all with a code-generating tool right now. Calvin
