3 ms·

Game UI in the DOM. When you need to update something 60 times a second all performance matters.

by Kiro 4y ago

davedx 4y ago
I’ve built web games. Don’t bother trying to render the DOM 60 fps, it’s unnecessary. Render your actual game with canvas and use regular react for your UI. If for some reason your UI needs to render that often, move it into canvas too.
- Kiro 4y ago
  Pretty strange to call it unnecessary when it's magnitudes easier to build the UI in in the DOM than re-implementing it in canvas. Yes, the UI needs to update that often because every game tick there are a lot of numbers being updated (think colony simulator). It works so not sure what the problem is or why I would change it.
  - davedx 4y ago
    If you're talking about things displaying numbers in real-time, it's not magnitudes easier to do it in the DOM, that's a gross exaggeration. If you're talking complex form controls then maybe, but I wonder what kind of game would have complex form controls that also need to be rendered at 60 fps. In my experience anything that needs to be animated should be done with canvas, otherwise at some point you're either going to hit performance walls or end up fighting the DOM.
    - Kiro 4y ago
      I'm not talking about displaying just numbers. Bars, numbers, animated things with shadows, filters and tweens. All trivial to do in the DOM with CSS while making it from scratch in a canvas (not using any engine) would be extremely cumbersome. And even if it's just text that's explicitly something you shouldn't do in canvas if you care about performance: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/... > Avoid text rendering whenever possible. So then I'm forced to create rendered font glyphs and use tooling for the texture atlas when drawing characters. Again, much easier just overlaying an element and do it in the DOM.
onion2k 4y ago
Every website, web app, browser-based game, etc should be nailing 60fps. That's the baseline minimum framerate for web software in my opinion. However... window.requestAnimationFrame in browsers (which is what games will be using to manage their main loop in the background) matches the refresh rate of the display. If you're looking at a game on a a laptop that's 60Hz, but if you're looking at it in a VR display it's probably 90Hz, or on a top end flagship phone it might be 120Hz. Games, even games written in React, manage to do this quite easily so long as the dev doesn't screw it up. You definitely don't need a 'faster state library' to do it well.
- Kiro 4y ago
  Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. Yes, of course you're using RAF for the game loop. Not sure of the relevance of that comment. I just said 60 to simplify things. > Games, even games written in React, manage to do this quite easily That's a really broad and generalising comment. All games are different. My way works but only because I'm using a library that is fast enough. Sure, maybe I should batch update calls and do all sorts of optimization techniques on my end, but why would I when I can just do it like this and focus on the core gameplay instead? Are you saying that libraries should not be performant in order to punish lazy developers like me?
  - onion2k 4y ago
    Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. It is though. We've all used web apps where something doesn't nail 60fps and it's so jarring. I used one yesterday where typing in a textbox was laggy. WTF is the dev who made it doing when a textbox is slow?! This is the sort of problem that developers face and, if they're not great at their job, they reach for a library that claims to be faster rather than looking at their code to work out why it's slow. The impact of marketing something as "magically better perf by using this super special library!" is that developers stop trying to make things fast enough themselves. Worse, some people start believing all web apps are slow because the web must be slow by default if you need these clever tricks that only libraries can provide to be fast. It's nonsense. Browsers are pretty damn fast and if you encounter a webapp that's slow it's almost guaranteed to be the fault of the developers who made it and not the libraries it's built on. There is no library that a bad dev can't make slow software with.
capableweb 4y ago
> Game UI in the DOM. When you need to update something 60 times a second all performance matters. What sort of Game UI has to be updated 60 times per second and would be implemented with something like React? In-game UI like healthbars would be implemented in canvas/webgl or whatever you use for the game itself. The UI around the game can be implemented as DOM and overlayed, but rarely have to be updated 60 times/second

Game UI in the DOM. When you need to update something 60 times a second all performance matters.

by Kiro 4y ago

Game UI in the DOM. When you need to update something 60 times a second all performance matters.

I’ve built web games. Don’t bother trying to render the DOM 60 fps, it’s unnecessary. Render your actual game with canvas and use regular react for your UI. If for some reason your UI needs to render that often, move it into canvas too.

Kiro 4y ago
Pretty strange to call it unnecessary when it's magnitudes easier to build the UI in in the DOM than re-implementing it in canvas. Yes, the UI needs to update that often because every game tick there are a lot of numbers being updated (think colony simulator). It works so not sure what the problem is or why I would change it.
- davedx 4y ago
  If you're talking about things displaying numbers in real-time, it's not magnitudes easier to do it in the DOM, that's a gross exaggeration. If you're talking complex form controls then maybe, but I wonder what kind of game would have complex form controls that also need to be rendered at 60 fps. In my experience anything that needs to be animated should be done with canvas, otherwise at some point you're either going to hit performance walls or end up fighting the DOM.
  - Kiro 4y ago
    I'm not talking about displaying just numbers. Bars, numbers, animated things with shadows, filters and tweens. All trivial to do in the DOM with CSS while making it from scratch in a canvas (not using any engine) would be extremely cumbersome. And even if it's just text that's explicitly something you shouldn't do in canvas if you care about performance: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/... > Avoid text rendering whenever possible. So then I'm forced to create rendered font glyphs and use tooling for the texture atlas when drawing characters. Again, much easier just overlaying an element and do it in the DOM.

onion2k 4y ago

Every website, web app, browser-based game, etc should be nailing 60fps. That's the baseline minimum framerate for web software in my opinion. However... window.requestAnimationFrame in browsers (which is what games will be using to manage their main loop in the background) matches the refresh rate of the display. If you're looking at a game on a a laptop that's 60Hz, but if you're looking at it in a VR display it's probably 90Hz, or on a top end flagship phone it might be 120Hz. Games, even games written in React, manage to do this quite easily so long as the dev doesn't screw it up. You definitely don't need a 'faster state library' to do it well.

Kiro 4y ago
Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. Yes, of course you're using RAF for the game loop. Not sure of the relevance of that comment. I just said 60 to simplify things. > Games, even games written in React, manage to do this quite easily That's a really broad and generalising comment. All games are different. My way works but only because I'm using a library that is fast enough. Sure, maybe I should batch update calls and do all sorts of optimization techniques on my end, but why would I when I can just do it like this and focus on the core gameplay instead? Are you saying that libraries should not be performant in order to punish lazy developers like me?
- onion2k 4y ago
  Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. It is though. We've all used web apps where something doesn't nail 60fps and it's so jarring. I used one yesterday where typing in a textbox was laggy. WTF is the dev who made it doing when a textbox is slow?! This is the sort of problem that developers face and, if they're not great at their job, they reach for a library that claims to be faster rather than looking at their code to work out why it's slow. The impact of marketing something as "magically better perf by using this super special library!" is that developers stop trying to make things fast enough themselves. Worse, some people start believing all web apps are slow because the web must be slow by default if you need these clever tricks that only libraries can provide to be fast. It's nonsense. Browsers are pretty damn fast and if you encounter a webapp that's slow it's almost guaranteed to be the fault of the developers who made it and not the libraries it's built on. There is no library that a bad dev can't make slow software with.

capableweb 4y ago

> Game UI in the DOM. When you need to update something 60 times a second all performance matters. What sort of Game UI has to be updated 60 times per second and would be implemented with something like React? In-game UI like healthbars would be implemented in canvas/webgl or whatever you use for the game itself. The UI around the game can be implemented as DOM and overlayed, but rarely have to be updated 60 times/second