noise generators (forked from: Krita user community?)
boud at valdyas.org
Mon Feb 25 18:54:05 CET 2008
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.
More information about the kimageshop