W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

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

From: Paul Chambers <Paul.Chambers@palm.com>
Date: Mon, 17 Nov 2008 18:12:21 -0800
Message-ID: <1835DC768EFA024692D1603EF90E34820EBEB4A7F3@ushqwmb02.palm1.palmone.com>

> Date: Tue, 18 Nov 2008 12:19:06 +1300
> From: "Robert O'Callahan" <robert at ocallahan.org>
>
> On Tue, Nov 18, 2008 at 12:09 PM, Antti Koivisto
> <antti at apple.com> wrote:
>
> > On 16.11.2008, at 16:16, Ian Hickson wrote:
<snip>
> >> With polling, the polling will miss key points, e.g. when
> >> the playback loops, which will result in the UI appearing
> >> to lag behind the playback.
> >> It will also cause higher processing cost while there is
> >> no need to send updates, e.g. while seeking or waiting for
> >> data, times where you really don't want extra load.
> >
> > The earlier iteration of the spec already fired timeupdate
> > events on all discontinuous changes in time. How would this
> > event flood be an improvement over that?
>
> 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.
>
<snip>

I'd like to see the option to have an timeupdate event sent whenever the time/position has changed by more than a time period from the last one sent, that time period threshold being settable from javascript.

Say I have a progress bar 120 pixels long, and a four minute long video clip is playing. I'd like to be able to set that threshold to 2 seconds, so the timeupdate event would be received each time the progress bar actually needs to be updated (i.e. the position has moved by the equivalent of at least one pixel on the progress bar).

Making a distinction between progress of the position through the content, and 'real time' passing (as you'd get with a timer) becomes important when you're playing at rates other than 1.0x forward. It makes sense to me to receive more frequent update events when the content is being played at greater than 1.0x speeds (e.g. fast forward, rewind) and less frequently if in a slow-motion mode, or paused.

I'm not a fan of timer-based/polling solutions, particularly for mobile devices - it's hard to know at the power management level when it's safe to start clocking down and/or turning stuff off.

I guess it all depends how long you want the battery to last ;)

-- Paul
Received on Monday, 17 November 2008 18:12:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC