W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

Re: Filter Effects and High DPI

From: Dirk Schulze <dschulze@adobe.com>
Date: Fri, 15 Mar 2013 14:30:54 -0700
To: Stephen White <senorblanco@chromium.org>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <1EFA3CEF-C292-4969-9629-D38C95F2F87C@adobe.com>

On Mar 15, 2013, at 2:06 PM, Stephen White <senorblanco@chromium.org> wrote:

> On Fri, Mar 15, 2013 at 3:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Mar 15, 2013 at 11:59 AM, Stephen White
> <senorblanco@chromium.org> wrote:
> > In particular, in Chrome's accelerated implementation, on a high-DPI
> > display, we get high-DPI input images from the compositor.  Right now,  we
> > filter the high-DPI image by the original (unscaled) parameter values,
> > which, for the filters whose pixel's result depends on more than a single
> > input pixel value (e.g., blur(), drop-shadow()), results in less blurring
> > than would be visible on a non-HighDPI display.  This seems wrong.  (Last
> > time I checked, the non-composited path was downsampling the input
> > primitive, giving a non-high-DPI result but correct amounts of blur,
> > although that may have been fixed).
> 
> This is a bug in our implementation, then.  The values in the
> functions are CSS values, so a length of "5px" means 5 CSS pixels, not
> 5 hardware pixels.  The browser has to scale that to whatever internal
> notion of "pixel" it's using.
> 
> Right, the question is which way should it go:  scale up the parameter values, or downsample the input primitive.  Currently the raster path in WebKit does the latter and the Chrome compositor does neither, so obviously that's broken.  Scaling up the parameter values seems better for highDPI, but doesn't completely work for the feConvolveMatrix case for example.
> 
> In the spec, I'm guessing it falls under this text (for filterRes): "If not provided, then the user agent will use reasonable values to produce a high-quality result on the output device."  So a high-DPI implementation is free to render a primitive at high-DPI, and scale up the parameter values (internally) to match.

This implementation detail should better be discussed on the webkit-dev mailing list or better on a bug report.

Greetings,
Dirk

> 
> Stephen
> 
> > > For blur() and drop-shadow(), It would be straightforward to scale the
> > > parameter values by the devicePixelRatio automatically, and achieve the
> > > correct amount of blurring without affecting the resolution of the result.
> > > Of course, we could downsample the input primitive for all filters, but that
> > > would lose the high DPI even for those filters which are unaffected by this
> > > problem, e.g., brightness() etc.
> > >
> > > However, for the reference filters, in particular feConvolveMatrix, it's not
> > > clear what the optimal behaviour is.  It's tempting to simply multiply the
> > > kernelUnitLength by the devicePixelRatio, and apply the convolution as
> > > normal.  However, that also loses high DPI, and incurs the cost of a
> > > downsample where it otherwise wouldn't be required (also note that
> > > kernelUnitLength seems to be unimplemented in WebKit, but that's our
> > > problem).  Would it be a possibility to simply upsample the kernel by
> > > devicePixelRatio instead, and apply that kernel to the original unscaled
> > > image?   (Or perhaps size' = (size - 1) * devicePixelRatio + 1 for odd
> > > kernel sizes?)   This would result in a similar effect range, while
> > > preserving the resolution of the source image.
> > >
> > > I have no idea if the convolution math is really correct this way, though.
> > > I'm guessing not, since if it was, presumably the spec would have allowed
> > > its use for kernelUnitLength application in general.
> >
> > I'm not sufficiently familiar with feConvolveMatrix to know how to
> > handle it well.  However, if you get a substantially different result
> > (beyond rendering/scaling artifacts), the implementation is definitely
> > wrong in some way.  None of SVG or CSS should require knowledge of the
> > device's DPI.
> >
> > ~TJ
Received on Friday, 15 March 2013 21:32:18 GMT

This archive was generated by hypermail 2.3.1 : Friday, 15 March 2013 21:32:19 GMT