- From: Dirk Schulze <dschulze@adobe.com>
- Date: Wed, 23 May 2012 13:10:27 -0700
- To: Stephen Chenney <schenney@chromium.org>
- CC: "www-svg@w3.org list" <www-svg@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
[I changed the title of the thread and resend it to public-fx since this part is a separate module now] On May 23, 2012, at 11:30 AM, Stephen Chenney wrote: > [Re-sending with correct outgoing email.] > > Dirk, > > I understand the defaults and how filter subregions are defined. My concern is with how the subregions on the filter effects interact with the filter region (that is, the x,y,width,height on the <filter> element), and how these determine the offscreen image sizes. > > As I understand the spec, nothing is ever drawn outside the filter region, so that limits the offscreen size. It all seems very clearly defined, apart from the one confusing sentence I originally pointed out. With your response in mind, and some more careful reading, I think the spec is really trying to say: > > "All intermediate offscreens are defined to not exceed the intersection of ‘x’, ‘y’, ‘width’ and ‘height’ with the filter region, enlarged to include whole pixels that only partly intersect the regions." In general yes. Every intermediate buffer gets clipped by the filter region. So you won't ever have a buffer that needs to be bigger than the filter region. If you access pixels outside this region (e.g for feDisplacementMap) they are defined as transparent black. I am not sure about the last part of your sentence, and I wouldn't got that far to specify it. For instance on WebKit, the content gets scaled first to match the filter region pixel perfect. That means there shouldn't be a pixel that gets intersected by the filter region. This is an implementation detail. Also the size of intermediate buffers should not specified in Filter Effects IMO, that is an implementation detail that can very between user agents. Greetings, Dirk > > Stephen. > > On Wed, May 23, 2012 at 2:06 PM, Dirk Schulze <dschulze@adobe.com> wrote: > Hi Stephen, > > On May 23, 2012, at 7:58 AM, Stephen Chenney wrote: > > > The SVG 1.1 spec section 15.7.3 says this: > > > > -------- > > All intermediate offscreens are defined to not exceed the intersection of ‘x’, ‘y’, ‘width’ and ‘height’ with the filter region. The filter region and any of the ‘x’, ‘y’, ‘width’ and ‘height’ subregions are to be set up such that all offscreens are made big enough to accommodate any pixels which even partly intersect with either the filter region or the x,y,width,height subregions. > > > -------- > > > > The first sentence explicitly defines the offscreen buffer size to be the intersection of the filter region and the filter effect subregions. The second sentence implies to me that the offscreen buffer size must be the union of the filter region and the filter effect subregions. I'm totally confused. > > > > Is this just a case of bad phrasing? In particular, the phrase "are made big enough" could be "are big enough" Is the intention to restrict the valid values of the subregions such that they remain inside the filter region? > > > > Otherwise, what does it mean? > > You can define the attributes 'x', 'y', 'width' and 'height' for every filter effect. If you do that, then these values indicate your clipping region. If one of the values is not defined, the clipping region on the missing dimension depends on the union of previous filter effects. > > For this pseudo example the effect region is the union of the two effects 1 and 2. > > <feOffset result="1"/> > <feOffset result="2"/> > <feComposite in="1" in2="2"/> > > For this pseudo example, the effect is the region defined by the attributes 'x', 'y', 'width' and 'height'. > > <feOffset result="1"/> > <feOffset result="2"/> > <feComposite in="1" in2="2" x="0" y="0" width="1" height="1"/> > > The filter region depends on the union of the input effects for the dimension attributes that are missing. > > > Greetings, > Dirk > > > > > Stephen. > > > > > -- > Stephen Chenney | Software Engineer | schenney@google.com | 404-314-1809 > >
Received on Wednesday, 23 May 2012 20:10:43 UTC