On Tue, Nov 18, 2008 at 4:09 AM, timeless <span dir="ltr"><<a href="mailto:timeless@gmail.com">timeless@gmail.com</a>></span> wrote:<br><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;">
<div class="Ih2E3d">On Tue, Nov 18, 2008 at 3:15 AM, Tab Atkins Jr. <<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>> wrote:<br>
> Keep in mind what we're dealing with here.<br>
<br>
</div>dumb web authors. check.<br>
<div class="Ih2E3d"><br>
> This isn't some trivial Javascript timer firing off events at 60Hz.<br>
<br>
> This is a full <video><br>
> element.  If a little "i++; if( i%60 == 0) {code}" is killing the CPU, then<br>
> that device isn't capable of playing a <video> either.<br>
<br>
</div>if that little code causes the entire page to reflow because the web<br>
author is stupid, then it's a problem.<br>
<br>
if i'm really lucky my device might be able to use a special module to<br>
deal w/ video processing without killing my battery life.<br>
<br>
while i am praying that JIT will improve my life, it won't save my<br>
battery from stupid web authors and their pages.<br>
<br>
where possible we want to be able to optimize, video is something<br>
which can be handled by a specialized processor.<br>
javascript which causes the page to reflow because the author did<br>
something 'strange' which only effects my small device and didn't<br>
appear when he tested it on something else, otoh isn't something i can<br>
specialize. other than turning it off, and if i do that, people<br>
complain my product is broken.<br>
<br>
they also say my device sucks when the battery life doesn't match<br>
their expectations.<br>
<br>
sadly, customers are valuable.<br>
<br>
if the embedders (and antti clearly represents one, and I represent<br>
another) express clearly that they don't want something, it's probably<br>
a good idea to listen.<br>
<br>
while it's true that you could write code which checked a counter and<br>
only did work on the nth iteration, it's unlikely that you would. such<br>
counters are also likely to be calibrated for the wrong type of device<br>
meaning you get other problems - perhaps the progress bar doesn't<br>
update often enough on slower devices, and not because the event<br>
wasn't sent often enough but because it was filtered by the page.<br>
<div class="Ih2E3d"><br>
On Tue, Nov 18, 2008 at 1:19 AM, Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<br>
> That makes a lot more sense than limiting the timeupdate period.<br>
> Firing timeupdate on discontinuous changes and requiring apps<br>
> to also use a regular timer to get periodic updates sounds reasonable to me.<br>
<br>
</div>this sounds good to me too.<br>
</blockquote></div><br>After reading more feedback, I'm agreeing with you, but note that my original point wasn't against what you were saying anyway.  ^_^  It was just disputing that a counter-based js loop would kill performance.<br>
<br>Noted, though, that many people will, without thinking, just update on every tick rather than figuring out what a significant interval to use is, and that the potential differences in tick speed (4Hz to 66Hz right now, right?  somewhere around there?) mean that you *can't* just run a simple counter and update every nth tick.  You'll still have to do some time comparisons.<br>
<br>~TJ<br>