As I mention in my top level post, this is false. The most obvious example is that you do all your rendering and updates in graph traversal order, even though this is one of the worst traversal orders to use because it minimizes the effectiveness of the processor's caches and produces the maximum number of GPU state changes. GPU state changes increase both CPU and GPU overhead, and in a software rasterizer they also prohibit efficient caching (for example, in Cairo).

You can say it's efficient as much as you like, but you clearly haven't done much research if you think it's fast just because the CPU usage is low in your trivial demos - demos that cause GC pauses on a regular basis, I should note. If you want to claim that it's fast and GPU/CPU friendly, you should be profiling it in a GPU profiler like PIX to ensure that it produces few GPU draw calls and state changes, and profiling it in a CPU profiler to ensure that virtually all the time spent is spent inside of the Canvas implementation - which, sadly, is not true for your example game 'O!' in the Chrome Profiler.