4 ms·
I don't understand. Was it not possible to decouple the UI/events thread from whatever performance intensive things your app might be doing? We've had HTML5 gam
by akersten 5y ago
I don't understand. Was it not possible to decouple the UI/events thread from whatever performance intensive things your app might be doing? We've had HTML5 games for a long time now and they've figured this out.
Is this just a batteries-included way of forcing the thread separation between logic and drawing?
- bob1029 5y agoThere is a "best practices" way to do canvas drawing which involves requestAnimationFrame inside a draw loop function, but there is no way to put UI events and drawing on different logical threads. The best you can do is make sure your draw function does not do non-drawing things.
- modeless 5y agoIn theory it's possible to break up long running operations into small chunks and schedule them between frames. In practice it's a lot of work and the only people who bother are game developers. Most app developers just don't care at all if they have a 100ms pause. If you point it out to them they'll just tell you that 100ms is nothing and nobody will notice, they have better things to do than fix 100ms pauses. And so all apps are janky. > Is this just a batteries-included way of forcing the thread separation between logic and drawing? It's not possible to draw canvases on multiple threads without this. So it's about enabling, not just forcing. Enabling multiple threads is a big deal because every device has multiple cores these days and the web is mostly using only one.
- rictic 5y agoExpanding on this, if you do all the work on the main thread, you're implementing a cooperative multitasking system, with all of the problems that entails. It's surprisingly hard to break up potentially long tasks in an ergonomic way without losing a ton of performance, tracking down a long tail of tasks that block rendering, or both. Having multiple threads of execution is so much better.