[whatwg] Bicubic filtering on context.drawImage

[Ryosuke Niwa]

On Mar 26, 2014, at 9:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa <rniwa at apple.com> wrote:
> 
>> 
>> On Mar 24, 2014, at 8:25 AM, Justin Novosad <junov at google.com> wrote:
>> 
>>> On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd <kg at luminance.org> wrote:
>>> 
>>>> 
>>>> A list of resampling methods defined by the spec would be a great
>>>> overengineered (not in a bad way) solution, but I think you really
>>>> only need to worry about breaking existing apps - so providing an
>>>> escape valve to demand bilinear (this is pretty straightforward,
>>>> everything can do bilinear) instead of the 'best' filtering being
>>>> offered is probably enough for future-proofing. It might be better to
>>>> default to bilinear and instead require canvas users to opt into
>>>> better filtering, in which case a list of available filters would
>>>> probably be preferred, since that lets the developer do feature
>>>> detection.
>>>> 
>>>> I think we missed an opportunity to make filtering future-proof when it
>>> got spec'ed as a boolean. Should have been an enum IMHO :-(
>>> Anyways, if we add another image smoothing attribute to select the
>>> algorithm let's at least make that one an enum.
>>> 
>>> I'm not sure the spec should impose specific filter implementations, or
>>> perhaps only bi-linear absolutely needs to be supported, and all other
>>> modes can have fallbacks.
>>> For example.  We could have an attribute named imageSmoothingQuality.
>>> possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean
>>> bi-linear. Not sure which mode should be the default.
>> 
>> We could also have interpolateEndpointsCleanly flag that forces bilinear
>> or an equivalent algorithm that ensures endpoints do not get affected by
>> inner contents.
>> 
> 
> Is that to clamp the sampling to the source rect?
> http://jsfiddle.net/6vh5q/9/ shows that Safari samples when smoothing is
> turned off which is a bit strange.
> 
> 
>> In general, it's better to define semantic based flags and options so that
>> UAs could optimize it in the future.  Mandating a particular scaling
>> algorithm in the spec. would limit such optimizations in the future.  e.g.
>> there could be a hardware that natively support Lanczos sampling but not
>> Bicubic sampling.
>> 
> 
> If it was an enum/string, an author could set the desired sampling method
> and if the UA doesn't support it, the attribute would not change.


The point I was trying to make isn't so much about some UA not supporting a particular sampling algorithm.  It's more about that the right/most-effective sampling algorithm depending on platform/hardware.  In general, UA is in a much better position to determine what sampling algorithm works best given the constraints such as smoothness and interpolating endpoints cleanly on a given hardware.

- R. Niwa