- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 23 Feb 2012 08:54:38 -0800
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, Alex Danilo <adanilo@google.com>, Vincent Hardy <vhardy@adobe.com>, Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>, "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>
On Mon, Feb 20, 2012 at 8:16 AM, Dirk Schulze <dschulze@adobe.com> wrote: > On Feb 20, 2012, at 7:21 AM, Leonard Rosenthol wrote: >> Making it a paint server, while a “cool idea”, seems like it’s asking for >> trouble in terms of correct, consistent and acceptably performing behavior. >> >> Consider a Canvas that is part of a Pattern or <use> - you will need to >> update each of them upon any change to the canvas. Is it an immediate >> operation? Can you “stop” and then “start” drawing operations to group them >> together to avoid redraw overheads? > > Don't we have to deal with it anyway nowadays? Every content element of a > pattern can get animated and requires an update immediately. > > But patterns are a good example. We don't need to specify a paint server in > order to support filling or stroking an element with a canvas by just adding > the canvas to a pattern. Therefore it doesn't matter if canvas gets a paint > server or not. Yup, there's no new issue here. You always have to track dirty rects, and <pattern> and <use> already let a single dirty rect spam into multiple across the document. You handle them as well as you can - this is pretty much completely a quality-of-implementation issue. Note as well that CSS now effectively defines <img>, <video>, and <canvas> to all be paint servers. (It uses the term "paint source", as I think that's somewhat clearer, but it means the same thing.) ~TJ
Received on Thursday, 23 February 2012 16:55:31 UTC