On Wed, 29 Aug 2007 02:56:02 -0300, "bulia byak" <buliabyak@...400...> wrote:
As of 15923, it renders the same file in just 26.1 seconds. It's a very noticeable speedup compared to 0.45, thanks! Now please don't lose it in your further refactoring :)
!!! That's a pleasant surprise; I was trying carefully to preserve the same code, only rearranging it so there was less duplication and changes were easier to make without needing to change multiple places in sync.
To be honest, I was expecting a performance hit, since the refactored version is broken into more (potentially non-inlined) function calls, and I actually got rid of one small optimization because I thought it was ugly.
I guess this just goes to show that cleaner code is sometimes faster code.
The one thing this hasn't done is changed the rendering artifacts due to the nearest-neighbor interpolation of the gradient vector. If we were to fix that in the "fast" renderer then we'd probably sacrifice some speed. At the moment, though, rather than making major changes to the current gradient code I'm going to focus my thought on implementing a separate high-quality rendering path for use with PNG export. I suppose we could then make it a preference for interactive use, like blur quality.
-mental