Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Styling of controls in demo shouldn't be modified when not visible #749

Closed
jbauman2 opened this issue Apr 5, 2017 · 3 comments
Closed
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@jbauman2
Copy link

jbauman2 commented Apr 5, 2017

See also https://bugs.chromium.org/p/chromium/issues/detail?id=704673#c1

Chrome Canary on Windows 10

  • What did you do?
    Loaded shaka player, started a video, and turned on "Paint Flashing" from the "Rendering" tab of Chrome's dev tools

    • What content did you load?

      • If standard demo asset, which one?
        Sintel 4k (WebM only)
    • How did you interact with the content, if at all?
      No, just waited for the controls to disappear

  • What did you expect to happen?
    Once the controls hide, only the entire video should flash green.

  • What actually happened?
    On alternating frames, either the entire video flashes green or the area where the seekBar is flashes green.

These unnecessary updates to the seekbar take CPU (for styling and layout) and GPU time (to draw frames that don't actually change anything. The demo app should avoid updating properties and style of the seekBar and other CSS elements when they're supposed to be hidden.

I think all calls to ShakaControls.prototype.updateTimeAndSeekRange_ should be deferred until the controls are made visible. Style and property updates that seem problematic are seekBar_.min, seekBar_.max, seekBar_.value, seekBar_.style.background, and currentTime_.textContent .

@joeyparrish joeyparrish added the type: bug Something isn't working correctly label Apr 5, 2017
@joeyparrish
Copy link
Member

As I understand it, this also means the demo app is consuming more battery than it should on mobile devices and laptops. Is that correct?

@joeyparrish joeyparrish added this to the v2.1.0 milestone Apr 5, 2017
@jbauman2
Copy link
Author

jbauman2 commented Apr 5, 2017 via email

@joeyparrish joeyparrish self-assigned this Apr 5, 2017
@joeyparrish
Copy link
Member

@jbauman2 The next nightly build should be much improved: https://nightly-dot-shaka-player-demo.appspot.com/ Thanks!

joeyparrish added a commit that referenced this issue Apr 6, 2017
This makes the demo app run more efficiently and may save battery on
devices.

Closes #749

Change-Id: I735cde417c04cf8c2e7d93944d1c80a0298a7111
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

3 participants