[whatwg] [canvas] imageRenderingQuality property

[David Hyatt]

On Jun 2, 2008, at 4:57 PM, Vladimir Vukicevic wrote:

>
> On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote:
>> 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.
>
> If web apps misuse the property, then bugs should be filed on those  
> apps that incorrectly use the property, and the app developer should  
> fix them.  The web platform shouldn't prevent developers from  
> exercising control over how their content is rendered; most  
> developers, as you say, probably shouldn't change anything from the  
> default 'auto'.  But the capability should be there.  Arbitrarily  
> deciding what developers can and can't do isn't interesting from the  
> perspective of creating a full-featured platform, IMO.
>
> No matter how fast smooth/bilinear filtering is, something more  
> complex is always going to be slower, and something less complex is  
> always going to be faster.  If those perf differences are  
> significant to the web app, no matter how small, you're going to  
> want to be able to have that control.  If they're not, then you  
> should just be using 'auto' and let the UA handle it.

I completely agree.  Almost any feature can be abused.  It's not our  
job to withhold features just because they can be abused.  It's also  
worth pointing out that this is a common graphical knob supported by  
Cairo and CoreGraphics.  It is a proprietary MS CSS property and an  
SVG CSS property.  In other words, it seems to be a pretty widely  
implemented feature and as such seems like it would be a worthwhile  
addition to canvas.

If we add this, we should also add support for text rendering quality  
as well, since canvas is picking up the ability to draw text.

dave
(hyatt at apple.com)