|
|
|
|
|
by bluetomcat
944 days ago
|
|
The core OS APIs still allow writing fast and snappy applications, but most apps nowadays are not written this way. Apps are using generic libraries that bring "the gorilla and the jungle" with them, browsers are relying on a JIT to draw their own UI, etc. |
|
1. Bad abstraction, causing the moral equivalent of N+1 queries in UI code. For example, modify one thing, causing layout, moving something else, causing layout, moving something else, causing layout, etc., etc., until it is all recalculated and re-laid out, and then allowing the paint.
2. Hidden serialization of asynchronous processes, essentially causing tiny pauses throughout the main thread.
I think this is one reason why people are so impressed with IMGUI. They imagine that the UI code must be doing an incredible amount of work to feel so slow, but then they watch a similar IMGUI app build and display the whole UI every frame 60-120 times per second, with plenty processing power left over. But if the other frameworks weren't wasting clock time, they could feel plenty fast.
You can get a good feel for what is really slow by using a very slow computer. The original Macintosh feels snappy, but it is doing one process in black and white. It's not hard to reach 30fps. When you take System 7, and put it on a 16MHz 68020 with half a memory bus (Mac LC), and run it at 16-bit color, painting those windows takes a long time. Our trick back then was to jump to black and white when we needed to get things done quickly, then back to higher bit depths when we wanted color or eye candy.
Now we have a situation where we can output full screen 24bit color in a millisecond or less, we are waiting on other things.