Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ooh interesting. What is your machine and browser? On chrome with my m1 macbook it takes less than 1ms to compute and render each frame, but I am noticing some things I can optimize from the performance flame graph! I will say, I find chrome to be way more efficient for ctx2d things than firefox or safari.
 help



Chrome on Linux suffers from this too. The issues are standard for all naive immediate GUI libs:

- constant repainting (while literally nothing changes) -> constant CPU load

- some libs can skip repaints but have no concept of damage area

- bad handling of high-dpi (which also can change dynamically)

- constant repainting behaves even worse on laptops which announce 180 Hz refresh interval, which means that it drains the battery 3 times faster than 60 Hz


> - constant repainting (while literally nothing changes) -> constant CPU load

This doesn't explain a 100% CPU usage since requestAnimationFrame is vsync-throttled and rendering such a simple scene will do the per-frame work in a fraction of a frame duration.

And FWIW I cannot reproduce the issue in both demos (in Chrome on macOS). The sokol demo has a per-frame load of about 0.3ms per 8.333ms frame, and the demo hosted on vercel.app about 0.7ms, both pretty much within expecations.


Firefox on Linux.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: