3 ms·

> et they struggle with rendering websites which comes down to presenting some good looking text. Umm... you're putting the blame on the wrong thing here, dude

> et they struggle with rendering websites which comes down to presenting some good looking text. Umm... you're putting the blame on the wrong thing here, dude. > because some front dev crambed some 'cool' paralax effect onto it, As I said.

Xeamek 3y ago
You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Would you apply the same logic to game optimization? That's it's not the responsibility of game devs, and instead we can shift all the blame to the gpu sdk team?
- Turing_Machine 3y ago
  > You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Not at all. Quite the opposite, in fact. My position is that the browser is fast enough, and that any slowness is exactly the fault of the site devs. You said the browser wasn't fast enough. Previous poster: The reality is that web is fast enough You: No its fuckin not.
  - Xeamek 3y ago
    Fair. I took 'web is fast enough' as in 'current state of web is fast enough'. But if we are still sticking to the actual internals of web browsers, i don't doubt they are quite 'state of the art'. It's just the outcome for the end user sucks
  - troupo 3y ago
    > You said the browser wasn't fast enough. It isn't. Not for what people are trying to make with it. Case in point: https://krausest.github.io/js-framework-benchmark/2023/table_chrome_120.0.6099.62.html https://krausest.github.io/js-framework-benchmark/2023/table... The benchmark creates 1000 rows that look like this: <tr> <td><a onclick={select this row}>random short text</a></td> <td><a onclick={remove this row}><span /></a></td> <td></td> </tr> So, less than a 10k elements in total. The fastest of the fastest attempts to do this takes 36 milliseconds to render. For what is essentially static markup with zero complex logic or complex interactions. In comparison: 1000 actors with complex interaction and behaviour, complex animations and lighting takes 4 milliseconds to render (in total, significanly more than the measley 5-6k static elements on the page): https://youtu.be/kXd0VDZDSks?si=SswSZLNFlRd7adsM&t=586 https://youtu.be/kXd0VDZDSks?si=SswSZLNFlRd7adsM&t=586 (at 9:46) I'm not saying everything should be Unreal Engine. But the web is on the lowest of the lowest end of the spectrum when it comes to performance.
    - Turing_Machine 3y ago
      > 36 milliseconds to render. 36 ms is a very small amount of time (faster than the rod flicker fusion frequency, though not the cones), and 10K elements is far more elements than even a complex web page is likely to have. Can you give me some examples of real-world web pages that have 10K DOM elements on them, or anything like it? Running document.querySelectorAll('*').length on my personal amazon.com home page gives 3163 (obviously this is going to vary somewhat for different people), and amazon.com's front page is pretty damned complex. > I'm not saying everything should be Unreal Engine. I'm saying that almost nothing needs to be Unreal Engine. You are confusing "fast" with "fast enough".
      - austin-cheney 3y ago
        Sure. Check out my personal website. https://prettydiff.com/ https://prettydiff.com/ Just open a bunch of windows and you will get to 10k page elements. The primary window shows the page load time in bold red font. The page load time includes all network calls, all initial script execution, state restoration, and graphical rendering. Total load time should always be around 1 second of which most is visual render. The script execution typically takes about 60ms or so but you can see the complete breakdown in the browser performance tab. The CSS could use a lot of clean up. I pulled all of this code from a browser based OS highly distributed OS I am working on. Also, on that site you can easily check element count in the console using the following custom DOM methods: document.getNodesByType(0).length; // all nodes document.getNodesByType(1).length; // all elements EDIT I just got to 10000 visible elements on the site and everything still loads in about 850ms, give or take 50ms, on my 7 year old desktop. Base load time for a new user on the same machine is about 550ms, so difference in load time is not significant. The real significance is page repaint on a fully loaded page. Drag and drop of any one window is noticeably slower. To reset state execute the following and refresh the page: delete localStorage["gui-state];
      - troupo 3y ago
        > 36 ms is a very small amount of time To render less than 10k objects on a screen given the current state of hardware? It's an eternity. The problem is, these things compound. That is why "my page doesn't have 10k elements", but for some reason Google gave up and now calls "2.4 seconds to render content is fast, actually": https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is, of course more than just DOM being slow). Gven that it takes that much time to render a static page with a number of elements that shouldn't even register by a clock, you run into hundreds of other problems: layout shifts in DOM are extremelyexpensive, avoid them; animations in the DOM are extremely expensive, avoid them; we can't re-render fast enough when the winow is dynamically resized, so there's tearing; we can't update the DOM fast enough because updates are extremely slow, so we fight the DOM and come up with crazier and crazier solutions to touch it as little as possible; and so on and so forth. On the same machine a game engine re-renders the entire world with thousands or millions of objects with complex computations and interactions from scratch in under 10ms. > You are confusing "fast" with "fast enough". I'm not. I'm tired of your "fast enoughs" that cannot reliably render a static web page without consuming more time and about as many resources as a modern video game. And then hear the idiocy of "it's the most advanced rendering and layout engine" or "string parsing is so much slower than DOM operations" and other claims by people who have no idea what they are talking about. Edit: your amazing "fast enough" is known to consume 20% of CPU just to display an animated emoji: https://twitter.com/dmitriid/status/1486364312910368769 https://twitter.com/dmitriid/status/1486364312910368769

