4 ms·

A lot of the speed games get is by having bad load times when starting up. Keeping startup really fast and all interactions really fast is more challenging tha

A lot of the speed games get is by having bad load times when starting up. Keeping startup really fast and all interactions really fast is more challenging than it seems. This is not the whole story, but one example of the differences in perception.

wtetzner 4y ago
But games are loading enormous textures, meshes, maps, etc. UIs don’t need any of that.
- astrange 4y ago
  A mesh may have a lot of triangles, but it's still a single object you can memory map. UIs are typically a bunch of heap allocations and pointer jumping all created at runtime. That can be surprisingly inefficient.
  - 8n4vidtmkvmk 4y ago
    then make it efficient. overallocate a block of memory and use it for all your tiny ui elements. its exactly what games do.
    - astrange 4y ago
      Arena allocators only work when everything has the same lifetime. There are game-like UI libraries (https://github.com/ocornut/imgui https://github.com/ocornut/imgui) but to use them you have to write your program like you're a gamedev and Conway's Law usually fights that.
ehnto 4y ago
Streaming in hundreds of assets as you walk around an open world does surely take a different pipeline, but as a show of computing competence it is staggering. You should see how fast some of these truly massive games load nowadays. The fact that the notepad app takes forever to load when all it needs to load is the UI is just a sad state of affairs.
thomastjeffery 4y ago
Most bad loading times fall into 2 categories 1. Avoidable: The main one here is shader caching. Shaders could be precompiled for every supported card/driver, but that's more work than anyone is willing to do. Even so, some games (like Rust) have an excessive amount of shaders, which adds a lot of extra waiting time. 2. Unavoidable: The main one here is textures. If you want it to be quickly accessible in VRAM, then it's going to be uncompressed, which means either having some very large files to copy over, or having some semi-large files to decompress. You can save quite a bit of time by micromanaging the texture resolution of each asset to be just high enough. Apart from textures, you have vertex data and other assets; all of which have basically the same considerations. When it comes to regular software, most UI designs don't have big assets. They aren't loading billions of triangles or thousands of textures. This means there really isn't much need for long startup times.

wtetzner 4y ago

But games are loading enormous textures, meshes, maps, etc. UIs don’t need any of that.

astrange 4y ago
A mesh may have a lot of triangles, but it's still a single object you can memory map. UIs are typically a bunch of heap allocations and pointer jumping all created at runtime. That can be surprisingly inefficient.
- 8n4vidtmkvmk 4y ago
  then make it efficient. overallocate a block of memory and use it for all your tiny ui elements. its exactly what games do.
  - astrange 4y ago
    Arena allocators only work when everything has the same lifetime. There are game-like UI libraries (https://github.com/ocornut/imgui https://github.com/ocornut/imgui) but to use them you have to write your program like you're a gamedev and Conway's Law usually fights that.

ehnto 4y ago

Streaming in hundreds of assets as you walk around an open world does surely take a different pipeline, but as a show of computing competence it is staggering. You should see how fast some of these truly massive games load nowadays. The fact that the notepad app takes forever to load when all it needs to load is the UI is just a sad state of affairs.

thomastjeffery 4y ago

Most bad loading times fall into 2 categories 1. Avoidable: The main one here is shader caching. Shaders could be precompiled for every supported card/driver, but that's more work than anyone is willing to do. Even so, some games (like Rust) have an excessive amount of shaders, which adds a lot of extra waiting time. 2. Unavoidable: The main one here is textures. If you want it to be quickly accessible in VRAM, then it's going to be uncompressed, which means either having some very large files to copy over, or having some semi-large files to decompress. You can save quite a bit of time by micromanaging the texture resolution of each asset to be just high enough. Apart from textures, you have vertex data and other assets; all of which have basically the same considerations. When it comes to regular software, most UI designs don't have big assets. They aren't loading billions of triangles or thousands of textures. This means there really isn't much need for long startup times.