If I remember correctly the previous version used assembler MMX/SSE code to perform graphic operation, and it was fast.
The new code does everything in C++, so it rely on the compiler optimization. This is an issue on debug build, all graphic operations (like bitblt images) take forever.
IIRC, you used to put some pragma magic in the previous version to optimize the code even in debug build, but I can’t find them anymore.
What about adding a #define JUCE_GRAPHIC_OPT 1 in juce config, for us, juce user, that would enable such optimization back, even in debug build ?
I think we don’t need to step into graphic code in our development anyway, so it’s worth it.
I took the magic pragmas out because I don’t think there was a way to push/pop the pragma state, so the optimisation affected not just the bit that was intended, but all the code that followed it too (in an amalgamated build)…
And I would have kept the mmx stuff if the new code had anywhere for it to go, but with the way the new clipping architecture worked, it didn’t fit in properly. At some point I’m probably going to do some extra optimisations for simple rectangular regions, and then there might be a place for it to come back.
Since the single-file amalgamation cause trouble for compilers, I’ve seen you’re now using multiple file amalgamation.
What about organizing a12n so that one file contains all the “juce internal”, like strings and draw code, and let only this one get optimized (while the other file wouldn’t be) ?
I guess this would mean fiddling with the template file for the a11r, but you’re doing this already.
Just having a quick look at MSDN, it does actually seem possible to just turn those optimisations off again… I’ve checked something in that should do it now.
