[whatwg] Bicubic filtering on context.drawImage

[K. Gadd]

As I mentioned to Ryosuke off-list, I think the
interpolateEndpointsCleanly attribute is a (relatively) simple solution to
the problem I have with the current spec, and it doesn't
overcomplicate things or make it hard to improve filtering in the
future. It's also trivial to feature-detect, which means I can use it
when available and fallback to a temporary canvas otherwise. I think
providing this option would also make it easier to solve situations
where applications rely on the getImageData output after rendering a
scaled bitmap.

I'd probably call it something (to me) clearer about semantics, though,
like 'sampleInsideRectangle'

On Wed, 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.