If you don't mind someone weighing in who's
been working with the Nintendo Wii for the past year and a half, I have
found that the "quality" setting in Flash is tremendously useful. While
the march of Moore's law has ensured that Flash on the desktop is
zippy, it has also created a gap whereby smaller devices are powerful
enough to compete with last generation desktops. For these devices, the
quality setting is more than a "nice to have". It's absolutely critical
to obtaining decent performance.<br>
<br>The algorithm&#39;s I&#39;ve used over on WiiCade automatically adjust for
high quality when on the desktop, and low to medium quality when on the
Wii. This provides a more consistent experience to users of both
systems. In addition, many game provide a quality setting in their
options screen. (Similar to the rendering features options in most 3D
games.) This allows the user to adjust the rendering speed manually if
he finds his system is too slow or the game in question is more than
fast enough on the Wii.<br>
<br>I can see a quality setting in Javascript used in much the same
way. The site would set the quality of the rendering based on knowledge
of particular platforms. Modern desktops would default to highest
quality. Furthermore, video games (and we all know that&#39;s going to be a
huge use of Canvas at some point ;-)) that push the limit of Canvas may
allow the user to &quot;shift down&quot; as it were to compensate for their
slower machine or the slow Canvas rendering of their browser.<br>
<br>I definitely think this setting should be a hint rather than a hard
and fast set of rules. If a UA (especially desktop UAs) wants to ignore
the setting, that&#39;s fine. It will cause no appreciable damage. But it
will allow for slower UAs to be tuned for usage. e.g. If I&#39;m looking at
charts on my Wii, I&#39;d rather they be high quality. If I&#39;m playing a
video game, the quality simply does not matter as much.<br>
<br>I hope you will all keep we poor device users in mind when you come to your decision. <br><br>Thanks!<br><font color="#888888">Jerason Banes</font><div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Mon, Jun 2, 2008 at 5:52 PM, Oliver Hunt &lt;<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>&gt; wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br><div><div><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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. &nbsp;You&#39;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.</blockquote>
 <div><br>If the quality knob is no longer necessary, why would new content perform badly?</div></div></blockquote></div><div>The
issue is not that certain operations are slower than others, the issue
is that anything that requires the developer to choose between
performance/quality is going to become obsolete as the performance
trade offs are constantly moving and are not the same from UA to UA,
from platform to platform. &nbsp;I think the issue of performance is a
complex one that will not benefit in the long term from a simple on off
switch. &nbsp;Conceivably we could introduce new rendering primitives, such
as CanvasSprite, CanvasLayer, or some such which would, i suspect,
provide a similar benefit, but be more resilient in the face of
changing performance characteristics.</div>
</div></div></blockquote></div><br>
</div></div>