W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Bicubic filtering on context.drawImage

From: Justin Novosad <junov@google.com>
Date: Mon, 24 Mar 2014 11:25:10 -0400
Message-ID: <CABpaAqSqFgH5U9jW3qrxPAG7f2w321T5OPmxz4Cs9gnYVY09SQ@mail.gmail.com>
To: Katelyn Gadd <kg@luminance.org>
Cc: WHATWG <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>, Simon Sarris <sarris@acm.org>
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.

Received on Monday, 24 March 2014 15:41:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC