Closed Bug 1155320 Opened 10 years ago Closed 9 years ago

Throttle Shumway player event loop when we detect render throttling

Categories

(Firefox Graveyard :: Shumway, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: cpeterson, Assigned: mbx)

References

Details

No description provided.
I thought we had discussed using an explicit signal like Page Visibility?
(In reply to Seth Fowler [:seth] from comment #1) > I thought we had discussed using an explicit signal like Page Visibility? We did, but mbx pointed out that we could fairly easily detect the rAF throttling and tie our own throttling to that. Seems like it's the simpler approach, arguably even the better one, and doesn't require standardization work. The Page Visibility-like signal has the upside of being really easy to use in JS, so might benefit more content more easily if it is adopted. We could inform work on that with our experience here, though.
(In reply to Till Schneidereit [:till] from comment #2) > We did, but mbx pointed out that we could fairly easily detect the rAF > throttling and tie our own throttling to that. Seems like it's the simpler > approach, arguably even the better one, It could be. The one downside I see is that it might start being more difficult as the platform gets smarter. For example, imagine if we implementing more granular rAF throttling based on remaining battery life. Of course, this is all theoretical stuff! =) Should work just fine today. I'm going to investigate the Page Visibility approach anyway, because I think it can potentially benefit a lot of content beyond Shumway. There's certainly no downside to implementing this bug's approach in Shumway and then reevaluating when/if we can use Page Visibility for this purpose.
(In reply to Seth Fowler [:seth] from comment #3) > It could be. The one downside I see is that it might start being more > difficult as the platform gets smarter. For example, imagine if we > implementing more granular rAF throttling based on remaining battery life. > Of course, this is all theoretical stuff! =) Should work just fine today. Hmm, yes. I guess that might well mean that we don't want to teach people about this approach, because it'd make it so much harder to get smarter in the platform in the future: could we do things like you suggest if content use rAF throttling as a signal for being invisible? > I'm going to investigate the Page Visibility approach anyway, because I > think it can potentially benefit a lot of content beyond Shumway. There's > certainly no downside to implementing this bug's approach in Shumway and > then reevaluating when/if we can use Page Visibility for this purpose. That much is certainly true, yes. It seems easy enough to switch between the two on our end.
(In reply to Till Schneidereit [:till] from comment #4) > Hmm, yes. I guess that might well mean that we don't want to teach people > about this approach, because it'd make it so much harder to get smarter in > the platform in the future: could we do things like you suggest if content > use rAF throttling as a signal for being invisible? We might end up needing heuristics to work around content's heuristics, which is kinda scary. =) Seems like it'd be in our interest to give people a more explicit API before we end up in that situation.
Michael, Till says you have a WIP patch to throttle the player event loop. Can you rebase your patch for landing?
Assignee: nobody → mbebenita
Flags: needinfo?(mbebenita)
Till wants a pref to be able to disable event loop throttling so we can test unthrottled performance of off-screen SWFs. Do we need a similar pref to disable render throttling?
Product: Firefox → Firefox Graveyard
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Clearing obsolete needinfo
Flags: needinfo?(mbebenita)
You need to log in before you can comment on or make changes to this bug.