[whatwg] Bicubic filtering on context.drawImage

[Rik Cabanier]

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.