* Calvin Williamson <calvinw@xxxxxxxxxxxxxx> [040923 18:02]: > 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? Correct this can also be considered "multiple roots" > 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? It just passes full frames at all times, which works quite well for video editing (scanline based rendering could be added to the current model to gain some performance.) A longer explaination of the gggl processing model follows, it has several shortcomings but I chose the path of least obstacles to get a working system. --------- gggl processing: step 1) clear active flag on all nodes, and then set activate flag on all nodes in active set (recursivly flag providers that are not flagged active for all dependencies of "active/root nodes" step 2) validate various requirements (number of input pads set, lack of cycles,. etc.) bail out if there is a problem. step 3) call the init function on all nodes in active set, (the only thing that comes to mind being very important being in the init part of processing, is setting of output pixel format, e.g. png can be either 8bit or 16bit rgb, rgba, gray or graya. step 4) negotiate the color space of all connections, by requesting a prioritized list of supported pixel representations for in_pad / out_pad, insert a proxy node if no agreement could be reached between two nodes. step 5) do a topological sort of the active set (should probably be replaced by a visitor used in step 6) step 6) invoke the process method on each node in the active set step 7) remove proxies inserted in step 4 ---------- One should probably create a temporary graph, (in gggl a node is a small wrapper around the actual Op instance), thus it would be possible to work on temporary graphs instead, doing transformations on graphs (reordering operations, placing color space conversions at the more correct places, collapsing affine transformations etc. could then be done in an easier way, I have not studied in detail how GEGL does this bit.) > 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. One of the advantages of tile based processing is the locality,. reducing the amount of memory that is accessed when processing,. ideally when doing rendering of a standard image stack where all layers are aligned, one would process one tile at the time,. from bottom to top to keep the data in memory. I have some problems merging these two thoughts in my head, but it would essentially be a scheduling problem. /pippin
