Not all effects needs access to all of the buffer. A lot of them only need access to a neighbourhood around each pixels, for which a system of slightly overlapping tiles fits the problem.
Martin --- On Fri, 1/21/11, Aurel W. <[email protected]> wrote: > From: Aurel W. <[email protected]> > Subject: Re: [Bf-committers] Proposal: Blender OpenCL compositor > To: "bf-blender developers" <[email protected]> > Received: Friday, January 21, 2011, 3:31 AM > Another question, I am concerned > with. > > What do you mean with "tiles" in the context of the > compositor. That a > node just processes patches/tiles of an image, so the basic > entity, > which is processed becomes a tile or even a single pixel? > > I hope it's commonly realized that a compositing node > always has to > process an entire image globally and output an entire > image. The > processing of each pixel depends on every other pixel in > the entire > image not just in tiles or on the very one input pixel. > It's really > that simple, a node can be expressed by a function > f(image)->image and > not f(tile)->tile or f(pixel)->pixel. > > Please remember this when doing any design of the new > system, > otherwise things will be heavily screwed up. > > aurel > > On 21 January 2011 08:37, Jeroen Bakker <[email protected]> > wrote: > > On 01/21/2011 12:10 AM, Matt Ebb wrote: > >> I say this not to be negative, but because there > is a lot of room for > >> functional improvement in blender's compositor, > and if it is to be > >> re-coded, it should be done with an eye to > workflow and future > >> abilities, not just from a purely techno-centric > perspective. > > I don't see it as negative. Also I don't think that I > am (cap)able to > > implement all these functional wishes/changes. They > need to be thinked > > about by users/developers together. I also don't think > it is good to do > > all this work we discussed in a single project. There > will be a > > separation of technology and functionality. First > should concentrate in > > implementing a kernel (stable ground), that is capable > of our 'future' > > wishes/changes/capabilities. And secondly we need to > implement the more > > functional/workflow part. > > > > The first part needs to know the directions of the > second part (vision). > > This vision should be clear upfront, but not in > details. > > > > Jeroen > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
