Re: [whatwg] [canvas] imageRenderingQuality property
On Mon, 30 Jun 2008, Vladimir Vukicevic wrote: On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote: On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). How can an author know which is appropriate? Erm, presumably because they're the author -- it seems quite valid to for an author to be able to say Just make this happen quickly, I don't care about the quality or Take extra time to make this the highest quality you can. But which of those to pick depends on the hardware at least as much as the complexity of the drawing code, as has been noted before. This table shows what the author would want to pick for a given page: 2008: 2008 desktop2008 mobile Complex Graphics high-qualityhigh-speed Simple Graphics high-qualityhigh-quality 2012: 2012 desktop2012 mobile2008 desktop 2018-era Graphicshigh-qualityhigh-speed high-speed Complex Graphics high-qualityhigh-quality high-quality Simple Graphics high-qualityhigh-quality high-quality This table shows the same thing again, but this time the desktop machine is also doing a massive high-CPU job in the background: 2008: 2008 desktop2008 mobile Complex Graphics high-speed high-speed Simple Graphics high-speed high-quality 2012: 2012 desktop2012 mobile2008 desktop 2018-era Graphicshigh-speed high-speed high-speed Complex Graphics high-speed high-quality high-speed Simple Graphics high-qualityhigh-quality high-speed How can the author possibly know what the right answer is? 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] imageRenderingQuality property
How can an author know which is appropriate? Erm, presumably because they're the author -- it seems quite valid to for an author to be able to say Just make this happen quickly, I don't care about the quality or Take extra time to make this the highest quality you can. No problem, all you have to do is define: - this - happen - quickly - quality - extra time - highest Of course the hard bit is that these change for every content developer, often per-platform. -- Charles
Re: [whatwg] [canvas] imageRenderingQuality property
On Mon, Jun 30, 2008 at 7:30 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 30 Jun 2008, Vladimir Vukicevic wrote: On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote: On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). How can an author know which is appropriate? Erm, presumably because they're the author -- it seems quite valid to for an author to be able to say Just make this happen quickly, I don't care about the quality or Take extra time to make this the highest quality you can. 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. So now we need to define levels of graphic burden? and at what level of burden does the quality suffer? Seems just as hard to define. Having the author explicit say this has to be as high quality as possible or less can be low quality seems better and we have examples of other specs offering the same kind of control.
Re: [whatwg] [canvas] imageRenderingQuality property
On Jun 30, 2008, at 4:14 PM, Vladimir Vukicevic wrote: On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote: On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). How can an author know which is appropriate? Erm, presumably because they're the author -- it seems quite valid to for an author to be able to say Just make this happen quickly, I don't care about the quality or Take extra time to make this the highest quality you can. Yes they are the author, but the user is the person actually using the content and history shows that the author will make such decisions based on how *their* machine works. Even if they try to test on other platforms/UAs, you cannot expect them to test the entire gamut from handheld device through to multicore workstations, and then expect them to update their site every 18 months to allow for the increased processing power. The alternative option, is to have the UA detect when a site is attempting to do the kinds of updates that would result in performance problems and make appropriate decisions to improve the performance (eg. reducing image scaling quality). The adjusting UA option has numerous advantages -- it does not require the developer to tests 1000s of different devices; it doesn't require the developer to update their content every few months; it allows the UA to make performance decisions based on the actual hardware and resources available to it at runtime (eg. allowing it to reduce quality on low powered devices); Improvements in UA performance can immediately result in improved quality, without the developer updating the site; Quality is not unnecessarily lowered in newer/faster UAs just because the developer made decisions based on an older/slower UA. Their are disadvantages -- the UA implementation complexity may be increased, quality may be reduced even when not desired by the developer. The first of these issues is to me a non-issue, in a choice between making the UA implementation more complex (which happens once per UA) vs. increasing the workload on the developer for each site in which they use canvas (which may happen 100s or 1000s of times per developer), increasing UA complexity seems the obvious choice. The second issue is more difficult, and i don't have any immediate solution -- you *could* have a flag which forced the UA to always use its highest quality level (which is a noop on current UAs as far as i am aware), but to me it seems that that would merely result in the poor behaviour on low powered devices that the developer did not consider. Finally, in general my experience suggests that if you have such a flag the developers will end up being split into three groups, those who *always* specify fastest, those who always specify highest quality, and those who never use the flag at all. I would also not expect this flag to be used on the basis of any kind of performance or quality testing, based on what they perceive to be most important, regardless as to whether their code actually had any performance issues. (Yes, there will be a few developers who do perf test, etc, and try to make good decisions, but i would expect them to represent a very small minority of developers) --Oliver - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
On 01/07/2008, Ian Hickson [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [whatwg] [canvas] imageRenderingQuality property
So now we need to define levels of graphic burden? and at what level of burden does the quality suffer? Seems just as hard to define. Having the author explicit say this has to be as high quality as possible or less can be low quality seems better and we have examples of other specs offering the same kind of control. No. The whole point is that the UA is in the best position to identify what the tradeoffs are, not the author -- if you want a flag to specify the quality to be used then that would require you to determine what the tradeoffs were yourself, with no substantial knowledge of what combination any given user was actually using. You need to realise that different UAs and different platforms have substantially different performance characteristics. And that said how would you make the decision yourself anyway? Your decision will almost always hurt *some* portion of your userbase, either through lower quality than would otherwise be possible, or by making a page that is unusable for someone with a lower powered device. And then, after you've made that decision you will start getting some people saying UA1 looks better than UA2 because you underestimated performance of the UAs, and UA1 ignores the flag. Or you'll get people saying UA1 is unusable because you found it was slow in UA2, so you dropped the quality setting -- which UA1 ignores, but then a year later you get people saying UA1 looks better again because hardware is faster so it now do its higher quality rendering without any problem -- but UA2 is still using the low quality path. Finally you test on UA1 and UA2, and find your site looks good in one, but is too slow in the other, do you now lower the quality in both so that your site is usable in both, or do you try and make the decision in JS at runtime? If the latter you now have quite a bit more work to do. How do you determine the performance of a particular UA/platform combination? JS performance is not the same as canvas, so you have to manually test canvas performance, so you are now trying to hand code what could already be built into the UA. Alternatively you could just try to take the lazy path and do a UA check, and try to determine the performance based on UA but now you have *all* of the standard UA check problems, and you still can't test the real performance because you don't know what hardware you're on. If the UA makes its own decisions about performance, it can make a decision based on a wide range of information that you do not have any access to, in addition to being aware of the specific costs of certain operations (eg. a UA could choose to lower the quality of only a single operation, like image scaling, but leave other operations at their standard fidelity -- trying to do this in a flag would be both horrifically complicated for authors *and* would represent tremendous over specification by the standard) --Oliver
