6 ms·

Layers of abstraction take you further away from the metal. The more layers of abstraction your keypress must traverse before rendering is complete and the phot

Layers of abstraction take you further away from the metal. The more layers of abstraction your keypress must traverse before rendering is complete and the photons have reached your retina, the longer it will be until that happens. Layers of abstraction make complex tasks more reachable by a larger number of programmers by reducing the amount of specialist knowledge about those lower layers required to do the job. The more layers of abstraction you have, the less they have to worry about lower levels and can just get on with what they want to do.

wruza 9y ago
Numerous games, including those having complex graphics and behavior, can render 120+ frames per second and realtime interactions (physics, optics, reactions) on pretty average hardware. I don’t think that game scripters who make final things like scenery or ui face complexity much harder than those in gtk/qt/wpf/htmljs widget programming. Details would be interesting though, since I’m no game developer. If true, it must be something very wrong with traditional ui systems? Edit: my apologies, I didn’t read the article first and thought it measured complete feedback like “press ctrl-f and wait for element to popup”, but I’m interested in my question regarding games anyway.
- stult 9y ago
  It's a lot easier to optimize the APIs underlying those scripts because there are far fewer of them in even the most complicated video games than there are comparable abstractions in modern OSs. And there's more motivation. People accept the slightly lower responsiveness in normal OS interactions whereas even millisecond delays in competitive games are intolerable.
  - wruza 9y ago
    That said, whether hundreds of ms delays in OS are tolerable or not is a question on topic itself.
- badsectoracula 9y ago
  There isn't much of a difference between a GUI toolkit you'd find in a desktop application and the GUI framework you'd see in a game - the most likely difference will be that the game GUI will be redrawn every frame whereas the desktop GUI wont (and there are game GUI frameworks that cache their output to avoid redrawing the entire widget tree every frame). The difference when it comes to why games can be snappier is that games are "allowed" to bypass most of the layers and cruft that exists between the user and the hardware, including the compositor that the linked article is talking about (in Windows at least). Fortunately in Linux with Xorg you can get stuff on screen as fast as the code can ask for it, as long as you are not using a compositor (so you can even play games in a window with no additional lag!). Hopefully the Wayland mania wont get to kill Xorg since yet another issue Wayland has and X11 doesn't is that with Wayland you are forced in a composition model.
  - _pmf_ 9y ago
    > the most likely difference will be that the game GUI will be redrawn every frame whereas the desktop GUI wont (and there are game GUI frameworks that cache their output to avoid redrawing the entire widget tree every frame). Modern UI toolkits (WPF, QML, JavaFX) operate on a scene graph, so they work exactly the same. Android is slowly catching up; it's a disgusting mix of the worst of both worlds.
  - Jasper_ 9y ago
    The reason that apps on Windows can bypass the compositor is that you can use them as the scanout buffer directly on fullscreen. On Linux (both Xorg and Wayland), this same exact behavior is supported with a compositor. For strange legacy reasons, it's known as "fullscreen unredirection". If you're running windowed on all three OSes, you see the same compositor latency.
    - badsectoracula 9y ago
      Note that on Linux you are not forced to use a compositor, personally i do not use one and so i do not have any such penalty when running games in windowed mode.
  - 9y ago
- pjc50 9y ago
  > can render 120+ frames per second and realtime interactions (physics, optics, reactions) on pretty average hardware Yes, but when you consider that the underlying "average" hardware of 2017 has a million times as many transistors and runs a thousand times as fast as the Amiga that seems less impressive.
- ssalazar 9y ago
  Cost/value. AAA games with "complex graphics" take years to develop, cost millions of dollars to produce, require dozens of developers, are extremely power hungry, and require specialized GPU programming to make look good and render fast. They are typically judged by how fast/smoothly they perform, so it makes sense to direct resources to this. This isn't an approach most people want to take for average mobile or desktop GUI apps.
  - TremendousJudge 9y ago
    Every realtime videogame, from AAA shooters built by hundreds of developers to tiny one man band indie platformers, is more responsive than the average desktop app. This happens because if the controls don't respond well, the game is automatically bad. Sadly this isn't the case with desktop apps
- tormeh 9y ago
  I think you severely underestimate the difficulty of making a game engine.
  - wruza 9y ago
    I was not talking about making a low-level engine; I only theoretized that gamemaking is somewhat as hard as modern ui at the top level where you script it and “draw” 3d/2d ui or interaction parts. For fair comparison on that scale game engines should correspond to at least font and vector rendering like pango/ft or cairo, or even direct blit ops, not to widget positioning. For one example, it is pretty easy to take unity3d and make a 9pool game — it is just ~two hour tutorial on youtube for people with no cg background at all.
