noise generators (forked from: Krita user community?)

[Boudewijn Rempt]

On Monday 25 February 2008, Matthew Woehlke wrote:
> Of course, another question might be if we care about partial updates?

If you want your filter to be enabled for filter nodes (i.e, non-destructive 
updates) then yes, unless it's blindingly fast. Of course, this generates 
data, so making it into a dynamic node type of thing is less important.

> If not, a (much) simpler way would be to parallelize only the guts of
> each sub-pass and lockstep all threads between passes. This would allow
> one thread per pixel (except many would have nothing to do the first
> pass), since the data is write-on

We are considering putting in convergence phases for filters that absolutely 
need all input information in a particular node to done, ready and available 
for the filter; those filters cannot be threaded and will cause a point of 
serialization in the projection update code. I.e, they will slow down things.

The way krita works now has a big advantage: the image is tiled in fairly big 
tiles and every tile is given to a thread. A thread gets to work out its tile 
before releasing control and giving another thread a chance. That means that 
the projection data doesn't get bumped out of the cache all the time, as it 
would if you were to update the whole image whole layer by whole layer. And 
it makes it possible to display the tiles that are ready already, giving the 
user the impression of responsiveness. And it makes it possible to defer the 
procession of out-of-view tiles to idle periods, making krita do the least 
possible amount of work.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi