[webkit-reviews] review granted: [Bug 45263] Add mediaPlayerPlaybackStateChanged to MediaPlayerClient : [Attachment 66635] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Sep 7 08:21:49 PDT 2010
Eric Carlson <eric.carlson at apple.com> has granted Tor Arne Vestbø
<vestbo at webkit.org>'s request for review:
Bug 45263: Add mediaPlayerPlaybackStateChanged to MediaPlayerClient
https://bugs.webkit.org/show_bug.cgi?id=45263
Attachment 66635: Patch
https://bugs.webkit.org/attachment.cgi?id=66635&action=review
------- Additional Comments from Eric Carlson <eric.carlson at apple.com>
> + updatePlayState() is then refactored to take into account the
> + situation where the backend is already in the correct state but
> + WebCore is not, so that we update thee playback progress timer
Typo - "thee"
>
> +void HTMLMediaElement::mediaPlayerPlaybackStateChanged(MediaPlayer*)
> +{
> + beginProcessingMediaPlayerCallback();
> + if (m_player) {
> + if (m_player->paused())
> + pauseInternal();
> + else
> + playInternal();
> + }
> + endProcessingMediaPlayerCallback();
> +}
> +
Might as well return early if m_player is NULL.
> + // Set rate before calling play in case the rate was set before
the media engine wasn't setup.
Old typo you might as well fix, "wasn't" should be "was".
> Tried to keep the logic of updatePlayState() in the refactor, but wondering
about if (playerPaused &&
> couldPlayIfEnoughData()), should this check be moved out of the
play/not-playing block? Or perhaps be
> done like this?
>
> if (!playerPaused)
> m_player->pause();
>
> if (couldPlayIfEnoughData())
> m_player->prepareToPlay();
Good idea, this seems much clearer.
Thanks!
r=me
More information about the webkit-reviews
mailing list