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

[Jonas Sicking]

Robert O'Callahan wrote:
> On Mon, Nov 17, 2008 at 3:19 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 
>     Ian Hickson wrote:
> 
>             Video and audio playback is already extremely CPU intensive,
>             we shouldn't require the UA to burn extra cycles doing
>             unnecessary work.
> 
> 
>         I agree. That was exactly the thinking behind the timeupdate
>         event. It allows the UA to determine how fast to update the UI
>         without hurting performance. Basically it puts the UA in charge
>         of the performance critical aspects instead of hoping that the
>         author will work it out.
> 
> 
>     Though if all implementations are saying that it has the opposite
>     effect then clearly we need to look into if something went wrong :)
> 
> 
> I don't think firing timeupdate on every frame is *that* bad for us, to 
> be honest.

It seems like a pretty big waste of resources to have the following 
script executing 50 times per second:

function timeupdatehandler(e) {
   video = e.target;
   completed = video.currentTime / video.duration;
   thumb = document.getElementById('thumb' + video.id);
   thumb.style.left =
     calcScreenPositionUsingOffsetLeftRecursion(thumb.parentNode) +
     thumb.parentNode.offsetWidth * completed;
   progress = document.getElementById('progress' + video.id);
   progress.style.width =
     progress.parentNode.offsetWidth * completed;
}

Sure, we can pull it off, but why do it? At it certainly doesn't seem to 
archive the goal of the event which apparently is to reduce the amount 
of CPU resources used.

/ Jonas