[whatwg] Bicubic filtering on context.drawImage

[K. Gadd]

In game scenarios it is sometimes necessary to have explicit control
over the filtering mechanism used, too. My HTML5 ports of old games
all have severe rendering issues in every modern browser because of
changes they made to canvas semantics - using filtering when not
requested by the game, sampling outside of texture rectangles as a
result of filtering, etc - imageSmoothingEnabled doesn't go far enough
here, and I am sure there are applications that would break if
bilinear was suddenly replaced with bicubic, or bicubic was replaced
with lanczos, or whatever. This matters since some applications may be
using getImageData to sample the result of a scaled drawImage and
changing the scaling algorithm can change the data they get.

One example I can think of is that many games bilinear scale a tiny
(2-16 pixel wide) image to get a large, detailed gradient (since
bilinear cleanly interpolates the endpoints). If you swap to another
algorithm the gradient may end up no longer being linear, and the
results would change dramatically.

On Fri, Mar 14, 2014 at 1:45 PM, Simon Sarris <sarris at acm.org> wrote:
> On Fri, Mar 14, 2014 at 2:40 PM, Justin Novosad <junov at google.com> wrote:
>>
>>
>> Yes, and if we fixed it to make it prettier, people would complain about a
>> performance regression. It is impossible to make everyone happy right now.
>> Would be nice to have some kind of speed versus quality hint.
>
>
> As a canvas/web author (not vendor) I agree with Justin. Quality is very
> important for some canvas apps (image viewers/editors), performance is very
> important for others (games).
>
> Canvas fills a lot of roles, and leaving a decision like that up to
> browsers where they are forced to pick one or the other in a utility
> dichotomy. I don't think it's a good thing to leave "debatable" choices up
> to browser vendors. It ought to be something solved at the spec level.
>
> Either that or end users/programmers need to get really lucky and hope all
> the browsers pick a similar method, because the alternative is a
> (admittedly soft) version of "This site/webapp best viewed in Netscape
> Navigator".
>
> Simon Sarris