/townhall/ - Townhall

>>11094  3D video games use hardware optimization specifically designed for this purpose, and the "hitches" and "loading" are all still there - they just take place before the calculations are even run during the extended time when you load into an area and it gets put into RAM.  Compare this with the generic 2D button, which if it isn't already loaded into memory, has to be read from disk, and reading from disk always takes longer.  The 2D button probably also doesn't utilize special dedicated hardware to place it.

>>11094
It's a good question, but a hard one to answer.

I think it's true a lot of software could be better optimized for speed.  But there are various costs, the first is simply time from developers who know enough about the nuts and bolts of systems to do the optimization.  Optimized code can be less flexible, making future updates or changes to software harder, although that's not an absolute rule.  Optimization also becomes more complicated when code targets a wide range of hardware or platforms.

>>11095
>extended time when you load into an area and it gets put into RAM
Yes, exactly so.

And yes having specialized hardware for a particular problem is a huge speed-up.  Things other than games can access the GPU, true.  I use a video conversion program, and if I specially compile it, it will run through the GPU.  But even there, the GPU can only encode some codex(es).  When it works it does encoding ~100x faster.

>>11096
Operating systems are also juggling processes.  Operating systems make judgements about which processes need responsiveness and which don't as much.  The goal is to pull the pieces of software that process keyboard/mouse input into focus quickly enough after the user interacts so the user doesn't notice the processor is switching between tasks.  Sometimes background tasks don't give up focus quickly enough and a delay is noticeable.

Different sorts of calculations.
It's not so clear cut as you describe. In some cases, 2D can be more complex
Especially given many engines are decades old.

This person may know nothing at all about computers. I don't know anything about computers but I know enough to disregard anything that they say on the topic.

Visual rendering happens almost entirely on the GPU, as stated above. Less stated is that 3D rendering is almost entirely the same calculation. Rendering is fairly unique in that it involves thousands of fairly trivial calculations that don't impact each other so they can be run on thousands of minimal processors simultaneously. Traffic management is minimal and solved in hardware. Some of your most expensive operations you can do are read-writes that are not generally necessary in how a GPU operates. And the 3D rendering possible has strict rules to simplify the linear algebra involved and make it as convenient for a computer as possible. It's why rendering "polygons" are always triangles and never squares. I recommend skimming the Red Book even if you only play games. It's a fascinating read and easy to find free.

By comparison opening a menu is an enormous operation that is limited to a single logical thread. It isn't hanging up because rendering a rectangle on the screen is that hard. It's hanging up because rendering that rectangle is the last step in an enormous data operation and I feel like anybody who even knows what programming is would be aware of that. Word processors and other data programs don't hang up because the letter 'a' is soooo hard to render.

Also there's the priorities. If a primitive just vomits all over itself and the rendering goes tits up for a single frame, or if a frame gets pushed out half finished or missing completely then nobody will care. It matters for 16 milliseconds. In other applications, especially online where packet security is important and data may arrive corrupted or missing portions and so there may be expectations to recover damaged or missing data through a communications delay that can be noticed by humans. Again the lag isn't in rendering a rectangle with letters on it. The lag is in the work you don't see solving other, generally more urgent problems that are designed so you don't notice anything went wrong but a brief second of unexpected waiting.

>>11105
>By comparison opening a menu is an enormous operation that is limited to a single logical thread. It isn't hanging up because rendering a rectangle on the screen is that hard. It's hanging up because rendering that rectangle is the last step in an enormous data operation and I feel like anybody who even knows what programming is would be aware of that.
25 years ago, CPUs were 10 times slower just by clock speed alone, but they were still pretty snappy at 2D GUI rendering.  My home machine running Linux on 8-year-old bare metal with a lightweight desktop environment is pretty snappy.  I think Windows is slow due to bloat, useless eye candy, built-in spyware, and no real attempt to keep latency under control.

Somewhat related: https://danluu.com/input-lag/

>>11107
That's interesting.  That's a kind of slow.

In your original post, I was thinking more of cases where you select Edit in Microsoft Office and it takes 7 seconds to draw the menu, or something.