On Tue, Nov 18, 2008 at 12:09 PM, Antti Koivisto <span dir="ltr"><<a href="mailto:antti@apple.com">antti@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 16.11.2008, at 16:16, Ian Hickson wrote:<br><div class="Ih2E3d">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
With polling, the polling will miss key points, e.g. when the playback<br>
loops, which will result in the UI appearing to lag behind the playback.<br>
It will also cause higher processing cost while there is no need to send<br>
updates, e.g. while seeking or waiting for data, times where you really<br>
don't want extra load.<br>
</blockquote>
<br></div>
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?</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- Requiring events on every frame might make some playback optimizations impossible (by requiring constant activation of the web engine thread during playback).<br>
</blockquote><div> <br>Can you be more specific?<br></div></div><br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>