[whatwg] Bicubic filtering on context.drawImage

[Rik Cabanier]

On Wed, Mar 26, 2014 at 10:23 PM, Ryosuke Niwa <rniwa at apple.com> wrote:

>
> 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.
>

Yes, figuring out the various aliasing options will be difficult to figure
out.
Katalyn's use case is with controlling the sampling outside the source rect
in drawImage which we can treat as a separate, more trivial issue.