- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 30 Apr 2009 17:31:32 -0700 (PDT)
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 I agree with Philip, that fine-grained control of rendering options is appropriate, if it's made available. The programmer can benchmark, if necessary the time between frames if they're drawing an animation, and they can use various techniques to display a complex scene. Given enough complexity, a low quality rendering would still freeze the browser. For what I've read (excuse me if I've missed it), there's nothing in the manual about rendering quality other than that the canvas shall use 32 bit pixels. Anti-aliasing and sub-pixels are somewhat implied, but not required. Here's a brief survey of available options, which one might want to tune: bezier curve quality [ low, med, high ] -- essentially, a count of quads used to create an individual cubic bezier. 2, 4, more than four quads. aliasing/subpixeling. bitmap size/components. 1 bit, 1 byte, 3 byte, 4 byte. scaling method ( in the long term, I could see seam carving as an option ). lock/unlock and other buffer options. In the short term, I don't think any of these options are worth referencing. they certainly add work to implementation.
Received on Thursday, 30 April 2009 17:31:32 UTC