A major rework (really rewrite except for the graphics bits) of the <canvas> support, to fix the fundamental problems the previous implementation had. Essentially, it used to store all the bits in the renderer, and have the painting state split between an ephemeral painter (which went away on every repaint), and the JS context object. The way it's spec'd in HTML5 is that the canvas element/its context manage the canvas area and the painting state, and the renderer merely scales. So, I did the following:

1) The context, gradients, patterns, are all proper DOM objects, giving the information the expected lifetime.

2) The DOM context object keeps track of all the painting state itself, updating the painter as needed, and provides the canvas APIs

3) khtmlImLoad gets a new CanvasImage class, that provides a way of using its scaling cache features for this sort of thing. It's not a great fit (it's really meant for something more static), but it's reasonable

4) The JS part is now just a standard wrapper object, with some extra parameter checking, and a bit of code to split the type-unsafe things nicely.

Should we perhaps provide this as part of our C++ DOM in 4.1 or a later 4.0.x release?

5) In general, this was brought in line with HTML5 as best as I could, not being a graphics guy. At least the type checking should be close... assuming I understood it right

There are still gaps/missing features and bugs, of course, but this should serve as a solid foundation.

Various portions were reviewed by Allan, Germain, Harri and Fredrik, hopefully totally covering everything.

(Oh, and I need to figure out how to testcase this properly; I've been using a bunch of web-available testsuites, but we need something for khtmltests)