[p0nce]

I had written another long reply but I felt like it added nothing to the discussion and removed it.

I'd like to adress only the technical issue of CPU usage, in which you are a bit right and perhaps we could agree. Software rendering need to be fast too as you guessed.

The optimizations performed is that only subparts of touched elements are redrawn in intermediate buffers (widgets receive the order to redraw in subrects of their positions), mipmapping (SSE2) is used to help with glow and shadows, tiling and multithreading are used, and the output of PBR is cached. For realtime feedback like spectrograms, the system has a bypass channel in which case the lighting calculation is just a copy. This is what is used for realtime feedback at 60fps, no PBR is computed then. That still leaves big PBR widgets which can be invalidated at once.

It's still not at the level of quickness I wan't it to be (Issue #127), you may have the problem that while turning a big knob - in which caching doesn't help - Crackles may occur. I'm pretty confident it can be solved completely when #127 is fixed and lighting is more SIMD and less shader-like.

So it's an ongoing process of making this rendering faster, however the rewards in my opinion are numerous (and there we get in debatable material so I won't disgress).