[whatwg] [canvas] imageRenderingQuality property

[Ian Hickson]

On Tue, 1 Jul 2008, Philip Taylor wrote:
> On 01/07/2008, Ian Hickson <ian at hixie.ch> wrote:
> >
> > It seems better for the browser to simply detect when the graphics 
> > burden being placed on the hardware by the page is too much to be done 
> > at high quality given the current load on the CPU, and for the browser 
> > to automatically drop down to a lower fidelity, higher speed rendering 
> > on the fly when appropriate.
> 
> Sometimes the author will want to force best-quality rendering, 
> regardless of the performance impact. E.g. a photo manipulation 
> application might let you resize a segment of a photo, displaying a live 
> preview (where performance is more important than quality), and then 
> render the final resized image and store it in a canvas for future 
> processing. That final rendering needs to be the best possible quality, 
> so it's not acceptable for the browser to decide that it should 
> semi-randomly drop the quality because it detected the live preview was 
> CPU-intensive.
> 
> Similarly, a pseudo-3d FPS game might load textures at runtime and 
> perform some preprocessing (like resizing to be square, and rendering 
> lots of smaller copies to be used as mipmaps for distant walls so they 
> look prettier), and then draw that processed texture into the game 
> thousands of times a second. Since the preprocessing is only done once, 
> and its result is reused for the whole of the rest of the game, it 
> should be done at the highest possible quality, regardless of 
> performance.
> 
> So, adaptively reducing the quality and allowing no author control seems 
> like a bad idea.
> 
> Perhaps the imageRenderingQuality property could have values 'high' and 
> 'auto', where the default is 'high' (so that existing content continues 
> working the same as it always has, and to avoid surprising authors by 
> randomly switching the rendering quality when they have no reason to 
> expect such weird behaviour), and 'auto' means 'low (but perhaps switch 
> to high if the browser thinks it's going to be fast enough)'. That would 
> avoid the issue of authors setting quality='low' and preventing 
> high-speed users from getting the best quality output.

I've made a note of this in the spec:

  // v4 we've also received requests for:
          attribute boolean <span title="dom-context-2d-forceHighQuality">forceHighQuality</span> // (default false)
  // when enabled, it would prevent the UA from falling back on lower-quality but faster rendering routines
  // useful e.g. for when an image manipulation app uses <canvas> both for UI previews and the actual work

I haven't added it yet because mozImageSmoothingEnabled doesn't seem to be 
used much (if at all?) and the uses of canvas so far have apparently not 
really run into serious performance problems yet.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'