- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 18 Nov 2008 08:34:40 -0600
On Tue, Nov 18, 2008 at 4:09 AM, timeless <timeless at gmail.com> wrote: > On Tue, Nov 18, 2008 at 3:15 AM, Tab Atkins Jr. <jackalmage at gmail.com> > wrote: > > Keep in mind what we're dealing with here. > > dumb web authors. check. > > > This isn't some trivial Javascript timer firing off events at 60Hz. > > > This is a full <video> > > element. If a little "i++; if( i%60 == 0) {code}" is killing the CPU, > then > > that device isn't capable of playing a <video> either. > > if that little code causes the entire page to reflow because the web > author is stupid, then it's a problem. > > if i'm really lucky my device might be able to use a special module to > deal w/ video processing without killing my battery life. > > while i am praying that JIT will improve my life, it won't save my > battery from stupid web authors and their pages. > > where possible we want to be able to optimize, video is something > which can be handled by a specialized processor. > javascript which causes the page to reflow because the author did > something 'strange' which only effects my small device and didn't > appear when he tested it on something else, otoh isn't something i can > specialize. other than turning it off, and if i do that, people > complain my product is broken. > > they also say my device sucks when the battery life doesn't match > their expectations. > > sadly, customers are valuable. > > if the embedders (and antti clearly represents one, and I represent > another) express clearly that they don't want something, it's probably > a good idea to listen. > > while it's true that you could write code which checked a counter and > only did work on the nth iteration, it's unlikely that you would. such > counters are also likely to be calibrated for the wrong type of device > meaning you get other problems - perhaps the progress bar doesn't > update often enough on slower devices, and not because the event > wasn't sent often enough but because it was filtered by the page. > > On Tue, Nov 18, 2008 at 1:19 AM, Robert O'Callahan <robert at ocallahan.org> > wrote: > > That makes a lot more sense than limiting the timeupdate period. > > Firing timeupdate on discontinuous changes and requiring apps > > to also use a regular timer to get periodic updates sounds reasonable to > me. > > this sounds good to me too. > 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. 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. ~TJ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081118/d2cdec38/attachment.htm>
Received on Tuesday, 18 November 2008 06:34:40 UTC