Remove kernelUnitLength plumbing

Remove kernelUnitLength plumbing

'kernelUnitLength' is not supported in Blink, and is deprecated in the
spec [1][2][3].
Rip out the plumbing and (FilterEffect) storage for it, since it's dead
code for practical purposes (see below though...)

The svg/dynamic-updates/SVGFEConvolveMatrixElement-*-kernelUnitLength-*
tests now actually show something because the kernelUnitLength of 0.05
no longer truncate to 0 and trigger an error. (0.05 should have been a
valid value previously too.)

The tests for negative kernelUnitLengths are dropped because they're no
longer of any use.

[1] https://drafts.fxtf.org/filters/#element-attrdef-feconvolvematrix-kernelunitlength
[2] https://drafts.fxtf.org/filters/#element-attrdef-fediffuselighting-kernelunitlength
[3] https://drafts.fxtf.org/filters/#element-attrdef-fespecularlighting-kernelunitlength
    (feSpecularLighting seems to be missing the Note, but it's the same
     as for feDiffuseLighting anyhow.)

BUG=231613
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=202601

[fs, 2015-09-21 11:24:12]

fs@opera.com changed reviewers:
+ fmalita@chromium.org, pdr@chromium.org, senorblanco@chromium.org

[fs, 2015-09-21 11:24:13]

I figured we weren't going to implement support for this any time "soon" (if at
all...), so this code seemed to do more harm then good.

[f(malita), 2015-09-21 12:43:26]

LGTM

[Stephen White, 2015-09-21 13:51:49]

I'm a little hesitant to remove this, since I actually think it's quite
important that we implement it at some point, even if it's simply by a
downsample-and-upsample. feConvolveMatrix, in particular, behaves in unintuitive
ways on hiDPI devices, since the visible scope of the effect depends on the DPI.
(Same for zoom.)

Granted, we could always revert this change when we start the implementation,
but it's something of a signal that we don't plan to do so.

[Stephen White, 2015-09-21 13:53:01]

Reading again, I didn't realize it has been deprecated in the spec. That seems
unfortunate, but
I suppose it reflects browser reality.

LGTM

[fs, 2015-09-21 14:04:37]

On 2015/09/21 at 13:53:01, senorblanco wrote:
> Reading again, I didn't realize it has been deprecated in the spec. That seems
unfortunate, but
> I suppose it reflects browser reality.
> 
> LGTM

It also says: "It does not provide a reliable way to create platform independent
results. Future versions of this specification will cover this use case." - the
former I can do nothing but agree with, but I wouldn't hold my breath for the
latter... That being said though, if you have any ideas of how you'd like it to
be specified, then providing that in one way or another to the FXTF, that'd
probably be good (even if it may just end up resting in a ML archive for the
foreseeable future...) It'd of course be even better if the attribute wasn't
exposed at all, but some mistakes take more time to fix than others...

[Stephen White, 2015-09-21 14:33:37]

On 2015/09/21 14:04:37, fs wrote:
> It also says: "It does not provide a reliable way to create platform
independent
> results. Future versions of this specification will cover this use case." -
the
> former I can do nothing but agree with, but I wouldn't hold my breath for the
> latter... That being said though, if you have any ideas of how you'd like it
to
> be specified, then providing that in one way or another to the FXTF, that'd
> probably be good (even if it may just end up resting in a ML archive for the
> foreseeable future...) It'd of course be even better if the attribute wasn't
> exposed at all, but some mistakes take more time to fix than others...

Now that I think about it some more, the hiDPI and zoom problem can be fixed
without having a web-exposed attribute (which probably *is* a mistake -- like
filterRes, it's just another way that users can shoot themselves in the foot).

I had imagined that the same machinery used to implement kernelUnitLength
could be used automatically (when kernelUnitLength was unspecified) to 
scale the content. But that's orthogonal to having it web-exposed, and I had
conflated the two in my head.

So let's go ahead and remove the plumbing.

[fs, 2015-09-21 14:43:05]

On 2015/09/21 at 14:33:37, senorblanco wrote:
> On 2015/09/21 14:04:37, fs wrote:
> > It also says: "It does not provide a reliable way to create platform
independent
> > results. Future versions of this specification will cover this use case." -
the
> > former I can do nothing but agree with, but I wouldn't hold my breath for
the
> > latter... That being said though, if you have any ideas of how you'd like it
to
> > be specified, then providing that in one way or another to the FXTF, that'd
> > probably be good (even if it may just end up resting in a ML archive for the
> > foreseeable future...) It'd of course be even better if the attribute wasn't
> > exposed at all, but some mistakes take more time to fix than others...
> 
> Now that I think about it some more, the hiDPI and zoom problem can be fixed
> without having a web-exposed attribute (which probably *is* a mistake -- like
> filterRes, it's just another way that users can shoot themselves in the foot).

Yeah, same type of well-intentioned construct...

> I had imagined that the same machinery used to implement kernelUnitLength
> could be used automatically (when kernelUnitLength was unspecified) to 
> scale the content. But that's orthogonal to having it web-exposed, and I had
> conflated the two in my head.
> 
> So let's go ahead and remove the plumbing.

I'll give pdr a chance to comment as well. Just in case.

[pdr., 2015-09-21 17:44:51]

On 2015/09/21 at 14:43:05, fs wrote:
> On 2015/09/21 at 14:33:37, senorblanco wrote:
> > On 2015/09/21 14:04:37, fs wrote:
> > > It also says: "It does not provide a reliable way to create platform
independent
> > > results. Future versions of this specification will cover this use case."
- the
> > > former I can do nothing but agree with, but I wouldn't hold my breath for
the
> > > latter... That being said though, if you have any ideas of how you'd like
it to
> > > be specified, then providing that in one way or another to the FXTF,
that'd
> > > probably be good (even if it may just end up resting in a ML archive for
the
> > > foreseeable future...) It'd of course be even better if the attribute
wasn't
> > > exposed at all, but some mistakes take more time to fix than others...
> > 
> > Now that I think about it some more, the hiDPI and zoom problem can be fixed
> > without having a web-exposed attribute (which probably *is* a mistake --
like
> > filterRes, it's just another way that users can shoot themselves in the
foot).
> 
> Yeah, same type of well-intentioned construct...
> 
> > I had imagined that the same machinery used to implement kernelUnitLength
> > could be used automatically (when kernelUnitLength was unspecified) to 
> > scale the content. But that's orthogonal to having it web-exposed, and I had
> > conflated the two in my head.
> > 
> > So let's go ahead and remove the plumbing.
> 
> I'll give pdr a chance to comment as well. Just in case.

LGTM!

[fs, 2015-09-21 17:48:33]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2015-09-21 17:49:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1354923003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1354923003/40001

[commit-bot: I haz the power, 2015-09-21 20:08:59]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=202601