Robert O'Callahan wrote:
On Mon, Nov 17, 2008 at 3:19 PM, Jonas Sicking <[EMAIL PROTECTED]> 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