- z3t4 9y ago
  They would have problems rendering text though. I'm working on a text editor and made some research on the fastest way to render text. It's really hard to beat the OS API.
  - wruza 9y ago
    Good point, I also touched pango-level text rendering and can remember how long some layout calculations may take. Do things get better with DirectWrite/2D or is it just a facade to old techniques incompatible with game environments? Edit: I also like how OSX go-fullscreen animation is done. They render new window once (with e.g. lots of text) completely in background and simply scale old window to fullscreen with alpha-transition between the two. First few frames give enough time for new window to be rendered and then it magically appears as being live-resized. I suspect few users actually notice the trick.
deleted 9y ago
[deleted]
NickM 9y ago
Layers of abstraction make complex tasks more reachable by a larger number of programmers by reducing the amount of specialist knowledge about those lower layers required to do the job. The more layers of abstraction you have, the less they have to worry about lower levels and can just get on with what they want to do. Sometimes this is certainly true, but I think when it comes to abstraction layers, people tend to overestimate the benefits and underestimate the costs. Lately I've been thinking a lot about Joel's Law of Leaky Abstractions. 20 years ago we had native UI toolkits that were fast and responsive, relatively simple to program against, and yielded a common design language that was shared across all the apps on a given OS. Now we have monstrosities like Electron that are bulky and slow, yield non-native UIs across the board, and require programmers to understand a whole mess of technologies and frameworks to use effectively. I mean, sure, now you don't have to rewrite your web code to build a desktop app, but don't get me started on the utter quagmire that is modern web development. These days it feels like software development has an infection, and instead of carving out the infection and letting it heal, we just keep piling more and more bandaids on top of it.
- dan_mctree 9y ago
  Absolutely, the amount of technologies often required for full stack web development is astounding. Even for a smallish website, you can be quickly staring at 30+ essential pieces of technology you need to at least understand somewhat. Several languages, package managers, IDEs, frameworks, a database, debuggers, compilers, project management tools, virtual machines, server software, your OS, supporting protocols (SSL, TCP/IP, SSH, DNS etc.) and the list goes on. Who can truly understand all of that simultaneously? All of that bloat just massively increases the chance of errors and inefficiencies.
- TickleSteve 9y ago
  Well said... It wouldn't be so bad if the many layers of abstractions actually resulted in increased productivity, but they clearly don't. Simplicity >> abstractions.
jdietrich 9y ago
Layers of abstraction aren't necessarily a problem if the designers care about latency. Oculus have invested huge resources in minimising latency, but most designers are fairly tolerant of latency if they can trade it off for increased throughput or lower development costs. We saw this particularly strongly with Android - circa 2011, Google realised that Android latency was having a major impact on UX, so they invested the resources to address it. Unfortunately, early architectural decisions meant that they never quite caught up with Apple, who had prioritised latency in iOS from the outset.
hasenj 9y ago
Consequently, we have more and more incompetent people writing software with absolutely no concerns about performance.

wruza 9y ago

Numerous games, including those having complex graphics and behavior, can render 120+ frames per second and realtime interactions (physics, optics, reactions) on pretty average hardware. I don’t think that game scripters who make final things like scenery or ui face complexity much harder than those in gtk/qt/wpf/htmljs widget programming. Details would be interesting though, since I’m no game developer. If true, it must be something very wrong with traditional ui systems? Edit: my apologies, I didn’t read the article first and thought it measured complete feedback like “press ctrl-f and wait for element to popup”, but I’m interested in my question regarding games anyway.

stult 9y ago
It's a lot easier to optimize the APIs underlying those scripts because there are far fewer of them in even the most complicated video games than there are comparable abstractions in modern OSs. And there's more motivation. People accept the slightly lower responsiveness in normal OS interactions whereas even millisecond delays in competitive games are intolerable.
- wruza 9y ago
  That said, whether hundreds of ms delays in OS are tolerable or not is a question on topic itself.
badsectoracula 9y ago
There isn't much of a difference between a GUI toolkit you'd find in a desktop application and the GUI framework you'd see in a game - the most likely difference will be that the game GUI will be redrawn every frame whereas the desktop GUI wont (and there are game GUI frameworks that cache their output to avoid redrawing the entire widget tree every frame). The difference when it comes to why games can be snappier is that games are "allowed" to bypass most of the layers and cruft that exists between the user and the hardware, including the compositor that the linked article is talking about (in Windows at least). Fortunately in Linux with Xorg you can get stuff on screen as fast as the code can ask for it, as long as you are not using a compositor (so you can even play games in a window with no additional lag!). Hopefully the Wayland mania wont get to kill Xorg since yet another issue Wayland has and X11 doesn't is that with Wayland you are forced in a composition model.
- _pmf_ 9y ago
  > the most likely difference will be that the game GUI will be redrawn every frame whereas the desktop GUI wont (and there are game GUI frameworks that cache their output to avoid redrawing the entire widget tree every frame). Modern UI toolkits (WPF, QML, JavaFX) operate on a scene graph, so they work exactly the same. Android is slowly catching up; it's a disgusting mix of the worst of both worlds.
