Comment 11 for bug 733966

Actually, the first and far most important step is to identify exactly what is "slow".

Usually we are talking about "unresponsive UI" issues. There are many ways to address these, but we need to know where to look. We also need to know in detail, not just "the app is slow".

For example, some users reported that changing colors via the sliders in the Fill & Stroke dialog was slow. I was able to measure some things and got it working much "faster" by actually slowing down that portion. What I did was clean up the UI integration to no longer generate hundreds of repaints per second (far faster than a normal user could even see). Instead events were pruned down and some updates deferred. Objectively the result was actually slower updating in response to user input on the color sliders. Subjectively, however, the operation of the program in that area suddenly felt much faster.

Switching to a Cairo renderer may allow some pixel-pushing speedups. However we will gain a lot more by addressing specific user interface responsiveness issues. Instead of trying to redraw thousands of vectors hundreds of times a second, we can instead switch to dragging proxy bitmaps and gain significant responsiveness speedups (even when combined with Cairo rendering). There are many other such UI tunings we can do... but we need to know which areas and aspects of the UI to focus on.