blattimwind (u/blattimwind)

blattimwind commented on H.266/Versatile Video Coding (VVC) newsletter.fraunhofer.de/... · Posted by u/caution

milansuk · 5 years ago

End-credits are just text. So it should be possible to put it through OCR and save only text, positions, and fonts. And the text is also possible to compress with a dictionary.

blattimwind · 5 years ago

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.

blattimwind commented on UASP makes Raspberry Pi 4 disk IO 50% faster jeffgeerling.com/blog/202... · Posted by u/geerlingguy

blattimwind · 5 years ago

> 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 %.

blattimwind commented on Microsoft’s new x86 DataCenter class machines running Windows (2018) anandtech.com/show/13522/... · Posted by u/rbanffy

blattimwind · 5 years ago

The late 1990s called and want their Numalink back.

blattimwind commented on Analogue radio in the UK given 10-year stay of execution theregister.com/2020/07/0... · Posted by u/open-source-ux

mdiesel · 5 years ago

In my limited experience, driving across the UK on FM is a pain due to regional differences. A couple of hours driving and I'll need to retune a few times, and my saved stations won't be applicable. DAB solves that minor issue at least.

I don't know the details of the spectrum usage, but there are more niche nationwide stations on DAB (Planet Rock is hardly niche anymore tbh, and is great). So maybe it's more accurate to say the FM spectrum isn't cluttered for barrier to entry reasons.

blattimwind · 5 years ago

> DAB solves that minor issue at least.

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.

blattimwind commented on MaXX Interactive Desktop: A Re-Implementation of the IRIX Interactive Desktop maxxinteractive.com/... · Posted by u/rbanffy

cellularmitosis · 5 years ago

(straying slightly off-topic) I recently had the same experience with an Apple eMac. Grab a window, shake it around as fast as you can, or just move the mouse cursor around in circles quickly.

"Whoa, why does this seem so much more responsive than my modern machines?" Two things, I think: 1) the mouse cursor is being updated with every vertical refresh (80Hz), and 2) the latency of the CRT must be lower than an LCD.

Not bad for a 700MHz, 18 year old machine!

blattimwind · 5 years ago

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.

blattimwind commented on MaXX Interactive Desktop: A Re-Implementation of the IRIX Interactive Desktop maxxinteractive.com/... · Posted by u/rbanffy

StillBored · 5 years ago

While you might be slightly right, my experience tuning windows machines leads me to believe your missing the mark.

I'm going to say the three largest contributions to general desktop lag are:

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.

Too many layers between the application draw commands and the actual display. All this compositing, vsync, and minimal 2d acceleration creates a low level persistent lag. Disabling aero on a win7 machine does wonders to its responsiveness. But even then pre-vista much of the win32 GDI/drawing API was basically implemented in hardware on the GPU. If you get an old 2d win32 API benchmark, you will notice that modern machines don't tend to fare well in raw API call performance. 30 seconds poking around on youtube, should find you a bunch of comparisons like this https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM.... Keep in mind that even in 2020 pretty much every application on the machine is still relying on GDI (same as linux apps relying on xlib).

Input+processing lag, USB is polling with a fairly slow poll interval rate (think a hundred or so ms). Combined with the fact that the keystrokes/events then end up queued/scheduled through multiple subsystems before eventually finding their way to the correct window, and then having to again reschedule and get the application to retrieve and process it via GetMessage()/etc. Basically, this is more a function of modern software bloat, where all those layers of correct architecture add more overhead than the old school get the ps2 interrupt, post a message to the active window queue, schedule the process managing the window messages. (https://social.technet.microsoft.com/Forums/windows/en-US/b1...)

There are a number of other issues, but you can retune those three areas to some extent, and the results are a pretty noticeable improvement. Having someone at MS/etc go in and actually focus on fixing this might have a massive effect with little effort. But that doesn't appear to be in the cards, since they appear to be more interested in telemetry and personal assistants.

blattimwind · 5 years ago

> 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.

https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB...

blattimwind commented on MaXX Interactive Desktop: A Re-Implementation of the IRIX Interactive Desktop maxxinteractive.com/... · Posted by u/rbanffy

whoopdedo · 5 years ago

There was a revelation a while back that instantaneous UX can be detrimental. If the action occurs so quickly that the users can't see it happening, they have a tendency to assume it didn't happen. Programmers had to introduce intentional latency through elements such as the file copy animation.

blattimwind · 5 years ago

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.

blattimwind commented on Low latency multipliers and cryptographic puzzles blog.janestreet.com/reall... · Posted by u/jsnell

tgflynn · 5 years ago

I wonder how competitive GPU's would be with FPGA's on this type of problem.

FPGA's have the advantage that the circuit architecture can be designed specifically for the algorithm but as far as I know they have much lower gate density and clock speeds compared to top of the line GPU's.

In the case of bitcoin mining as far as I know GPU's passed the hat directly to ASIC's. I never heard that FPGA's were competitive for that.

blattimwind · 5 years ago

> In the case of bitcoin mining as far as I know GPU's passed the hat directly to ASIC's. I never heard that FPGA's were competitive for that.

They were, before the ASICs came. CPU -> GPU -> FPGA -> ASIC. A classic story of specialization.

blattimwind commented on Ask HN: Good Resources on Voice Encryption? · Posted by u/quotz

aosaigh · 5 years ago

What exactly are the challenges of voice encryption over say text encryption? Just the bandwidth of data, or establishing trust?

blattimwind · 5 years ago

From a modern point of view it's not a challenge.

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).