On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa <rn...@apple.com> wrote:
> > On Mar 24, 2014, at 8:25 AM, Justin Novosad <ju...@google.com> wrote: > > > On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd <k...@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.