hi, Danko Dolch schrieb: > Oh interesting topic! > > To decide for a good "composition rendering strategy" I would suggest to > take a look at some verry similar applications like motion compositig > software. very interesting input, indeed! > IMHO "to render" is exactly the word describing whats going on here. true enough. For GIMP, though, graph-based compositing is only a back-end technology. The details should not show up in the UI unless absolutely necessary. (This doesn't rule out that a plugin could offer full tree editing and a corresponding "render" command...) > Toxic is strictly tile based and distributes the rendering of the > composition to all available CPU cores. To further increase speed a > large disc cache computes all the nodes of a composition and stores it > automatically to it's disc cache to create a display preview or render a > composition. this is quite exactly what i understand what GEGL does (i'm not a devel) ... unless you're picky about every node being cached ;) > --> Another great thing with Toxik as also with combustion is a small > "Feedback" checkbox in the UI that ensures that the compositing graph > isn't computed with a given resolution and a given quality but in a > given timeframe of some ms - to get a unblocked response to user changes > - Great Thing by the way!! that's also a very interesting approach for dealing with slow filters: render a small area of the screen in full resolution and fill the rest of the screen with an interpolated low-resolution result. I will post that to the brainstorm so it doesn't get forgotten. greetings, peter _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
