Filter optimization function

that's an interesting idea, components would be different colors based on how fast that individual component processed its work. i'd go with red, yellow, green, though and not orange. that seems to be a standard in the u.s., at least, for stop, slow down, go.

+1.

Quote
CorvusCroax wrote: of how much render time the overall filter takes to render would be very useful,

you can already set that in options. with each render a popup will show up showing you the overall length of render.

I like the idea. OK, sometimes by following the updating of "mini-renders" i each component you can follow the flow, but I think at least having some kind of "bottleneck warning". I figured out the hard way (hung FF2 beta in a totally inresponsive way) but feeding bomber results into particles, into particles....

Quote
CorvusCroax wrote: It would even be helpful to have a top level metric: some absolute measure (that is, not dependent on your machine) of how much render time the overall filter takes to render would be very useful, just for comparison.

Quote
CorvusCroax wrote: But that's dependent on your machine. It's not an absolute metric. All those measurements are relative to our respective hardware setups, and for that matter, also the size of the render.

how can a measure of render time not be dependent on your machine? and, it does measure the overall time it takes to render; that's what i was saying. and a second is about as absolute as you're going to get.

the size of the render is 600 x 600, at least for benchmark purposes. just use the default pic, the life preserver. that's what filter forge, inc. is using when they test your submitted filters for speed.

i'm guessing what you want is a benchmark test, something that is fixed, rather than all our different machine specs, but it's not quite what i'm hearing you say
there is a little bit of a benchmark set by FF, inc. the pic, like i said is the life preserver, the processor is a 1 gigahertz, single core and the max render time allowed for one to have their filter accepted is 15 minutes, if i'm remembering all this correctly.

but, what i was saying was that you dont need really tight benchmarks, plus it would be very difficult to do since you couldnt just do it on a local machine. you'd have to have a fixed machine to compare your results to, which would mean FF, inc. would have to test each filter and then spit out their results on the web site somehow. it just doesnt sound very practical or all that useful.

what does sort of work is, comparisons of render time amongst us all here on the forums. it's not tremendously precise as far as setting a true benchmark, but it can give you an idea of how your machine is doing relative to others. if i send carl a filter and he can render it as speed X in a 600 x 600 pic and i render that same pic on my machine at Y amount of time, then that's about all you can do, i would think.

now, bear in mind that i also may well end up being called 'jane, you ignorant slut.' on all this. perhaps i'm not truly getting what you're saying. so, elaborate if necessary

Is amazing that community can be design and optimizate a small idea.
The green-red scale is good to me.
Also the machine independent comparative time rendering.

What says the Filter Forge Team?

Render values for components would have to be based on the sliders. A blur w/radius of 1 is faster than a blur w/radius of 100. A bomber gets a lot slower when you crank up the density slider. FF would have to compute render values at the same time an image is rendering, not just have a set value per component, and that might negatively affect the render time.

It could be possible to estimate general render times per component and color them like that, but it might not be that accurate.

i'll make one little suggestion here on how you might want to track bottlenecks in your filter... ok, two suggestions. first, if it ever gets implemented, we could use the compressed components system and time each 'leg' of a filter, rather than each component. the compressed components system is where you have x number of components in a given routine and they become a sort of macro-component compressed down into one faux component (it's still really all those components, but can be displayed with just one placeholder). those routines can be saved as a single component, more or less, and you could then time that package/routine by itself.

and two, you could just read the helps and wiki and forum(s) to see which components are typically slow and which are fast

I think it would be a great idea to have a scale or mark to know wich filter is CPU hungry and need lots of computing power to work and wich one are not so power hungry.

I have seen that there is a great difference in speed between filters and render time, some are fast and other take very long.

Of course this also depends on the computer you have, because if you have a monster super computer, most of the filters would go fast and smooth, but if you a computer that is 4 or 5 years old, it would be much slower, so it would be good to know which ones are power hungry nad which are in the middle and which are not.

Spaceray, doesn't this thread meet the request for a benchmark?