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
Right now we're only measure FPS, plus the values from a Chrome trace (time spent "scripting", "rendering", and "painting"). These are better than nothing, but they seem insufficient. In particular, they really only start changing if the app is continuously updating in a stress test scenario (ie, dispatching actions every few milliseconds).
It would be good to start figuring out what other metrics we might want to measure, and how we should try measuring them.
Also, the "average FPS" metric is presumably a bit flawed, because it only shows the changes, not exactly how long we spent at a given FPS rate. If we spent 20 seconds at 60 FPS and 10 seconds at 50 FPS, the average FPS isn't 55, it's ( (60 * 20 + 10 * 50) / 30), or something like that. The current math is passable enough for now, but it'd be nice if we actually used the timestamps from the performance.measure() calls to calculate a more accurate FPS result.
The text was updated successfully, but these errors were encountered:
Right now we're only measure FPS, plus the values from a Chrome trace (time spent "scripting", "rendering", and "painting"). These are better than nothing, but they seem insufficient. In particular, they really only start changing if the app is continuously updating in a stress test scenario (ie, dispatching actions every few milliseconds).
It would be good to start figuring out what other metrics we might want to measure, and how we should try measuring them.
Also, the "average FPS" metric is presumably a bit flawed, because it only shows the changes, not exactly how long we spent at a given FPS rate. If we spent 20 seconds at 60 FPS and 10 seconds at 50 FPS, the average FPS isn't 55, it's
( (60 * 20 + 10 * 50) / 30)
, or something like that. The current math is passable enough for now, but it'd be nice if we actually used the timestamps from theperformance.measure()
calls to calculate a more accurate FPS result.The text was updated successfully, but these errors were encountered: