6 ms·

> Don’t you find it a bit funny that Windows 95 is actually snappier than Windows 10? It’s really a shame that response times in modern computers are visibly wo

> Don’t you find it a bit funny that Windows 95 is actually snappier than Windows 10? It’s really a shame that response times in modern computers are visibly worse than those in twenty years ago. My Amiga A1200 (Only have extra RAM) feels faster and more responsive that any modern computer with Windows or GNU/Linux desktop.

fredley 9y ago
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.
bitwize 9y ago
https://news.ycombinator.com/item?id=15721854 https://news.ycombinator.com/item?id=15721854
amiga-workbench 9y ago
I was seriously impressed with how well BeOS performed too. I've got a Blizzard 1230-IV with 128mb of RAM bunged into my A1200 at the moment and it runs rings around my desktop running Gnome.
- waddlesplash 9y ago
  Haiku has the same rendering model, so it's equally snappy here. :)
em3rgent0rdr 9y ago
> "or GNU/Linux desktop" I believe Wayland has made some latency improvements.
- badsectoracula 9y ago
  Wayland uses a composition model which is inherently slower than having direct access to the front buffer.
  - TheCoreh 9y ago
    Not necessarily: video output is ultimately limited by the display. If the display runs at, say, 60Hz and both drawing on an off-screen buffer and compositing together take up less than ~16ms, the result should be exactly the same as drawing directly on the front buffer. The main problem is that modern GPU rendering is “pipelined”, so it's entirely possible to have a drawing operation that takes 16ms and a compositing operation that also takes 16ms, and still have your application running at 60FPS, albeit 1 frame "behind" the input. Most developers are not aware of that. (Including me, until recently. I learned about this while trying to figure out why my VR application felt "wobbly", despite running at the recommended 90FPS) The HTC Vive ships with a really neat tool for visualizing that: http://i.imgur.com/vqp01xn.png http://i.imgur.com/vqp01xn.png
    - badsectoracula 9y ago
      This assumes you are synchronizing the updates with the monitor's refresh cycle, however if you aren't (and the major reason you see lag in compositors is because they do such synchronizations) then composition is indeed slower since it involves several more moving parts and the need to orchestrate the refresh of multiple windows (as opposed to the instant "i want to draw on the screen now" model that X11/Xorg without a compositor and Windows without DWM use). I give a few more details here: https://news.ycombinator.com/item?id=15748880 https://news.ycombinator.com/item?id=15748880
      - TheCoreh 9y ago
renox 9y ago
Except that the Amiga didn't have any memory protection, something not really possible when connected to Internet. A more interesting comparison is BeOS: it had memory protection and it was (probably still is) way more responsive than Linux and Windows. Thad said with a SSD a computer responsiveness is good enough and if display latency bother you, buy a monitor with an high refresh rate! You'll have a fix much sooner than waiting for a software fix of the issue..
rasz 9y ago
open a hard drive folder, wait until it draws one icon at a time and get back to me
Gravityloss 9y ago
A fun experience some years back: running Wine on OSX and browsing the file system with explorer was a lot faster than with OSX:s own finder.

fredley 9y ago

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.

bitwize 9y ago

https://news.ycombinator.com/item?id=15721854 https://news.ycombinator.com/item?id=15721854

amiga-workbench 9y ago

I was seriously impressed with how well BeOS performed too. I've got a Blizzard 1230-IV with 128mb of RAM bunged into my A1200 at the moment and it runs rings around my desktop running Gnome.

waddlesplash 9y ago
Haiku has the same rendering model, so it's equally snappy here. :)

em3rgent0rdr 9y ago

> "or GNU/Linux desktop" I believe Wayland has made some latency improvements.

badsectoracula 9y ago
Wayland uses a composition model which is inherently slower than having direct access to the front buffer.
- TheCoreh 9y ago
  Not necessarily: video output is ultimately limited by the display. If the display runs at, say, 60Hz and both drawing on an off-screen buffer and compositing together take up less than ~16ms, the result should be exactly the same as drawing directly on the front buffer. The main problem is that modern GPU rendering is “pipelined”, so it's entirely possible to have a drawing operation that takes 16ms and a compositing operation that also takes 16ms, and still have your application running at 60FPS, albeit 1 frame "behind" the input. Most developers are not aware of that. (Including me, until recently. I learned about this while trying to figure out why my VR application felt "wobbly", despite running at the recommended 90FPS) The HTC Vive ships with a really neat tool for visualizing that: http://i.imgur.com/vqp01xn.png http://i.imgur.com/vqp01xn.png
  - badsectoracula 9y ago
    This assumes you are synchronizing the updates with the monitor's refresh cycle, however if you aren't (and the major reason you see lag in compositors is because they do such synchronizations) then composition is indeed slower since it involves several more moving parts and the need to orchestrate the refresh of multiple windows (as opposed to the instant "i want to draw on the screen now" model that X11/Xorg without a compositor and Windows without DWM use). I give a few more details here: https://news.ycombinator.com/item?id=15748880 https://news.ycombinator.com/item?id=15748880
    - TheCoreh 9y ago

renox 9y ago

Except that the Amiga didn't have any memory protection, something not really possible when connected to Internet. A more interesting comparison is BeOS: it had memory protection and it was (probably still is) way more responsive than Linux and Windows. Thad said with a SSD a computer responsiveness is good enough and if display latency bother you, buy a monitor with an high refresh rate! You'll have a fix much sooner than waiting for a software fix of the issue..

rasz 9y ago

open a hard drive folder, wait until it draws one icon at a time and get back to me

Gravityloss 9y ago

A fun experience some years back: running Wine on OSX and browsing the file system with explorer was a lot faster than with OSX:s own finder.