- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 May 2022 22:41:38 +0000
- To: public-webrtc-logs@w3.org
@jan-ivar, I don't understand your methodology for measuring performance. * How am I going to extrapolate the numbers from your machine or mine, to the expected numbers for users on lower-end hardware, or with busy CPUs? * What are you measuring? Time to the resolution of the Promise returned by cropTo()? The [CL](https://chromium-review.googlesource.com/c/chromium/src/+/3497676) for that is still pending submission. I have not had the time to finalize the tests because I've been busy debating specs. Without that CL, you're not measuring what you think. You're just measuring IPCs between the render process and the browser process. * Even after that specific CL is submitted, this fiddle will measure when the last pre-crop frame was produced, not when the new post-crop frame is produced - which is the more interesting number. Because... * Any measurement that does not result in a latency that falls below half the rate at which frames are drawn to the screen, is suspect. Because frames are captured when drawn. (Given our current implementation.) > The fiddles also show some bugs in Chrome you may wish to iron out (the blue outline is way off) Thanks for pointing that out. We'll definitely look into it. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1132272361 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 May 2022 22:41:39 UTC