11 ms·

> How is that ok? Probably because a browser like FF has the goal to load and display arbitrary dynamic content in realtime like a reddit infinite scroll with

> How is that ok? Probably because a browser like FF has the goal to load and display arbitrary dynamic content in realtime like a reddit infinite scroll with various 4k videos and ad bullshit, whereas the game has the goal to render a known, tested number of pre-downloaded assets in realtime. Also on shitty pages the goal is different-- load a bunch of arbitrary adware programs and content that the user doesn't want, and only after that display the thing they want to read. Also, you can click a link somewhere in your scrolling that opens a new, shitty page where you repeat the same crazy number of net connections, parsing ad bullshit, and incidentally rendering the text that the user wants to read. If you want to compare fairly, imaging a game character entering a cave and immediately switching to a different character like Spiderman and inheriting all the physics and stuff from that newly loaded game. At that point the bulk of your gameplay is going to be loading new assets and you're back to the same responsiveness problems of the shitty web. Edit: clarification

anthk 7y ago
>whereas the game has the goal to render a known, tested number of pre-downloaded assets in realtime. Say hello to shaders.
TeMPOraL 7y ago
Browsers are fine. It's the websites that are slow. It's not the fault of Firefox that Reddit's new UI is pathetically slow. It's the Reddit's implementation of their UI itself which is total garbage. And given that people do write fast, complex, real-time games in JavaScript for the browser, gamedev absolutely becomes a valid reference point for the possible performance of any individual page.
- qqii 7y ago
  Hmm, that leads be to an interesting counter idea. Why should Firefox or any other dynamic software have the ability to be slow for what it archives? If compilers should be fast, Web engines should be equally as fast. The Web should have never been designed such that a slow website (relative to the task) could be achieved. In the same way that you can only express memory safe code in rust and type safe code in haskell why not being only able to express "fast for what is interactive"?
  - zbentley 7y ago
    > The Web should have never been designed such that a slow website (relative to the task) could be achieved That's already the case, your orders of magnitude are just off. Long-running AJAX or page loads are timed out at a pretty consistent point across browsers. Half-open/closed TCP connections are timed out at a pretty consistent point across operating systems. Busy-looping JS gets you a "page is not responding" block in a similar amount of time; same for nonresponsive native applications on many operating systems. Their definition of "slow" or "stuck" just tends to be "tens of seconds or minutes", not the threshold of perceived responsiveness you want in a website. Also, your parenthetical is a pretty tall-née-impossible order: > a slow website (relative to the task) How could the "task" be classified? Do you mean "task" as in "clicking a button and having a DOM update"? Or as in "this is a TODO application so it should have responsiveness threshold X"?
nearbuy 7y ago
I'm both a web developer and a game developer, and this comparison doesn't ring true at all. Games usually have tons of arbitrary dynamic content to display in realtime. Minecraft will load about 9 million blocks around your character plus handle mobs, pathfinding, lighting, etc. Reddit infinite scroll loads a sequence of text, images, and videos. Multiplayer games have such tight latency and bandwidth targets that game developers routinely do optimizations web developers wouldn't even consider. As a web developer, sending an 8 KB JSON response is no problem. That's nice and light. In a networked action game, that's absurd. First, (hypothetical network programmer talking here) we're going to use UDP and write our own network layer on top of it to provide reliability and ordering for packets when we need it. We're going to define a compact binary format. Your character's position takes 96 bits in memory (float x, y, z); we'll start by reducing that to 18 bits per component, and we'll drop the z if you haven't jumped. Then we'll delta compress them vs the previous frame. Etc. Really, what's happening is things are getting optimized as much as they need to be. If your game is running at 10 fps, it's going to get optimized. When it's hitting 60+ fps on all target platforms, developers stop optimizing, even if it could potentially be faster. Same for Reddit; it's fast enough for most users.
- theandrewbailey 7y ago
  > As a web developer, sending an 8 KB JSON response is no problem. That's nice and light. In a networked action game, that's absurd. It depends on what that 8 KB is doing. If that 8 KB is a chat message, that's way too big. On the other hand, I've never seen an 8 KB game patch.
  - nearbuy 7y ago
    This doesn't really relate to my point. The blog post asked why is it that we can handle games (fancy 3D simulations, sometimes with hundreds of players and millions of objects) at a smooth 60 fps but not scrolling a web page. The parent comment suggested that it's easier to render games smoothly because you know the content in advance. I'm suggesting that software gets optimized (by necessity) until it works well enough. If some website had to display a million elements, the devs would either optimize it until it could do so, or the project would get scrapped. When I talk about sending 8 KB in a "networked action game", I'm referring to the update packets sent to and from clients in something like Fortnite or Counter-Strike, not a game patch. I'm not trying to make a competition for who uses the least bandwidth (which a 60 GB game would lose just on the initial download). I'm trying to illustrate that games don't run faster than some website because it's inherently easier to make games run fast, but rather that developers, by necessity, optimize games until they run fast (or in this example, until they reduce network lag enough). I'm not sure why a chat app would tack on something like 7.5 KB of overhead on a chat message, but I wouldn't be surprised if there's a chat app out there that does so. Users won't notice the extra couple milliseconds (especially so because they don't know exactly when the other person hit send). A 3 character Discord message is close to 1 KB including the headers. The same message over UDP in a game might be under 20 bytes, including the UDP header (games could also use TCP for chat - text chat isn't going to strain anything). So I'd say the overhead of a Discord message is still an order of magnitude or two bigger than it could be. Which is perfectly fine; we can afford 1 KB of overhead on a modern connection. It's optimized as much as it needs to be.

