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

[timeless]

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.