[whatwg] [canvas] imageRenderingQuality property

[Oliver Hunt]

That's exactly what i would be afraid of people doing.  If I have a  
fast system why should i have to experience low quality rendering?  It  
should be the job of the platform to determine what level of  
performance or quality can be achieved on a given device.  Typically  
such a property would be considered a "hint", and as such would likely  
be ignored.

If honouring this property was _required_ rather than being a hint you  
would hit the following problems:
* Low power devices would have a significant potential for poor  
performance if a developer found that their desktop performed well so  
set the requirement to high quality.
* High power devices would be forced to use low quality rendering  
modes when perfectly capable of providing better quality without  
significant performance penalty.

Neither of these apply if the property were just a hint, but now you  
have to think about what happens to content that uses this property in  
18 months time.  You've told the UA to use a low quality rendering  
when it may no longer be necessary, so now the UA has a choice it  
either always obeys the property meaning lower quality than is  
necessary so that new content performs well, or it ignores the  
property in which case new content performs badly.

The correct behaviour would be for the UA to work out itself what it  
can do, which it needs to be able to do anyway, in order to satisfy  
the "auto" option.

--Oliver

On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote:

>
> Sure; bilinear filtering is slower than nearest neighbour sampling,  
> and in many cases the app author would like to be able to decide  
> that tradeoff (or, at least, to be able to say "I want this to go as  
> fast as possible, regardless of quality").  Some apps might also  
> render to a canvas just once, and would prefer to do it at the  
> highest quality filtering available even if it's more expensive than  
> the default.
>
>    - Vlad
>
> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>> Um, could you actually give some kind of reasoning for these?  I am  
>> not aware of any significant performance issues in Canvas that  
>> cannot be almost directly attributed to JavaScript itself rather  
>> than the canvas.
>>
>> --Oliver
>>
>> On Jun 2, 2008, at 12:19 PM, 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).  This is  
>>> modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>> :
>>>
>>> attribute string imageRenderingQuality;
>>>
>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>> to balance speed and quality, but quality shall be given more  
>>> importance than speed.
>>>
>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>
>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>
>>> No specific image sampling algorithm is specified for any of these  
>>> properties, with the exception that, at a minimum, nearest- 
>>> neighbour resampling should be used.  One alternative is to  
>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>> opposed to the SVG names; I think those names are more  
>>> descriptive, but there might be value in keeping the names  
>>> consistent with SVG, especially if that property bubbles up into  
>>> general CSS usage.
>>>
>>>  - Vlad
>>>
>>
>