anthk 7y ago

>whereas the game has the goal to render a known, tested number of pre-downloaded assets in realtime. Say hello to shaders.

TeMPOraL 7y ago

Browsers are fine. It's the websites that are slow. It's not the fault of Firefox that Reddit's new UI is pathetically slow. It's the Reddit's implementation of their UI itself which is total garbage. And given that people do write fast, complex, real-time games in JavaScript for the browser, gamedev absolutely becomes a valid reference point for the possible performance of any individual page.

qqii 7y ago
Hmm, that leads be to an interesting counter idea. Why should Firefox or any other dynamic software have the ability to be slow for what it archives? If compilers should be fast, Web engines should be equally as fast. The Web should have never been designed such that a slow website (relative to the task) could be achieved. In the same way that you can only express memory safe code in rust and type safe code in haskell why not being only able to express "fast for what is interactive"?
- zbentley 7y ago
  > The Web should have never been designed such that a slow website (relative to the task) could be achieved That's already the case, your orders of magnitude are just off. Long-running AJAX or page loads are timed out at a pretty consistent point across browsers. Half-open/closed TCP connections are timed out at a pretty consistent point across operating systems. Busy-looping JS gets you a "page is not responding" block in a similar amount of time; same for nonresponsive native applications on many operating systems. Their definition of "slow" or "stuck" just tends to be "tens of seconds or minutes", not the threshold of perceived responsiveness you want in a website. Also, your parenthetical is a pretty tall-née-impossible order: > a slow website (relative to the task) How could the "task" be classified? Do you mean "task" as in "clicking a button and having a DOM update"? Or as in "this is a TODO application so it should have responsiveness threshold X"?

nearbuy 7y ago

I'm both a web developer and a game developer, and this comparison doesn't ring true at all. Games usually have tons of arbitrary dynamic content to display in realtime. Minecraft will load about 9 million blocks around your character plus handle mobs, pathfinding, lighting, etc. Reddit infinite scroll loads a sequence of text, images, and videos. Multiplayer games have such tight latency and bandwidth targets that game developers routinely do optimizations web developers wouldn't even consider. As a web developer, sending an 8 KB JSON response is no problem. That's nice and light. In a networked action game, that's absurd. First, (hypothetical network programmer talking here) we're going to use UDP and write our own network layer on top of it to provide reliability and ordering for packets when we need it. We're going to define a compact binary format. Your character's position takes 96 bits in memory (float x, y, z); we'll start by reducing that to 18 bits per component, and we'll drop the z if you haven't jumped. Then we'll delta compress them vs the previous frame. Etc. Really, what's happening is things are getting optimized as much as they need to be. If your game is running at 10 fps, it's going to get optimized. When it's hitting 60+ fps on all target platforms, developers stop optimizing, even if it could potentially be faster. Same for Reddit; it's fast enough for most users.

theandrewbailey 7y ago
> As a web developer, sending an 8 KB JSON response is no problem. That's nice and light. In a networked action game, that's absurd. It depends on what that 8 KB is doing. If that 8 KB is a chat message, that's way too big. On the other hand, I've never seen an 8 KB game patch.
- nearbuy 7y ago
  This doesn't really relate to my point. The blog post asked why is it that we can handle games (fancy 3D simulations, sometimes with hundreds of players and millions of objects) at a smooth 60 fps but not scrolling a web page. The parent comment suggested that it's easier to render games smoothly because you know the content in advance. I'm suggesting that software gets optimized (by necessity) until it works well enough. If some website had to display a million elements, the devs would either optimize it until it could do so, or the project would get scrapped. When I talk about sending 8 KB in a "networked action game", I'm referring to the update packets sent to and from clients in something like Fortnite or Counter-Strike, not a game patch. I'm not trying to make a competition for who uses the least bandwidth (which a 60 GB game would lose just on the initial download). I'm trying to illustrate that games don't run faster than some website because it's inherently easier to make games run fast, but rather that developers, by necessity, optimize games until they run fast (or in this example, until they reduce network lag enough). I'm not sure why a chat app would tack on something like 7.5 KB of overhead on a chat message, but I wouldn't be surprised if there's a chat app out there that does so. Users won't notice the extra couple milliseconds (especially so because they don't know exactly when the other person hit send). A 3 character Discord message is close to 1 KB including the headers. The same message over UDP in a game might be under 20 bytes, including the UDP header (games could also use TCP for chat - text chat isn't going to strain anything). So I'd say the overhead of a Discord message is still an order of magnitude or two bigger than it could be. Which is perfectly fine; we can afford 1 KB of overhead on a modern connection. It's optimized as much as it needs to be.