- From: Justin Novosad <junov@google.com>
- Date: Mon, 24 Mar 2014 11:25:10 -0400
- 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. -Justin
Received on Monday, 24 March 2014 15:41:52 UTC