W3C home > Mailing lists > Public > www-svg@w3.org > August 2011

Re: enable-background and filters

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 31 Jul 2011 21:08:19 -0700
Message-ID: <CAGN7qDAvvsUyQS0gBjj27vRMZdjSGdHTSEU=t4=W3YUF1K29Cw@mail.gmail.com>
To: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
Cc: www-svg@w3.org
Hi Jasper,

I agree that the spec is not very clearly written but after I read it a
couple of times, it started to makes sense.

The intent is that after step 2, BUFi contains the partially rendered
content of that context.
For example, take the following SVG snippet:
<g enable-background="new" transform="translate(810,0)">
    <rect x="25" y="25" width="100" height="100" fill="red"/>
    <g opacity=".5" comp-op="darken">
      <circle cx="125" cy="75" r="45" fill="green"/>
      <g opacity=".5" comp-op="darken">
        <circle cx="145" cy="55" r="45" fill="yellow"/>
        <polygon points="160,25 160,125 240,75" fill="blue"
comp-op="darken"/>
      </g>
    </g>
    <rect x="5" y="5" width="260" height="260" fill="none" stroke="blue"/>
</g>

To calculate the background of the polygon:

   - Find the element Ai with the smallest subscript i (including A0=E) for
   which the ‘enable-background’<http://www.w3.org/TR/SVG/filters.html#EnableBackgroundProperty>
property
   has the value new.

<g enable-background="new" transform="translate(810,0)"> *<- A3*
    <rect x="25" y="25" width="100" height="100" fill="red"/>
    <g opacity=".5" comp-op="darken"> *<- A2*
      <circle cx="125" cy="75" r="45" fill="green"/>
      <g opacity=".5" comp-op="darken"> *<- A1*
        <circle cx="145" cy="55" r="45" fill="yellow"/>
        <polygon points="160,25 160,125 240,75" fill="blue"
comp-op="darken"/> *<- A0*
      </g>
    </g>
    <rect x="5" y="5" width="260" height="260" fill="none" stroke="blue"/>
</g>

   - For each Ai (from i=n to 1), initialize BUFi to transparent black.
   Render all children of Ai up to but not including Ai-1 into BUFi. The
   children are painted, then filtered, clipped, masked and composited using
   the various painting, filtering, clipping, masking and object opacity
   settings on the given child. Any filter effects, masking and group opacity
   that might be set on Ai do *not* apply when rendering the children
of Ai into
   BUFi.
   (Note that for the case of A0=E, the graphical contents of E are not
   rendered into BUF1 and thus are not part of the background image
   available to E. Instead, the graphical contents of E are available via the
   SourceGraphic <http://www.w3.org/TR/SVG/filters.html#SourceGraphic> and
   SourceAlpha <http://www.w3.org/TR/SVG/filters.html#SourceAlpha> pseudo
   input images.)

buf3 contains the bits of <rect x="25".../>
buf2 contains the bits of <circle cx="125.../>
buf1 contains the bits of <circle cx="145".../>

   - Then, for each Ai (from i=1 to n-1), composite BUFi into BUFi+1.
   - The accumulated result (i.e., BUFn) represents the background image
   available to E.

> If I understand correctly this means that after step 2, BUFi contains
> essentially A(i-2)...A1, all rendered in the usual way (and NO other
> descendants of Ai, in particular no siblings of any of those elements).

I think that this is incorrect.
Bufi contains the rendered content of previous sibling of Ai-1.
It does not contain any of the content generated by Ai-1...A1. From the
spec:

> Render all children of Ai up to but* not including Ai-1* into BUFi. The
> children are painted, then filtered, clipped, masked and composited
> using the various painting, filtering, clipping, masking and object
> opacity settings on the given child.

>From my example:
Buf3 will contain the content of A3 up to A2.
If <rect x="25".../> had been a group with blending and filtering, it would
be "painted, then filtered, clipped, masked and composited using the various
painting, filtering, clipping, masking and object opacity settings on the
given child."

What do you think?

Rik Cabanier
Adobe Systems, Inc

On Thu, Jul 28, 2011 at 1:30 AM, Jasper van de Gronde <
th.v.d.gronde@hccnet.nl> wrote:

> Resending the question below for lack of reaction. And let me stress
> that this is a real world problem, Inkscape has had several bug reports
> related to using background images, and we'd love to fix them, but to do
> that properly we do need to know what we're supposed to do.
>
> In its description of what enable-background does, the specification says:
>
> 1. Find the element Ai with the smallest subscript i (including A0=E)
> for which the ‘enable-background’ property has the value new.
>
> I assume that this smallest subscript is then considered to be "n", and
> the spec continues:
>
> 2. For each Ai (from i=n to 1), initialize BUFi to transparent black.
> Render all children of Ai up to but not including Ai-1 into BUFi. The
> children are painted, then filtered, clipped, masked and composited
> using the various painting, filtering, clipping, masking and object
> opacity settings on the given child.
>
> Okay, fine, can do. Now it says:
>
> "Any filter effects, masking and group opacity that might be set on Ai
> do not apply when rendering the children of Ai into BUFi."
>
> Then it goes on to say:
>
> 3. Then, for each Ai (from i=1 to n-1), composite BUFi into BUFi+1.
> 4. The accumulated result (i.e., BUFn) represents the background image
> available to E.
>
> If I understand correctly this means that after step 2, BUFi contains
> essentially A(i-2)...A1, all rendered in the usual way (and NO other
> descendants of Ai, in particular no siblings of any of those elements).
> This seems a bit weird, both the i-2 part (it says up to but not
> including A(i-1)) and the part that ONLY ancestors of the "current"
> element (E) are drawn.
>
> However, it gets weirder still. Now that we have those BUFi, we all
> composite them and serve up the sum total as background image. So
> effectively A1 gets composited into the background n-2 times or so, A2
> n-3, etc., An and A(n-1) are simply out of luck, they are in none of the
> BUFi images.
>
> Someone please tell me that this is NOT what the spec intends. (And
> preferably also what the spec DOES intend.)
>
>
Received on Monday, 1 August 2011 04:08:47 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT