x264 is kinda absurdly good at compressing screencasts, even a nearly lossless 1440p screencast will only have about 1 Mbit/s on average. The only artifacts I can see are due to 4:2:0 chroma subsampling (i.e. color bleed on single-pixel borders and such), but that has nothing to do with the encoder, and would almost certainly not happen in 4:4:4, which is supported by essentially nothing as far as distribution goes.
> I used a Satechi USB-C power tester and measured an 8% peak power savings using UASP. That means you'd get 8% more runtime on a battery if you do a lot of file transfers.
No no, even better! Peak power consumption is lower, but the same work is completed much more quickly due to increased throughput, so the energy required for the same work is decreased dramatically. Between the performance increase and the lower power usage I wouldn't be surprised if this reduces energy use by 50 %.
Enter Germany, where it was decided DAB is not a federal matter and basically you have 16 small states with entirely different stations available on DAB. The one real advantage DAB could have had, and they threw it away just to auction off the same frequency band a couple more times.
CRTs are "dumb" devices, they literally just amplify the R/G/B analog signal while deflecting a beam using electromagnets according to some timing signals. As far as input lag goes, they're the baseline. For fast motion they have some advantages at leat over poor LCD screens as well, since non-strobing LCDs quite literally crossfade under constant backlight between the current image and the new image; we perceive this crossfading as additional blurring. A strobing LCD on the other hand shifts the new image into the pixel array and lets the pixels transition while the backlight is turned off. The obvious problem - it's flickering.
LCDs that aren't optimized for low latency will generally just buffer a full frame before displaying it, coupled with a slow panel these will typically have 25-35 ms of input lag at 60 Hz. LCDs meant for gaming offer something called "immediate mode" or similar, where the controller buffers just a few lines or so, which makes the processing delay irrelevant (<1 ms). The image is effectively streamed through the LCD controller directly into the pixel array.
> Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up.
These animations effectively increase the input lag significantly. Even with them turned off there are extra frames of lag between a click and the updated widget fully rendering.
(Everything below refers to a 60 Hz display)
For example, opening a combo-box in Windows 10 with animations disabled takes two frames; the first frame draws just the shadow, the next frame the finished open box. With animations enabled, it seems to depend on the number of items, but generally around 15 frames. That's effectively a quarter second of extra input lag.
A menu fading in takes about ~12 frames (0.2 seconds), but at least you can interact with it partially faded in.
Animated windows? That'll be another 20 frame delay, a third of a second. Without animations you're down to six, again with some half-drawn weirdness where the empty window appears in one frame and is filled in the next. (So if you noticed pop-ups looking slightly weird in Windows, that's why).
I assume these two-frame redraws are due to Windows Widgets / GDI and DWM not being synchronized at all, much like the broken redraws you can get on X11 with a compositor.
> USB is polling with a fairly slow poll interval rate (think a hundred or so ms).
The lowest polling rate typically used by HID input devices is 125 Hz (bInterval=8), while gaming hardware usually defaults to 500 or 1000 Hz (bInterval=2 or 1). Most input devices aren't that major a cause of input lag, although curiously a number of even new products implement debouncing incorrectly, which adds 5-10 ms; rather unfortunate.
I disagree. What you describe is a problem of interaction design founded on bad assumptions; with good interaction design I don't have to show the user that the computer is doing something for the user to be able to tell it happened. This is a problem of the system not showing its state transparently and relying on the user to notice a change in hidden state indicated by a transient window.
Windows Explorer gets your particular example right: When you copy a bunch of files into a folder, it will highlight all of the copied files after it is done, so it doesn't matter if you saw the progress bar or not.
Historically voice encryption was politically only meant for state use, with strict controls, and us plebs not getting any voice encryption or very weak encryption only. Compared to encryption on the internet, this state has persisted for longer in communications. Even in new communication standards the options for encryption generally offer weak/irrelevant security for modern standards (end-to-end encryption).
> Meanwhile, pointing at memory latency as the flaw in Ryzen has been a popular misdirection for a while now.
How is it a misdirection? The data is accurate and memory latency scaling is a well-known issue for simulations like e.g. games (which is a huge market for high end desktop CPUs and also the market 90 % of reviews address), where you can't really explain the performance differences just by higher clocks. It's considered the main reason why much older Intel CPUs can still outperform Ryzen CPUs in games.
On the other hand, if you take something like Cinebench you can literally turn XMP off (thus using JEDEC timings and bus speed) and still get almost the same score (within, say, 2 %). That's because Cinebench is benchmarking pretty much only ALU throughput. That's obviously an important factor for performance, but just as obviously not the only one.
IIRC L3 is slightly slower on Zen 2, main memory as mentioned much slower.
Clock speed advantage -- Most Zen 2 CPUs don't overclock to 4.5 GHz on any core, let alone all-core. The boost numbers are reached with current firmware, but only for tiniest fractions of a second and never under any real load. Sustained single-core boost frequencies are 200-400 MHz lower than the specified boost frequency. On the other hand, Intel CPUs consistently reach their boost frequencies under load, and most CPUs can do their single-core boost as an all-core overclock under load (with much greater power consumption of course).
In practice this means that for equivalently priced parts (e.g. 3900X vs 10900K) the AMD part will have about a GHz lower clock for lightly threaded workloads, which are most workloads. With Intel settings, the Intel and AMD parts have about the same sustained clocks (3.8-4 GHz) under all-core load, but with the defaults of many motherboards the Intel part will run at 4.8-5 GHz, depending on the cooling.
As a desktop user, my CPU tends to be mostly idle. So overall power efficiency is impacted a lot by idle power consumption; my AMD Ryzen CPU alone draws significantly more power in idle than my previous several-years-old Intel system. In fact, just the IO die alone draws almost as much power as some office PCs.
For what it's worth, Intel is still faster in most applications, simply by virtue of having a clock speed advantage that by far exceeds any IPC difference, and also by having much lower memory latencies. AMD has basically a 20-30 ns extra latency over Intel; so with good memory you can do ~45 ns on current Intels, but that will give you ~65 ns on a Ryzen. That's significant for a lot of code (e.g. pointer chasing, complex logic etc.).
On the other hand, few applications scale efficiently to more than just four cores. Yes, of course, AMD delivers more Cinebenchpoints-per-Dollar and usually more Cinebenchpoints overall, but that's not necessarily an interesting metric.
Personally I find that if I'm waiting on something to complete that the application in question tends to use only a tiny number of cores for the task at hand. Usually one.
Another significant weakness of AMD's current platform is idle power consumption.
These factors leave me with a much more nuanced impression than "Intel is ded" or "HOW IS INTEL GOING TO CATCH UP TO THIS????"; CPU reviews these days are just pure clickbait.
Correct, a CMOS sensor with a rolling shutter looks and handles a lot like a piece of DRAM. Pixels are arranged in rows and colums; capturing a frame works just like a sequential read through a DRAM array. The nominal frame-rate at a given resolution is set by the read-out speed of the array, so reducing resolution increases speed almost linearly.
Autochrome is pretty much just subpixels. You capture and view a greyscale image through the same dots-of-color filter plate, and thus you see color, just like an image sensor uses a Bayer filter to deconstruct color into greyscale (with three times as many pixels), and then your screen has three subpixel per pixel which you perceive as a solid color because they're sorta far away and kinda small.
> Certain types of mechanical shutters exhibit the same phenomenon at high speeds.
Pretty much all focal-plane shutters do it beyond 1/60 to 1/250 of a second (identical to the flash sync speed), because the finite movement speed of the upper and lower curtains would result in an uneven exposure otherwise.
> All I want is an Android between 5 inch and 6 inch, something the size of a 2016 iPhone SE.
That's much larger than the SE (4" screen, 125x60x7.5 mm, 110 g compared to 5" screen, 140x70x7.5 mm, 150 g for the 2020 SE). Which is a really nice form factor, and well suited for apps, but not so good for web browsing.
Sometimes I use a quad-core laptop with 2 GB of memory and no swap (because it doesn't have enough disk space for a meaningful amount of swap) and five tabs is practically a hard limit. Even with adblocking, news sites and sites like imgur or reddit -- or really anything using heavy and fancy scripting or animations -- demand to be the sole tab on the machine.