Re: Filter Effects and High DPI

BTW: this is https://bugs.webkit.org/show_bug.cgi?id=93471 in WebKit.

Dean

On 16/03/2013, at 5:59 AM, Stephen White <senorblanco@chromium.org> wrote:

> Hi folks,
> 
> Sorry if this has been addressed before, but I'm wondering whether High DPI support has been discussed for W3C Filter Effects.
> 
> 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).
> 
> 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.
> 
> Stephen