[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
>

Received on Monday, 30 June 2008 16:56:04 UTC