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
