- From: Vladimir Vukicevic <vladimir@pobox.com>
- Date: Mon, 2 Jun 2008 14:15:51 -0700
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
>>
>
Received on Monday, 2 June 2008 14:15:51 UTC