Re: feDisplacement filter -- problem with spec and image quality

Hi David,

You brought up a good point about the cross-browser inconsistency in
feDisplacement rendering. I agree with you that it seems logical to expect
a certain degree of resampling/smoothing of the distorted image, although
that may be subject to performance limitations.

I've posted the text of your email as an issue on the FX Task Force's
GitHub repo, so it doesn't get lost:
https://github.com/w3c/fxtf-drafts/issues/21

All this, however, is separate from any proposal to support vector-based
curve distortion.  I would love to see that in a future SVG spec, but it
won't be via filter effects, which by definition always operate on a
rasterized bitmap layer.

Best,
Amelia


On 9 August 2016 at 13:05, David Dailey <ddailey@zoominternet.net> wrote:

> Hi folks,
>
>
>
> Compare this page in Chrome and Firefox (Windows).
>
>
>
> http://cs.sru.edu/%7Eddailey/svg/distortGrid0.svg <http://cs.sru.edu/~ddailey/svg/distortGrid0.svg> Compare both speed and image quality.
>
>
>
> You’ll note that Firefox performs much faster. I am told [1] that this is because “Firefox on Windows uses Direct2D IIRC, and the filters are accelerated.” The speed issue should be handled later, according to the Chrome folks.
>
>
>
> The troublesome thing, though, is the image quality. Observe the crispness of the edges in Firefox and the truly inadequate rendering in Chrome. When I raised the issue as a Chrome bug [1] the folks there did a goodly amount of research on the history of the problem and it seems to be a spec bug rather than a browser bug, introduced when the filters module was split out from the rest. (I’m so not in favor of having 29 different specs and Working Groups – it’s always a prime number -- to talk to when I find a problem with SVG that wasn’t there before!)
>
>
>
> I made a slightly simplest version here: http://cs.sru.edu/~ddailey/
> svg/distortGrid.svg without some of the aesthetic niceties.
>
>
>
> I gather it comes from not specifying how the feDisplacement’s effect on
> its results will be resampled.
>
>
>
> Ultimately, if an feDisplacement is applied to a vector image, we might,
> alternatively, approach the problem by doing a convolution of the
> respective functions (applying the continuous Perlin noise, functionally,
> to the associated curves themselves, resulting in vector rather than
> pixel-based output – but the math here could get gnarly – I don’t know. )
> At any rate, having a flexible set of distortion filters that preserves
> vectors would be a good thing to think about for SVG3, if it’s not already
> in the wish lists. Having a bitmap at the core of spherical distortion [2]
> in the test cases seems a bit like a hack to me!
>
>
>
> In the  meantime, can we require feDisplacement to do a little better?
> It’s not only a problem when vectors are distorted – note how the bitmaps
> crack and separate using Chrome here: https://ello.co/ddailey/post/
> iagdm_myjtpdy9dyvsoozq
>
> I can report that this sort of cracking didn’t happen in Adobe’s ASV, nor
> in Opera during its SVG-, so this is, indeed moving back to <SVG1.1.  – of
> course the examples that used to work in ASV and Opera heyday (remember the
> fried egg-billiards and the face distorted by pond ripples from 2005?) no
> longer work anywhere (due to other manifestations of “progress” – I think I
> used enable-background or some such thing, since in those days you could!).
>
>
>
> Regards
>
> David
>
> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=634115
>
> [2] http://cs.sru.edu/~ddailey/svg/feComposite9.svg
>