Optimizing Filters for Speed

Quote
uberzev wrote: Anybody know which are the "heaviest" components?

1. SLOWEST: Image-based components (Blur, Motion Blur, Sharpen and High Pass) with any slow component (like Worley-based noise) as a source.

2. SLOW: Worley-based noises (any Noise except Perlin, which is very fast).

3. SLOW: Image-based components (see above) in general, because they need to prepare a source bitmap before rendering themselves.

4. CAN BE SLOW: Refraction, especially with a slow component as a source. Refraction takes 3 samples of the source input.

5. CAN BE SLOW: Any Noise (or any component based on Noise such as Noise Gradient, Noise Distortion or Noise Curve) with high Detail and Roughness (they are interdependent) especially with a custom curve as a profile.

6. CAN BE SLOW: Any Noise with a custom curve as a profile -- the curve is sampled once for each noise octave (for Details = 10 you have 10 samples of the curve per one noise sample).

5. CAN BE SLOW IN CERTAIN CASES: Any component that generates edges for anti-aliasing (Patterns, Worley noises, some of the adjustments). But since anti-aliasing is done in a separate pass, that shouldn't impact speed too much.

6. FAST: Patterns, Channels, Adjustments, Gradients (except for Noise gradient).

7. ULTRA-FAST: Externals (Image and Selection), Checker, Switch, Blend, Offset.

Quote
Vladimir Golovin wrote: 7. ULTRA-FAST: Externals (Image and Selection), Checker, Switch, Blend, Offset.

Sometimes a filter may use the External Image as an input to many different components. Often the connections can cross the whole filter from start to end.

In this "ULTRA-FAST" case, can I interpret that we can sprinkle duplicates of the External Image throughout the filter without suffering any (or too much) delay. i.e. increased legibility, without sacrificing speed.

If so, is the same true of the other components quoted?

Rô

Quote
Vladimir Golovin wrote: If so, is the same true of the other components quoted?

External > Selection.

As for other components, I would not recommend duplicating them. The renderer has an optimization called "sample cache" that can save you a significant amount of rendering time in situations when a single component has multiple outbound connections -- you won't get the speedup when using duplicates instead of connections.

Maybe these optimization tips should also go into the help wiki (I couldn't find them in the wiki anywhere). And how about a rendering knowledge-base with its own sub-section?

Great info!!! Thanx Vladimir

A sample is a single evaluation of the image function (built by the filter tree) at given coordinates. To determine the surface normal vector, we need to know the surface heights of at least two more points near the location of the central sample. Hence, three samples.

Some info can be found here:
http://www.filterforge.com/more/help/...nents.html

Quote
David Scheffert wrote: How long is too long, when it comes to rendering, for a filter to be accepted in the library?

We usually don't reject filters based on their rendering time, except for filters with absurdly long rendering time which blocks our rendering queue. You can look at the filters included with Filter Forge to get the idea of acceptable rendering time.

does extracting channels improve performance aswell? let's say you have a b/w noise and extract the lightness-channel and continue to perform whatever it is with that channel only - will this improve performance compared to using just the noiseoutput or is this approach useless because an empty hue and saturation channel dont cost performance anyway?

cheers

Vlad is there a speed list for the new components, or can you update your first post - I seem to have taken a backward step with speed of V2 filters

Thanks, that's a help, the Median/Minimum/Maximum is my problem I think then

Quote
smoocherz wrote: a new category based on speed or simply add a rating to each filter with a 1 - 10 scale

That is an excellent idea!

I have a few comments/ideas for that.

First of all, since rendering now takes place clientside, we have many different systems, so the rating should be normalized somehow.

For that I suggest either a benchmark of the system that can be used as normalization factor, or a test rendering of a specific default filter that is used to measure the performance on a given system. This could be done the first time FF is installed or when the first filter is submitted.

When a filter is submitted and the preset rendering starts, an average tile rendering time is calculated. This average time is normalized with system bench value from earlier.

This should ensure a consistent measurement

Very interesting inujima. thanks

Quote
Inujima wrote: Method of Increasing a speed of filters seems so complicated more than I had thought.

I know another way that it could help to increase the speed of filters, and this is that the FF developers team can make a new better and more optimized render engine for FF 4.0 and so all is supossed that would be faster. HINT HINT Do you listen FF Inc.?

Looks like the sample cache mechanism is broken - I bet thats what the new 3.007 release is about.

Btw here is an informative discussion on the sample cache stuff..

Quote
Sphinx wrote: I bet thats what the new 3.007 release is about.

Regretably this has NOT been included in the 3.007 update, so we will have to wait until another update.

Yep, there's no magic number on how long is too long. It totaly depends on the user and how much he wants the result a filter gives.

I'd say smudge is like "medium speed" it can run pretty darn fast at the same time pretty darn slow depending on the way you deal with it.

The list here is from FF1.0 you won't see many of the newer components present.

For example if you enable Anti-Alias it'll run slow as you'd expect. Disabling orthogonal and having density at 100 will make it sluggish. Pretty sure there are a couple more, but those settings alone are a mild hinderance to render speed. So I guess it's "can be slow".

I made a test to see which line creation method is the fastest: Line draw benchmark

I'd be interested to see if anyone can improve them.

GalaxyMeridian,

I've checked the Techno Shapes filter earlier, you certainly have made an effort with the script. Thanks for reminding about the pre-rendering method.

One possible thing for me to test is to pre-render one horizontal "slice" of a vertical gradient, then rotate and shift it to correct position. I don't have high hopes about it, but it could be worth a try.