You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to highlight another possible scenario which I believe can be relevant for this API and would be interested hearing feedback on this.
In Excel Online (although not a video streaming app) we have observed cases where when the CPU/GPU is highly utilized, perhaps due to another processing intensive app running at the same time on the OS, interactivity experience degrades. This would manifest as increased response time to interactions due to expensive React components which needs to render and scroll smoothness related impact due to expensive rendering of grid content on the main thread.
We are looking into providing an adaptive experience to the user based on external factors beyond the app control. For example, rendering simpler grid content while there is high CPU pressure and then render complete content when there is more idle time is something we are considering.
Another example is providing simple skeleton content to the immediate interaction on the same animation frame and schedule a full response to a later time when we know CPU pressure is relatively high. This way, the user will not experience prolong UI blocking periods (over 100ms) without any visual response.
From reading the proposal it feels like the main scenario it tries to address is video/gaming related aspects but I think it may also be possible to utilize it for other cases.
The text was updated successfully, but these errors were encountered:
@nhelfman I somehow missed this issue you filed. Yes, most certainly, we also intent so work for cases like the one you described and it would be great to get that integrated in the spec/README.md.
There is definitely things to still consider here, as whether our frequency is high enough and future support for GPU pressure. Let's keep it open for now.
Following up of TPAC 2023 discussion.
I would like to highlight another possible scenario which I believe can be relevant for this API and would be interested hearing feedback on this.
In Excel Online (although not a video streaming app) we have observed cases where when the CPU/GPU is highly utilized, perhaps due to another processing intensive app running at the same time on the OS, interactivity experience degrades. This would manifest as increased response time to interactions due to expensive React components which needs to render and scroll smoothness related impact due to expensive rendering of grid content on the main thread.
We are looking into providing an adaptive experience to the user based on external factors beyond the app control. For example, rendering simpler grid content while there is high CPU pressure and then render complete content when there is more idle time is something we are considering.
Another example is providing simple skeleton content to the immediate interaction on the same animation frame and schedule a full response to a later time when we know CPU pressure is relatively high. This way, the user will not experience prolong UI blocking periods (over 100ms) without any visual response.
From reading the proposal it feels like the main scenario it tries to address is video/gaming related aspects but I think it may also be possible to utilize it for other cases.
The text was updated successfully, but these errors were encountered: