Rendering Speed Classification on Filter Details page?

Overall that's not a bad idea. Some people won't care, and others will. The only real downside would be it could deter people from even downloading the filter in the first place, ie = not wanting to waste a lot of time on a slow rendering filter ya know.

jffe

Yes, we considered that. The benefits are obvious, but the task isn't as simple as it sounds. For example, the time measurement must be taken multiple times to compensate for possible interventions from the OS (like disk swapping). Also, we would need a separate server for this, because measuring rendering time on a server busy with Filter Library requests is not a good idea.

For me, an important question is: When is a filter fast enough? What is a good ratio between visual complexity and rendering performance? This is especially interesting for textures, since these tend to be more visually complex than effects.

Looking at the visually complex, high-detail textures on the library, some would certainly be categorized as slow performers. However, their visual appeal might make render-time considerations largely irrelevant. You might just need a few of these rendered out, so you don't care: you're going all out high-detail. Where do you draw the line? And what do we desire for the filter library?

It's really a dilemma. On my last filter I tested both a low and high global detail version. Just removing a highpass brought down rendertimes a minute on the low and 2.5 minutes on the high detail one. Visually, however, removing the highpass turned out to be .

Since its about visuals, I certainly would submit the slow version, not the one that's been gutted for performance.

I put a switch on one or two of mine, for low/high quality, so people could get a preview faster and get an idea of what it looked like, (basically just on/off remapped for roughness/details set from zero, to normal, on a couple of noise modules). That might be something for you to do also Crapa.

jffe

Quote
Vladimir Golovin wrote: For example, a filter can be considered fast if its rendering time is lower than the average rendering time across all filters in the Library.

And can you enlighten us as to what this average rendering time currently is?

No, I'd say "We want slow filters only if they do something really useful or cool-looking. We don't want filters that take hours to produce obvious things that can be easily made in Photoshop."