New issue
Advanced search Search tips

Issue 836816 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Feature



Sign in to add a comment

Page.startScreencast argument everyNthFrame is not useful

Reported by jap...@datablocks.net, Apr 25 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
1. Connect to headless chrome via devtools protocol
2. Call Page.startScreencast({everyNthFrame:2})
3. Load a page which triggers only one frame render per second
4. You only get frames every two seconds...

What is the expected behavior?
Replace everyNthFrame with maximumFramesPerSecond.

What went wrong?
everyNthFrame is just not useful in real world scenarios.

The only reason why you set this to >1 would be to increase performance at the cost of getting fewer frames back. This strategy makes sense assuming a constant and high framerate,  but the framerate is not constant and is entirely dependent on the content/activity of the page. 

Some pages will only cause one frame to render and in these cases you will never receive a frame for the page if everyNthFrame>=2. 

Similarly, if a page updates after a few seconds, but still only generates 1 new frame render, you may not see this frame at all.

Did this work before? No 

Chrome version: 65.0.3325.181  Channel: n/a
OS Version: OS X 10.12.6
Flash Version: 

Please add a maximumFramesPerSecond option to this feature.
 
Labels: Needs-Triage-M65
Labels: -Type-Bug M-68 Triaged-ET FoundIn-68 Target-68 Type-Feature
Status: Untriaged (was: Unconfirmed)
The issue seems to be a feature request as per comment #0 as the reporter is requesting for adding a maximumFramesPerSecond option to this feature. Hence, marking it as untriaged for further inputs from dev team.

Thanks...!!


Comment 3 by alph@chromium.org, May 12 2018

Owner: dgozman@chromium.org
Status: Assigned (was: Untriaged)
Status: WontFix (was: Assigned)
Thanks for filing this issue!

everyNthFrame will be removed eventually, we replaced it with backpressure mechanism. Client should send screencastFrameAck command back, and we will only keep some small amount of frames inflight. The slower the client acks, the less frames it gets. Does this work for you?
So basically screencastFrameAck would indicate that I am ready to receive another frame. That make sense to me!

Thanks!

Sign in to add a comment