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.
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.
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
than the canvas.
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.