81–90 of 104 posts
Earlier quoted context omitted.
> I wonder how VSCode compares. I was curious so I did some tests: https://imgur.com/a/73coWRR
Thanks for this. I definitely wasn’t expecting VSCode to be almost on par with Emacs...
It is on par with "the fastest terminal emulator in existence". :)
Earlier quoted context omitted.
How does that compare to 144hz 1ms response gaming monitors? I know that late CRT’s handily beat early flatscreens but does that still hold?
For a PC, you'll most likely have USB latency, double-buffering, latency between the graphics card and the screen, latency due to picture processing in the screen. All that is additional to the 1ms that the pixels need to switch color after the instruction to do so has been received.
Earlier quoted context omitted.
Wait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.
It's not so much that CRTs are faster than LCD. It's that old consoles (up until the Sega Saturn, Nintendo 64, Sony Playstation era) didn't draw to frame buffers. They didn't have enough RAM to have a real frame buffer. You configured the graphics chip what you wanted it to draw, and as the scanline scanned across the screen, it outputted the color that was supposed to be output depending on the background/sprite/pal…
Seeing as how this and similar articles regularly crop up here, I'm curious as to when this started and why nothing is done about it. I still regularly use my 14 MHz Amiga 1200 for recreational programming and I _never_ experience input lag on that machine. Thinking back, the first time I noticed input lag was on a Mac LCIII running Word in the mid-90s. Then for a long long time I didn't come across any particularly…
There are underlying reasons, much of which can be gathered under the umbrella term of "virtualisation". Modern computers use layers upon layers of software or hardware to present an interface pretending to each higher level that things are simpler than they really are. These abstractions, however, are leaky, and almost all of them are leaky in the temporal sense. There's a pretend continuity or constant throughput t…
The Amiga 1200 I mentioned earlier does pre-emptive multitasking on a 14 MHz CPU with 256 bytes of cache. I can switch between my IDE, my paint program, the OS desktop, a file manager and a simple text editor without any noticeable delay. It's as fast as flipping between desktops in FVWM on my PC (an operation which, incidentally, never seems to suffer from latency).
> The video card in turn is no longer just a block of memory mapped into the address space of the program doing the drawing, but is its own little computer with cores, threads, schedulers, locks, clocks, delays, and so forth.
The graphics architecture of my Amiga consists of several different chips all timed to a PAL signal and, since they're sharing memory with the CPU and other I/O, are also affected by constant interrupts.
> The desktop window manager
There's a DWM on my Amiga as well, called Intuition, providing several abstractions for programs to open screens and windows and render graphics and text in them. Plus, of course, GadTools, the system library for drawing UI widgets.
> The display in turn might further delay things because it has complex overdrive or scaling logic
The cheap, modern flatscreen connected to one of my Amigas upscales and upsamples _and_ does A->D-conversion on the analog RGB signal and yet manages to show my double-buffered displays scrolling in one pixel increments, with 50 Hz vsync without stuttering or tearing.
Yes, the layers of abstraction have increased in number and complexity, but so has the speed of the surrounding architecture. My PC's clock speed is more than 100 times that of the Amiga, it has 4000 times more RAM (in fact the caches in my cheap CPU exceed the amount of RAM on the Amiga), displays are now connected to the GPU with a wide-bandwith digital interface, and so on.
All of this could perhaps be valid excuses if it was consistent. Yet typing in a Firefox feels faster than typing in for example FocusWriter, and typing in an xterm faster still. I can paint smooth freehand curves in Gimp with instant feedback (something the Amiga is not always capable of, depending on how much bandwidth the selected resolution requires). The computer is capable of full screen, full frame, fully vsynced full HD movie playback without stuttering or dropping frames.
The most interesting aspect is of course that a computer that might feel laggy in certain applications is fully capable of emulating an Amiga, complete with the perceived snappiness of the UI, despite all the overhead of emulation _and_ the supposed delays of the surrounding architecture.
(edit: getting some numbers straight)
Earlier quoted context omitted.
The trouble is that this screen isn't just for entering your password. On my logon screen, I have not only the PIN field (because I enabled the TPM-based Windows Hello feature), but also these other links or buttons: "I forgot my PIN", "Sign-in options", network, Ease of Access, and power. So use of a full GUI framework, that supports accessibility tools such as a screen reader, is justified.
The user doesn't care about any of that. I should be able to wake up the box by typing the pin. The reality is that i have to press the first letter of it then wait then press it again and then I have to wait and see if a dot appears in the field. The reason it works like this is that the user is forced to use the software. It should be the other way around. If people are forced to use something developers should do…
You're making an uncharitable assumption about real people who work full-time on this stuff. I can assure you that they do put a lot of thought into their work. No, I never worked on the Start menu or search myself, but before we started working from home, I was in the same building with the folks that do.
> Because sampling rate is fast enough to misinterpret contact bounce as keystrokes, keyboard control processor perform so-called debouncing of the signals by aggregating them across time to produce reliable output. Such a filtering introduces additional delay, which varies depending on microcontroller firmware. As manufacturers generally don’t disclose their firmware internals, let’s consider typical debouncing algo…
I suspect in practice most software is not very good at giving the compositor the info it needs to avoid wasteful refreshes of the whole desktop, and the compositor probably also isn't putting in as much effort as it could.
Earlier quoted context omitted.
It really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time. You just can't get that responsiveness anymore.
Wait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.
So for a given set of timings, you'd always expect the CRT to be faster, because it represents the absolute minimum time-of-flight delay, assuming it is driven by a direct RAMDAC and not by a conversion box buffering an entire frame or significant portions.
Also, you can "move" electron beams at extremely high speeds. Even in a magnetic deflection CRT like the GDM-FW900 the electron beam can move at more than 80 km/s[1]. In some electrostatic deflection systems the speed of light is exceeded: they can draw a dot moving across the face of the CRT that moves at a higher speed than c. This is possible because "the beam" is a fictional object.
[1] 2304 dots across 482 mm with a pixel clock of around 384 MHz means these 2304 dots are covered in about 6 µs; 482 mm/6 µs = 80.3 km/s.
Earlier quoted context omitted.
The NES-CRT connection is analog and the screen is drawn line by line, if you connect a digital monitor that will have to be buffered and you get some delay/lag of min 1 frame.
Most LCDs only buffer a single line at a time: https://www.youtube.com/watch?v=wts8f1bNnbo
The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
The worst is when I see someone using vim or Emacs over SSH. If you think Electron apps are bad, imagine adding a network round trip between every keystroke!
Earlier quoted context omitted.
If you really believe that you're sensitive enough It's pretty obvious when using extended shortcuts or a string of keys that are committed to muscle memory, like Ctrl+Shift+P (+ first letter of a cmd) or Ctrl+K combos. Imagine playing an instrument wired up to headphones and then adding a 30-60 ms delay... the longer the delay the more it creates that "off" feeling Don't forget too, those are bare metal calculations…
The ear's whole function is to detect differences in patterns. This is how we identify the direction of sound with only two ears. For our ears, a delay of 30ms is an eternity. The eyes on the other hand have very little response to this. Some will say they can spot a 15ms vs 30ms visual delay easily, but this is an open debate rather than an obvious fact. A 15ms delay in audio is noticeable to almost anyone. Differen…
I've made a jumping mechanism for a game that makes you move faster if you jump right when you hit the ground again. This system does not give any audible cues as to when you should jump. When something in this system is slightly off, ie keyboard latency, jump height, gravity, etc. You can't time the jumps properly and you're left feeling that you somehow just can't do it but can't really pinpoint what the problem is exactly.
I think the same applies to many games. Especially fighting games.
With that said, I don't think writing code is about timing. I think it's nice when an editor feels very responsive, but I don't think it necessarily makes me more productive.