- From: Bryce Johnson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 14 Aug 2023 15:45:47 +0000
- To: public-device-apis-log@w3.org
Thanks for your thoughtful response 🙇 Yes, I do think a catch-all source would be valuable. The primary uses we have at Slack for this feature are: - detecting when a device is not capable of a fully-featured experience, so that we can alert the user and/or gracefully degrade. If thermal and/or power-related throttling is happening, we almost always observe noticeable differences in a/v quality, as well as Slack's responsiveness. In this case, distinguishing between compute pressure and thermal/power-related pressure is not as important as detecting the system's overall capabilities. - diagnosing the source of problems based on user reports or support requests(after the fact). If we're able to identify that a user's device is the source of the problem based on a catch-all value (rather an a performance problem with Slack or Huddles), we're not going to spend as much time investigating, but rather provide helpful troubleshooting tips or information. So a catch-all value that flags that the system's capabilities were limited would help us make that decision quickly. In this case, distinguishing between thermal/power related throttling and CPU pressure would be helpful in providing the user more targeted help. But a catch-all source would still be an improvement if in fact compute pressure does not capture thermal or power-related throttling. -- GitHub Notification of comment by brycepj Please view or discuss this issue at https://github.com/w3c/compute-pressure/issues/228#issuecomment-1677585952 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 14 August 2023 15:45:49 UTC