- Jasper_ 9y ago
  The reason that apps on Windows can bypass the compositor is that you can use them as the scanout buffer directly on fullscreen. On Linux (both Xorg and Wayland), this same exact behavior is supported with a compositor. For strange legacy reasons, it's known as "fullscreen unredirection". If you're running windowed on all three OSes, you see the same compositor latency.
  - badsectoracula 9y ago
    Note that on Linux you are not forced to use a compositor, personally i do not use one and so i do not have any such penalty when running games in windowed mode.
- 9y ago
pjc50 9y ago
> can render 120+ frames per second and realtime interactions (physics, optics, reactions) on pretty average hardware Yes, but when you consider that the underlying "average" hardware of 2017 has a million times as many transistors and runs a thousand times as fast as the Amiga that seems less impressive.
ssalazar 9y ago
Cost/value. AAA games with "complex graphics" take years to develop, cost millions of dollars to produce, require dozens of developers, are extremely power hungry, and require specialized GPU programming to make look good and render fast. They are typically judged by how fast/smoothly they perform, so it makes sense to direct resources to this. This isn't an approach most people want to take for average mobile or desktop GUI apps.
- TremendousJudge 9y ago
  Every realtime videogame, from AAA shooters built by hundreds of developers to tiny one man band indie platformers, is more responsive than the average desktop app. This happens because if the controls don't respond well, the game is automatically bad. Sadly this isn't the case with desktop apps
tormeh 9y ago
I think you severely underestimate the difficulty of making a game engine.
- wruza 9y ago
  I was not talking about making a low-level engine; I only theoretized that gamemaking is somewhat as hard as modern ui at the top level where you script it and “draw” 3d/2d ui or interaction parts. For fair comparison on that scale game engines should correspond to at least font and vector rendering like pango/ft or cairo, or even direct blit ops, not to widget positioning. For one example, it is pretty easy to take unity3d and make a 9pool game — it is just ~two hour tutorial on youtube for people with no cg background at all.
z3t4 9y ago
They would have problems rendering text though. I'm working on a text editor and made some research on the fastest way to render text. It's really hard to beat the OS API.
- wruza 9y ago
  Good point, I also touched pango-level text rendering and can remember how long some layout calculations may take. Do things get better with DirectWrite/2D or is it just a facade to old techniques incompatible with game environments? Edit: I also like how OSX go-fullscreen animation is done. They render new window once (with e.g. lots of text) completely in background and simply scale old window to fullscreen with alpha-transition between the two. First few frames give enough time for new window to be rendered and then it magically appears as being live-resized. I suspect few users actually notice the trick.

deleted 9y ago

[deleted]

NickM 9y ago

Layers of abstraction make complex tasks more reachable by a larger number of programmers by reducing the amount of specialist knowledge about those lower layers required to do the job. The more layers of abstraction you have, the less they have to worry about lower levels and can just get on with what they want to do. Sometimes this is certainly true, but I think when it comes to abstraction layers, people tend to overestimate the benefits and underestimate the costs. Lately I've been thinking a lot about Joel's Law of Leaky Abstractions. 20 years ago we had native UI toolkits that were fast and responsive, relatively simple to program against, and yielded a common design language that was shared across all the apps on a given OS. Now we have monstrosities like Electron that are bulky and slow, yield non-native UIs across the board, and require programmers to understand a whole mess of technologies and frameworks to use effectively. I mean, sure, now you don't have to rewrite your web code to build a desktop app, but don't get me started on the utter quagmire that is modern web development. These days it feels like software development has an infection, and instead of carving out the infection and letting it heal, we just keep piling more and more bandaids on top of it.

dan_mctree 9y ago
Absolutely, the amount of technologies often required for full stack web development is astounding. Even for a smallish website, you can be quickly staring at 30+ essential pieces of technology you need to at least understand somewhat. Several languages, package managers, IDEs, frameworks, a database, debuggers, compilers, project management tools, virtual machines, server software, your OS, supporting protocols (SSL, TCP/IP, SSH, DNS etc.) and the list goes on. Who can truly understand all of that simultaneously? All of that bloat just massively increases the chance of errors and inefficiencies.
TickleSteve 9y ago
Well said... It wouldn't be so bad if the many layers of abstractions actually resulted in increased productivity, but they clearly don't. Simplicity >> abstractions.

jdietrich 9y ago

Layers of abstraction aren't necessarily a problem if the designers care about latency. Oculus have invested huge resources in minimising latency, but most designers are fairly tolerant of latency if they can trade it off for increased throughput or lower development costs. We saw this particularly strongly with Android - circa 2011, Google realised that Android latency was having a major impact on UX, so they invested the resources to address it. Unfortunately, early architectural decisions meant that they never quite caught up with Apple, who had prioritised latency in iOS from the outset.

hasenj 9y ago

Consequently, we have more and more incompetent people writing software with absolutely no concerns about performance.