Suggestion to give to new filters a Speed render level rating or mark

Vladimir Golovin wrote in 2006 a list of seven levels of filter rendering speed

Quote

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.

I am suggesting to use this well done list to make a kind of Speed rendering levels marks or rating for new filters that could be submitted, and could be made an algorithm that could detect which components are used inside the filter and then compare them to this list and see to which level that filter should belong and mark it whith one of this 7 levels.

So anyone that wants to know how fast or slow is a filter, could know very quickly without having to try itself in his computer.

Obviously it will not be the same render speed for everyone because it will depend on the computer that each one has, BUT as I suposse this scale and rating that Vladimir have made is based only on components used and not on the power of the computer to be able to render it and make it work.

I think this was actually suggested before.... could be wrong. Of course, as it's been described already, yes the processor speed can really alter the speed of the render. And sure, you can count the number of components which are "ultra fast" and categorically say it's "fast" but there's a huge issue with doing that. First, nobody's computer's the same. Already mentioned. Next note: the way somebody constructs a filter and its user output can alter the speed of the output. So as an author I can add a mode like "preview mode" which bypasses detailing components essentially kicking render times down for a low-resolution output. That alters full render time and plus in some cases, I will construct a separate chain just to output different results. So that contributes to other variables. Which is why I would rather have a "speed limit" than a "speed ranking based on something that can be altered."

So there's another side to this. Let's say I'm producing a filter and I make one that takes 10 minutes to render for a 600x600px image. That's a significant amount of time for a render. So at that point I'd realize I need to take a look at the structure of my filter to assess what's making it go super slow. In most cases, I would be able to go in to the filter and simplify it to the extent where render may take shorter times. Now there are some cases where I can't do that due to aesthetic reasons.

Honestly, in terms of "speed" I think 5 minutes for a 600x600 render is considerably slow already. I generally try to maintain a maximum 2 minute for any filter I submit to the library. But those are just my marks and quality standards for myself. Basically, just as long as you can go in that filter and cut down what can be cut down without hurting the overall look, you should be "ok".

I guess filter authors can mention that it IS a slow filter in the description.

Quote
Skybase wrote: First, nobody's computer's the same.

Absolutely agree, BUT this scale above does NOT depend and is not related to the speed of the computer you are using,so if a filter is considered level 3. SLOW, I doubt much that it will transformed into a 6. FAST ONLY by changing the computer and using a faster one, because it will be updated EQUALLY, I mean if a filter is slow, will be less slow, but continue being slow, and a fast filter will be faster.

Quote
Skybase wrote: the way somebody constructs a filter and its user output can alter the speed of the output. So as an author I can add a mode like "preview mode" which bypasses detailing components essentially kicking render times down for a low-resolution output. That alters full render time and plus in some cases

This is a very good point and this could be really important, as the combination of the components and HOW you do it and how you optimize it and built with good knowledge for best spped could change the results using the same components.

Quote
Skybase wrote: So there's another side to this. Let's say I'm producing a filter and I make one that takes 10 minutes to render for a 600x600px image.

I am sorry BUT this "10 minutes" is based totally on the computer you are using, so this time is relative and not real, and is not a good measure to know if a filter is really very slow, slow, fast or very fast.

If you use EXACTLY SAME filter in a computer from 8 years ago, then in a computer form 4 years ago, and then on the most advanced one available now, will all have the same 10 minutes time ? No, so this is not a god measure to make a scale based on this.

The only way to measure it this way is to have the best and fastest computer you can have and then if in this computer your filter is SLOW, then I go to the following point:

Quote
Skybase wrote: That's a significant amount of time for a render. So at that point I'd realize I need to take a look at the structure of my filter to assess what's making it go super slow.

Then you can realize that as you have the fastest computer and the filter is slow, then you realize that there must be something wrong in the filter, or you must analyze the structure to see if you can make it faster and optimize it in some way.

SpaceRay... you hardcore posting some stuff there. hehe.

