W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2012

Re: canvas in SVG (was: Re: SVG 2 Requirements: next phase)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 23 Feb 2012 08:54:38 -0800
Message-ID: <CAAWBYDDxNxQaeCtUfrA5=iEwm78werXga7J6ESgJ114T75-MdQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC