- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 01 Jul 2011 11:15:25 -0700
- To: Edward O'Connor <eoconnor@apple.com>
- CC: public-canvas-api@w3.org
On 7/1/2011 10:52 AM, Edward O'Connor wrote: > Hi, > > Doug wrote: > >> I agree with others on this list that a retained-mode Canvas API is a >> bit of a contradiction, and that SVG is better suited (designed, in >> fact) for retained-mode graphics. > Indeed. Retained-mode shadow dom. We've discussed a "path" object; which is something that most 2d apis with similar semantics to canvas have and operate with. Given that canvas is not a -new- invention, but simply a borrowing, it's not so absurd to borrow the other part that so many 2d implementations have found useful. >> I suggest that rather than adding more retained-mode shape features to >> the Canvas API or shadow tree, that we simply allow the SVG and Canvas >> to be used more seamlessly together[…] I wrote up some more detailed >> notes on my blog, and I'm interested in hearing feedback[…] > While painting, the render tree needs to be immutable. There are some > unfortunate legacy cases where this doesn't hold (plugins, mainly), but > we'd be really reluctant to allow new cases in which the render tree can > change out from under us while painting. Which means that scribbling on > an SVG element with the 2d context API while painting is a non-starter. > > > Ted > Ted, are you sure your repaints can not be "held" until the end of the event loop? By and large, such screen updates can -wait- until the end of the event loop; where the UA has complete control over the situation again. I realize that WebKit2 will have multiple processes, and that graphics may be painted off-thread; SVG can still be updated as it normally would when the scripting environment signals a change in fill/stroke attributes. Again, here's Canvas as a background fill: http://www.webkit.org/blog/176/css-canvas-drawing/ -Charles
Received on Friday, 1 July 2011 18:16:20 UTC