This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1499 [details] Reftest Currently, the spec says: "The bounds of this rectangle [the filter region] act as a hard clipping region for each filter primitive included with a given filter element; thus, if the effect of a given filter primitive would extend beyond the bounds of the rectangle (this sometimes happens when using a feGaussianBlur filter primitive with a very large stdDeviation), parts of the effect will get clipped." [1] I interpret this as the output of a filter is clipped to its filter region, and nothing is said about clipping the input. Currently, all UAs I've tested (Chrome, Firefox, IE, Safari) clip the input SourceGraphic to the filter region (as I would expect). I think we should add that to the spec. I wrote a reftest and attached it. [1]: http://dev.w3.org/fxtf/filters/#FilterRegionXYWidthHeightAttributes
Created attachment 1500 [details] Reftest reference file
Maybe I spoke too soon- Safari is rendering white on my reftest. I expected a green rect. (The other UAs draw a green rect.) This might be a different bug though. If I recall correctly, Safari clips input using the filter region.
Section "Filter primitive subregion" says "The filter primitive subregion act as a hard clip clipping rectangle on both the filter primitive’s input image(s) and the filter primitive result.". Since every primitive has a primitive subregion, isn't that the same as saying the input is clipped to the filter region? Especially with the comment in the next paragraph: "All intermediate offscreens are defined to not exceed the intersection of the filter primitive subregion with the filter region." Do you disagree? http://dev.w3.org/fxtf/filters/#FilterPrimitiveSubRegion
(In reply to Dirk Schulze from comment #3) > Do you disagree? I agree. If the filter primitive subregion clips input and intermediate offscreens cannot exceed the filter region, I believe that's the same as saying the filter region clips the input. IIRC, no browsers actually use the filter primitive subregion to clip a previous filter primitive's input. They only use it to clip a filter primitive's output. However, I believe all browsers use the filter region to clip input. (I will attach a better test case shortly.) To match all the implementations, I'd change the spec to say filter primitive subregions clip their primitive's output, and filter regions clip the input SourceGraphic (or other input). I don't see any harm in primitive subregions not clipping input. You can achieve the same result by inserting an extra no-op primitive of some kind with a primitive subregion if you really want to clip both input and output. This is probably a separate bug, though. The current spec language does work for filter regions clipping input via filter primitive subregion input clipping.
Created attachment 1532 [details] Reftest: All browsers clip the input SourceGraphic to the filter region. This is a simpler example that works in Safari, IE11, Firefox, and Chrome. The previous example was running into some other seemingly unrelated issue in Safari.
(In reply to Max Vujovic from comment #4) > (In reply to Dirk Schulze from comment #3) > > Do you disagree? > > I agree. If the filter primitive subregion clips input and intermediate > offscreens cannot exceed the filter region, I believe that's the same as > saying the filter region clips the input. > > IIRC, no browsers actually use the filter primitive subregion to clip a > previous filter primitive's input. They only use it to clip a filter > primitive's output. > > However, I believe all browsers use the filter region to clip input. (I will > attach a better test case shortly.) > > To match all the implementations, I'd change the spec to say filter > primitive subregions clip their primitive's output, and filter regions clip > the input SourceGraphic (or other input). > > I don't see any harm in primitive subregions not clipping input. You can > achieve the same result by inserting an extra no-op primitive of some kind > with a primitive subregion if you really want to clip both input and output. > > This is probably a separate bug, though. The current spec language does work > for filter regions clipping input via filter primitive subregion input > clipping. I found it hard to observe. In my tests not even browsers are that consistent. IE sometimes clips the input as well. But it doesn't do it all the time. I brought this up to the WG twice. The second time with the intention to undo the input clipping. In both cases the WG (and the UA reps with them) wanted to keep the introduced primitive input clipping. I would bring it up a third time if you raise an objection with the change.
Created attachment 1533 [details] Reftest: Primitive subregions don't clip input in most browsers This test shows that filter primitive subregions don't clip input in Safari, Firefox, and Chrome. In IE11, I get an unexpected result (the green square isn't offset at all), so I'd say it's inconclusive.
(In reply to Dirk Schulze from comment #6) > I found it hard to observe. In my tests not even browsers are that > consistent. IE sometimes clips the input as well. But it doesn't do it all > the time. I brought this up to the WG twice. The second time with the > intention to undo the input clipping. In both cases the WG (and the UA reps > with them) wanted to keep the introduced primitive input clipping. I would > bring it up a third time if you raise an objection with the change. Sounds good. I posted my thoughts to the list: http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0043.html
(In reply to Max Vujovic from comment #8) > (In reply to Dirk Schulze from comment #6) > > I found it hard to observe. In my tests not even browsers are that > > consistent. IE sometimes clips the input as well. But it doesn't do it all > > the time. I brought this up to the WG twice. The second time with the > > intention to undo the input clipping. In both cases the WG (and the UA reps > > with them) wanted to keep the introduced primitive input clipping. I would > > bring it up a third time if you raise an objection with the change. > > Sounds good. I posted my thoughts to the list: > http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0043.html We resolved to accept the proposal.(In reply to Max Vujovic from comment #8) > (In reply to Dirk Schulze from comment #6) > > I found it hard to observe. In my tests not even browsers are that > > consistent. IE sometimes clips the input as well. But it doesn't do it all > > the time. I brought this up to the WG twice. The second time with the > > intention to undo the input clipping. In both cases the WG (and the UA reps > > with them) wanted to keep the introduced primitive input clipping. I would > > bring it up a third time if you raise an objection with the change. > > Sounds good. I posted my thoughts to the list: > http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0043.html The proposal was accepted and is part of the specification.