sRGB⇔linear sRGB conversion performance improvements
The phone time is cut in half again!
- Converted the
srgb::functions to use look-up tables instead of costly floating point operations + pow. Due to having to round unpremultiplied pixel values to use the lookup table, this very slightly changed the results of some filter tests.
- This dropped the phone from 16 seconds to 11 seconds.
- This dropped
rsvg-bench -p 1 -r 100 tests/fixtures/reftests/svg1.1/filters-*.svgfrom 51 seconds to 38 seconds.
SharedImageSurfacewith a more general
SurfaceTypewhich indicates if the surface is sRGB, linear sRGB or alpha-only. I then changed the filter code to only convert between the color spaces when necessary. This is very important because in the common case a bunch of filter primitives will have the same
color-interpolation-filters, and there's no need to convert to linear sRGB, then to sRGB and then back to linear sRGB between every two primitives.
- This dropped the phone from 11 seconds to 8 seconds.
- Didn't really affect
filters-*.svg, probably because when there are filter chains they operate on tiny surfaces.
- Switched from
nalgebrafor matrix and vector operations.
nalgebrais much more widely used (165k vs. 10k), is actively maintained and most importantly has both dynamic and static stack-based types. This allowed me to get rid of the allocations in the lighting code.
- Phone: 8 seconds -> 7.6 seconds.
- Didn't affect
This time I used callgrind + KCachegrind for visualization (my first time using callgrind). KCachegrind provides a very good overview of things and includes a number of different ways of visualizing them, including a call graph, a callee map and a source code view with performance marks. It also seems to provide better call graph info than perf + flamegraph.
Either way, here's the latest flamegraph: