[whatwg] Video Element Events? - Use Case: Custom Progress Bar

[Tab Atkins Jr.]

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-0001.htm>