> If this is strictly a performance issue, then we definitely should fix that before adding new API, IMHO. It would be great to get some reduced test cases where save()/restore() is a bottleneck.
I'd argue its not strictly a performance issue. More generally its awkward that you can reset any piece of the canvas context state except the clipping region. The clipping region alone requires you to clobber all state in order to reset it. You can set the fillStyle back to black, you can set the transformation matrix back to identity, etc. But you can't set the clipping region back to the entire canvas area without save()/restore() or can.width=can.width. It's the only thing like that. That ought to be considered bad on principle I think. It makes clipping a really odd operation compared to anything else, and at the least it makes the one part of the API unintuitive.
