Re: [whatwg] Bicubic filtering on context.drawImage

On Mar 24, 2014, at 8:25 AM, Justin Novosad <junov@google.com> wrote:

> On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd <kg@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.

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.

- R. Niwa

Received on Thursday, 27 March 2014 03:59:40 UTC