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

RE: SVG 2 rendering model

From: Rik Cabanier <cabanier@adobe.com>
Date: Fri, 3 Aug 2012 09:59:13 -0700
To: Leonard Rosenthol <lrosenth@adobe.com>, Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <83F37C1A4497B54589EAEDC750D03A9473B7E69C@nambx09.corp.adobe.com>
How would you implement group opacity on a non-isolated group without a buffer?

I agree that if you have a non-isolated group with default parameters, you could optimize it away since it's not supposed to do anything.

Rik

> -----Original Message-----
> From: Leonard Rosenthol
> Sent: Friday, August 03, 2012 5:48 AM
> To: Rik Cabanier; Nikos Andronikos; public-svg-wg@w3.org
> Subject: RE: SVG 2 rendering model
> 
> Based on the text you copied, there is actually NOTHING in the spec that
> requires a specific implementation in the case of a non-isolated group.  It
> simply requires that certain things have to take place in a certain order.  I
> agree with that.
> 
> Consider the "buffer" in this case to be the full page output and non-isolated
> groups can be composited directly into that buffer.  It represents both the
> group backdrop as well as the immediate backdrop, since if you only draw to
> it, it is " the result of compositing all elements up to but not including the first
> element in the group".  Right?
> 
> The size of the group only matter for isolated (or potentially knockout)
> groups, since in those cases, you have no choice but to use a separate
> "buffer".
> 
> Leonard
> 
> -----Original Message-----
> From: Rik Cabanier
> Sent: Thursday, August 02, 2012 11:21 PM
> To: Leonard Rosenthol; Nikos Andronikos; public-svg-wg@w3.org
> Subject: RE: SVG 2 rendering model
> 
> No, a buffer is always required.
> From the pdf spec:
> 
> From the perspective of a particular element in a nested group, there are
> three different backdrops of interest:
> *The group backdrop is the result of compositing all elements up to but not
> including the first element in the group. (This definition is altered if the
> parent group is a knockout group; see 11.4.6, "Knockout Groups") *The initial
> backdrop is a backdrop that is selected for compositing the group's first
> element. This is either the same as the group backdrop (for a non-isolated
> group) or a fully transparent backdrop (for an isolated group).
> *The immediate backdrop is the result of compositing all elements in the
> group up to but not including the current element.
> When all elements in a group have been composited, the result shall be
> treated as if the group were a single object, which shall then be composited
> with the group backdrop
> 
> So, according to the PDF spec, the buffer is initialized with the backdrop of
> the group which is the " the result of compositing all elements up to but not
> including the first element in the group "
> In the case of HTML and Flash, the size of this buffer is calculated
> automatically. In PDF, it is given as the bbox parameter in the transparency
> group. From the PDF spec:
> 
> If the transparency group is non-isolated (the value of the I entry in its group
> attributes dictionary is false), its initial backdrop, within the bounding box
> specified by the XObject's BBox entry, shall be defined to be the accumulated
> colour and alpha of the parent group or page-that is, the result of
> everything that has been painted in the parent up to that point.
> 
> Also, if there is no buffer, how could you implement group opacity?
> 
> > -----Original Message-----
> > From: Leonard Rosenthol
> > Sent: Thursday, August 02, 2012 5:54 PM
> > To: Rik Cabanier; Nikos Andronikos; public-svg-wg@w3.org
> > Subject: RE: SVG 2 rendering model
> >
> > In the case of a non-isolated transparency group, no buffer is required.
> And
> > in fact, it may actually be WRONG to use one, since you may well be
> > blending the wrong colors in the wrong order depending on what's in the
> group.
> >
> > Leonard
> >
> > -----Original Message-----
> > From: Rik Cabanier
> > Sent: Thursday, August 02, 2012 4:25 PM
> > To: Leonard Rosenthol; Nikos Andronikos; public-svg-wg@w3.org
> > Subject: RE: SVG 2 rendering model
> >
> > An implementor always has to do this anyway.
> > The only difference is if the bitmap is filled with transparent black
> > (= isolated) or the backdrop (=non-isolated)
> >
> > In PDF, this information comes from the bbox in the transparency group.
> > Regardless of isolation, the buffer is created. (See 11.4.3 in the PDF
> > spec)
> >
> > Rik
> >
> > > -----Original Message-----
> > > From: Leonard Rosenthol
> > > Sent: Thursday, August 02, 2012 1:09 PM
> > > To: Rik Cabanier; Nikos Andronikos; public-svg-wg@w3.org
> > > Subject: Re: SVG 2 rendering model
> > >
> > > On 8/2/12 3:34 PM, "Rik Cabanier" <cabanier@adobe.com> wrote:
> > >
> > > >Hi Leonard,
> > > >
> > > >> The problem with making isolated the default is that it will
> > > >> impact performance for all of the normal cases.
> > > >Isolated is faster since you don't have to composite all the group
> > > >to get the background.
> > >
> > > But you DO have to create an "offscreen buffer", composite the entire
> > > group into that, and then blit the entire "offscreen" back.   So you're
> > > clearly using more memory and time than simply putting bits into the
> > > existing buffer.
> > >
> > >
> > > >The compositing spec specifies the order in which filters and
> > > >compositing happens.
> > > >The filters spec should say if the stacking group it creates is
> > > >isolated or not. I believe people don't want it to be isolated (and
> > > >can post some examples if needed)
> > >
> > > But how would you apply a filter to a group that has already been
> > > blended into the background?  The result is certainly going to be
> > > different - which may be good or bad.
> > >
> > > I would think that given a group with a filter applied to it, you
> > > have to make that specific group isolated, apply the filter, and
> > > only then blend it to the background.
> > >
> > > Leonard
Received on Friday, 3 August 2012 16:59:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 3 August 2012 16:59:42 GMT