Xeamek 3y ago

You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Would you apply the same logic to game optimization? That's it's not the responsibility of game devs, and instead we can shift all the blame to the gpu sdk team?

Turing_Machine 3y ago
> You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Not at all. Quite the opposite, in fact. My position is that the browser is fast enough, and that any slowness is exactly the fault of the site devs. You said the browser wasn't fast enough. Previous poster: The reality is that web is fast enough You: No its fuckin not.
- Xeamek 3y ago
  Fair. I took 'web is fast enough' as in 'current state of web is fast enough'. But if we are still sticking to the actual internals of web browsers, i don't doubt they are quite 'state of the art'. It's just the outcome for the end user sucks
- troupo 3y ago
  > You said the browser wasn't fast enough. It isn't. Not for what people are trying to make with it. Case in point: https://krausest.github.io/js-framework-benchmark/2023/table_chrome_120.0.6099.62.html https://krausest.github.io/js-framework-benchmark/2023/table... The benchmark creates 1000 rows that look like this: <tr> <td><a onclick={select this row}>random short text</a></td> <td><a onclick={remove this row}><span /></a></td> <td></td> </tr> So, less than a 10k elements in total. The fastest of the fastest attempts to do this takes 36 milliseconds to render. For what is essentially static markup with zero complex logic or complex interactions. In comparison: 1000 actors with complex interaction and behaviour, complex animations and lighting takes 4 milliseconds to render (in total, significanly more than the measley 5-6k static elements on the page): https://youtu.be/kXd0VDZDSks?si=SswSZLNFlRd7adsM&t=586 https://youtu.be/kXd0VDZDSks?si=SswSZLNFlRd7adsM&t=586 (at 9:46) I'm not saying everything should be Unreal Engine. But the web is on the lowest of the lowest end of the spectrum when it comes to performance.
  - Turing_Machine 3y ago
    > 36 milliseconds to render. 36 ms is a very small amount of time (faster than the rod flicker fusion frequency, though not the cones), and 10K elements is far more elements than even a complex web page is likely to have. Can you give me some examples of real-world web pages that have 10K DOM elements on them, or anything like it? Running document.querySelectorAll('*').length on my personal amazon.com home page gives 3163 (obviously this is going to vary somewhat for different people), and amazon.com's front page is pretty damned complex. > I'm not saying everything should be Unreal Engine. I'm saying that almost nothing needs to be Unreal Engine. You are confusing "fast" with "fast enough".
    - austin-cheney 3y ago
      Sure. Check out my personal website. https://prettydiff.com/ https://prettydiff.com/ Just open a bunch of windows and you will get to 10k page elements. The primary window shows the page load time in bold red font. The page load time includes all network calls, all initial script execution, state restoration, and graphical rendering. Total load time should always be around 1 second of which most is visual render. The script execution typically takes about 60ms or so but you can see the complete breakdown in the browser performance tab. The CSS could use a lot of clean up. I pulled all of this code from a browser based OS highly distributed OS I am working on. Also, on that site you can easily check element count in the console using the following custom DOM methods: document.getNodesByType(0).length; // all nodes document.getNodesByType(1).length; // all elements EDIT I just got to 10000 visible elements on the site and everything still loads in about 850ms, give or take 50ms, on my 7 year old desktop. Base load time for a new user on the same machine is about 550ms, so difference in load time is not significant. The real significance is page repaint on a fully loaded page. Drag and drop of any one window is noticeably slower. To reset state execute the following and refresh the page: delete localStorage["gui-state];
    - troupo 3y ago
      > 36 ms is a very small amount of time To render less than 10k objects on a screen given the current state of hardware? It's an eternity. The problem is, these things compound. That is why "my page doesn't have 10k elements", but for some reason Google gave up and now calls "2.4 seconds to render content is fast, actually": https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is, of course more than just DOM being slow). Gven that it takes that much time to render a static page with a number of elements that shouldn't even register by a clock, you run into hundreds of other problems: layout shifts in DOM are extremelyexpensive, avoid them; animations in the DOM are extremely expensive, avoid them; we can't re-render fast enough when the winow is dynamically resized, so there's tearing; we can't update the DOM fast enough because updates are extremely slow, so we fight the DOM and come up with crazier and crazier solutions to touch it as little as possible; and so on and so forth. On the same machine a game engine re-renders the entire world with thousands or millions of objects with complex computations and interactions from scratch in under 10ms. > You are confusing "fast" with "fast enough". I'm not. I'm tired of your "fast enoughs" that cannot reliably render a static web page without consuming more time and about as many resources as a modern video game. And then hear the idiocy of "it's the most advanced rendering and layout engine" or "string parsing is so much slower than DOM operations" and other claims by people who have no idea what they are talking about. Edit: your amazing "fast enough" is known to consume 20% of CPU just to display an animated emoji: https://twitter.com/dmitriid/status/1486364312910368769 https://twitter.com/dmitriid/status/1486364312910368769