- From: Philip Taylor <excors+whatwg@gmail.com>
- Date: Tue, 1 Jul 2008 01:04:49 +0100
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. -- Philip Taylor excors at gmail.com
Received on Monday, 30 June 2008 17:04:49 UTC