I mean... you just said the problem yourself: it's relative. So why bother assessing filters based on that when things are just going to be different anyway? And besides, if the user sees a filter he or she wants to render, why should that user be swayed by a tag that says "this filter is slow." Sure, it helps to understand that filter will take a bit to render, but other than that, that user's just going to render the filter out anyway.

And don't forget, there are some filters that totally stand on their own and are unique in their own domain.

So just saying that.

SpaceRay, you should probable define what is "slow"
If a filter renders in 0.01 seconds and another one renders in 1 second the first one is really 100 times faster – but does it make any sense to the end user?

Quote
GMM wrote: If a filter renders in 0.01 seconds and another one renders in 1 second the first one is really 100 times faster

I am sorry, but you are measuring and defining the "SLOW" with a TIME based scale, and this will NOT work because as already said nobody have the same computer, and so what one filter could render in 3 seconds on a fast computer, it could take 3 minutes in a slow computer.

And also is an error to measure it in HOW MUCH faster is it. You can´t measure well if you say that one filter takes 1 second to render, and another filter takes 100 seconds to make something, and so the first filter is 100 times faster than the first one, which seems to be A HUGE LOT OF TIME but it really is not so much. 100 TIMES FASTER !!! WOW, sorry, but this is not the way.

If I earn 1 $, and then I earn 10 $, would I say that my earnings have increased 1000% ?

Well technically is true, but if you say 1000% seems to be a huge amount, and really is only 9 $ more.

Quote

Morgantao wrote: I think you're missing the point guys... What SpaceRay is trying to say is that YES, slow and fast are RELATIVE, but a filter that gets an ULTRA FAST grade will always be ULTRA FAST relative to a filter that is VERY SLOW on the same computer. If my computer can only do a ULTRA FAST filter in 10 minutes, then it's still going to take LONGER to use a VERY SLOW filter. On the same computer, a fast filter will always be faster than a slow filter. No matter what the computers specs are.

YES, YES, YES !!! Thanks very much for your comment, this is exactly what I know to trying to explain and what the first post with the scale is about, IS NOT ABOUT TIME!

Quote
GMM wrote: I expect that a 50-core CPU would render any library filter in a desktop resolution in a few seconds

ANOTHER reason to remove the speed limit on the filter submition wizard!

Quote
New CPUs hit the market faster than filter authors start constructing more complex filters.

As true as that may be, every now and again we can find on the forum a filter that was rejected due to render time.

THERE IS ALSO A VERY BIG MISSING POINT HERE THAT IS NOT BEING TALKED ABOUT

This missing point is something called RENDER RESOLUTION !!!

The same filter does NOT take the same time to render a 600x600, a 1500x1500 or a 3000x3000 image, and the increases much with resolution.

It could be FAST for this same filter for 600x600 BUT could be probably SLOW for 1500x1500 and much slower in 3000x3000

I have made some time ago this measurements that are in the list below, so you can that what could be fast in 1000x1000 in just more that minute, it will increase to 23 MINUTES by increasing the resolution to 4000x4000.

Quote
Render speed time is in minutes and seconds FF2 1000x1000 1.20 FF2 1200x1200 2.11 FF2 1400x1400 3.03 FF2 1600x1600 4.10 FF2 1800x1800 5:12 FF2 2000x2000 6:08 FF2 3000x3000 13:10 FF2 4000x4000 23:42

Quote
GMM wrote: Your example shows FF scalability works as it should It takes 17.7 times longer to render an image that is 16 times larger than the original.

Yes, I know that it works as it should and is right, I agree with this, and obviously the time is increased according to the size, BUT what I mean with this is that 4000 x 4000 is not a huge resolution and is standard and usual, and if it takes 23 minutes to make a render is a VERY SLOW filter, compared to the 1,20 minutes of the 1000x1000.

I will explain again, for a filter to be FAST it should be rendering a 4000 x 4000 image in about 5 or 4 minutes or less, so a 1000 x 1000 should be 16 times lower than that.