workloadSimulation : irrelevant framerate by default with "animate" and "postMessage" checked

[tlecoz]

When you click on the link from the Webgpu-sample page , if you enable the "animate" checkbox then the "postMessage" checkbox , the framerate is incorrect. It shows only 2 and should be much higher.

It seems to be an initialisation problem because if the page start with this config directly, it works as expected.
It also works as expected if you modify the size of the canvas (or if you change any other property I think - but I only tryed to change the size of the canvas - )

Please look at the video to get a better understanding

chrome_kav2fokfMD.mp4

OS : Windows 11
Browser : chrome 131.0.6778

about-gpu-2024-12-13T03-33-59-239Z.txt

[kainino0x]

cc @jdarpinian in case you're interested

[jdarpinian]

Thanks for the ping! I can't reproduce the behavior seen in the video here locally. The behavior I get is the FPS counter showing 1400+ FPS while the actual rendering visually looks more like an inconsistent ~10 FPS, indicating that the compositor is dropping a lot more frames than it should. I don't think either behavior represents a bug in the workload simulator. If anything, it would be bugs in Chrome's compositor.

The behavior I would expect ideally for a postMessage rendering loop would be uncapped rendering frame rate, with screen updates at the monitor's frame rate. But websites really shouldn't use postMessage for rendering loops so I'm sure fixing any behavior like this would be low priority.

[tlecoz]

Why the fastest way to update something should not be used ? Le ven. 3 janv. 2025, 08:07, James Darpinian ***@***.***> a écrit :

…

Thanks for the ping! I can't reproduce the behavior seen in the video here locally. The behavior I get is the FPS counter showing 1400+ FPS while the actual rendering visually looks more like an inconsistent ~10 FPS, indicating that the compositor is dropping a lot more frames than it should. I don't think either behavior represents a bug in the workload simulator. If anything, it would be bugs in Chrome's compositor. The behavior I would expect ideally for a postMessage rendering loop would be uncapped rendering frame rate, with screen updates at the monitor's frame rate. But websites really shouldn't use postMessage for rendering loops so I'm sure fixing any behavior like this would be low priority. — Reply to this email directly, view it on GitHub <#483 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCTMPHAMFYNZOAW7JDKRL2IYZL5AVCNFSM6AAAAABTRECSV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRYG43TMNRUGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jdarpinian]

Rendering faster than the screen can show updates wastes power without any benefit.

[tlecoz]

Yes, for sure 🙂 I was thinking about a very spécial case. Forget about it. Thank you for your message, your time and all the great work on webgpu Le ven. 3 janv. 2025, 09:21, James Darpinian ***@***.***> a écrit :

…

Rendering faster than the screen can show updates wastes power without any benefit. — Reply to this email directly, view it on GitHub <#483 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCTMJ7SB6AZ7RJ5RB2UML2IZCAHAVCNFSM6AAAAABTRECSV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRYHAZTSNZUG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>