Ever since the first Filter Forge release 10 years ago we have been reprimanded for slow rendering. Unfortunately our renderer architecture is not very suitable for speed improvements – this is a downside of storing filters in an open XML format that allows every user to look at the internals of a filter and quickly modify it for their purpose. Well, things have improved a bit.
In Filter Forge 7 we overhauled the renderer, particularly the logic of sampling and sample caches. Our original sample cache architecture didn’t take into account cases where a single component was used in multiple filter subtrees: every time the sample function of a component was called from a different subtree, the cache was invalidated. Filter Forge 7 takes a different approach: all samples are preserved in separate bins, which eliminates the need to re-calculate the sample which has been already requested before.
The obvious benefit of the new sample cache architecture is increased rendering speed for most filters. In quite a few lucky cases the improvement is in double digits. Here are our benchmark results:
| 3000x3000 px | 6.0 | 7.0 | Improvement |
 Crosshatch Drawing |
59 s | 34 s | 42,4% |
 Old Cobblestone |
1383 s | 673 s | 51,3% |
 Watercolor Painting |
298 s | 162 s | 45,6% |
 Toycam-82 |
166 s | 136 s | 18,1% |
 Derelict |
1326 s | 750 s | 43,4% |
 Ornamented Ball |
2558 s | 1856 s | 27,4% |
 Whisp |
3701 s | 1944 s | 47,5% |
 Technical Drawing |
54 s | 34 s | 37% |
– Wait, my favorite filter doesn’t show any improvement!
This means your filter was already optimized. Our new algorithm can only speed things up if a filter uses sample cache ineffectively. You can console yourself by thinking that the filter author maxed out filter performance long before we implemented it in Filter Forge.
