Hacker News Reader

Comment by tjader | Hacker News Reader

But is this cache trustworthy or will it eventually lead you to click in the wrong place because the situation changed and now there's a new button making everything change place?

And even if every information takes a bit to figure out, it doesn't excuse taking a second to even draw the UI. If checking bluetooth takes a second, then draw the button immediately but disable interaction and show a loading icon, and when you get the blutooth information update the button, and so on for everything else.

View on HN

As someone who routinely hops between WiFi networks, I've never seen a wrong value here.

And OK, we'll draw a tile with all the buttons with greyed out status for that half second and then refresh to show the real status. Did that really make things better, or did it make it worse?

And if we bothered keeping all that in memory, and kept using the CPU cycles to make sure it was actually accurate and up to date on the click six hours later, wouldn't people then complain about how obviously bloated it was? How is this not a constant battle of being unable to appease any critics until we're back at the Win 3.1 state of things with no Bluetooth devices, no WiFi networks, no dynamic changing or audio devices, etc?

And remember, we're comparing this to just rendering a volume slider which still took a similar or worse amount of time and offered far less features.

> And OK, we'll draw a tile with all the buttons with greyed out status for that half second and then refresh to show the real status. Did that really make things better, or did it make it worse?

Clearly better. Most of the buttons should also work instantly, most of the information should also be available instantly. The button layout is rendered instantly, so I can already figure out where I want to click without having to wait one second even if the button is not enabled yet, and by the time my mouse reaches it it will probably be enabled.

> And remember, we're comparing this to just rendering a volume slider which still took a similar or worse amount of time and offered far less features.

I've never seen the volume slider in Windows 98 take one second to render. Not even the start menu, which is much more complex, and which in Windows 11 often takes a second, and search results also show up after a random amount of time and shuffle the results around a few times, leading to many misclicks.

It doesn't even know if the devices are still attached (as it potentially hasn't tried interfacing them for hours) but should instantly be able to allow input to control them and fully understand their current status. Right. Makes sense.

And if you don't remember the volume slider taking several seconds to render on XP you must be much wealthier than me or have some extremely rose colored glasses. I play around with old hardware all the time and get frustrated with the unresponsiveness of old equipment with period accurate software, and had a lot of decent hardware (to me at least) in the 90s and 00s. I've definitely experienced lots of times of the start menu painting one entry after the other at launch, taking a second to roll out, seeking on disk for that third level menu in 98, etc.

Rose colored glasses, the lot of you. Go use an old 386 for a month. Tell me how much more productive you are after.

Rendering a volume slider or some icons shouldn't take half a second, regardless. e.g. speaking of Carmack, Wolfenstein: Enemy Territory hits a consistent 333 FPS (the max the limiter allows) on my 9 year old computer. That's 3 ms/full frame for a 3d shooter that's doing considerably more work than a vector wifi icon.

Also, you could keep the status accurate because it only needs to update on change events anyway, events that happen on "human time" (e.g. you plugged in headphones or moved to a new network location) last for a practical eternity in computer time, and your pre-loaded icon probably takes a couple kB of memory.

It seems absurd to me that almost any UI should fail to hit your monitor's refresh rate as its limiting factor in responsiveness. The only things that make sense for my computer to show its age are photo and video editing with 50 MB RAW photos and 120 MB/s (bytes, not bits) video off my camera.

It's not the drawing an icon to a screen that takes the half second, it's querying out to hardware on driver stacks designed for PCI WiFi adapters from the XP era along with all the other driver statuses.

It's like how Wi-Fi drivers would cause lag from querying their status, lots of poorly designed drivers and archaic frameworks for them to plug in.

And I doubt any hardware you had when Wolfenstein:ET came out rendered the game that fast. I remember it running at less than 60fps back in '03 on my computer. So slow, poorly optimized, I get better frame rates in Half Life. Why would anyone write something so buggy, unoptimized, and slow?!

You don't need to query the hardware to know the network interface is up. A higher level of the stack already knows that along with info like addresses, routes, DNS servers, etc.

IIRC it ran at 76 fps (higher than monitor refresh, one of the locally optimal frame rates for move speed/trick jumps) for me back then on something like an GeForce FX 5200? As long as you had a dedicated GPU it could hit 60 just fine. I think it could even hit 43 (another optimal rate) on an iGPU, which were terrible back then.

In any case, modern software can't even hit monitor refresh latency on modern hardware. That's the issue.

It's not just showing "is the interface up", it's showing current signal strength, showing current ssid, showing results from the recent poll of stations, etc.

And then doing the same for Bluetooth.

And then doing the same for screen rotation and rotation lock settings. And sound settings, And then another set of settings. And another set of settings. All from different places of the system configuration while still having the backwards compatibility of all those old systems.

It's not a slowness on painting it. It can do that at screen refresh rates no problem. It's a question of querying all these old systems which often result in actual driver queries to get the information.

43fps? Sure sounds slow to me. Why not 333fps on that hardware? So bloated, so slow.

You're just listing mechanisms for how it might be slow, but that doesn't really make it sensible. Why would the OS query hardware for something like screen rotation or volume? It knows these things. They don't randomly change. It also knows the SSID it's connected to and the results of the last poll (which it continuously does to see if it should move).

And yes it should cache that info. We're talking bytes. Less than 0.0001% of the available memory.

Things were different on old hardware because old hardware was over 1000x slower. On modern hardware, you should expect everything to be instantaneous.

And yet doing an ipconfig or netsh wlan show interfaces isn't always instantaneous depending on your hardware and the rest of your configuration. I can't tell you what all it's actually doing under the hood, but I've definitely seen variations of performance on different hardware.

Sometimes the devices and drivers just suck. Sometimes it's not the software's fault it's running at 43fps.

I'm hitting the little quick settings area on my exceptionally cheap and old personal laptop. I haven't experienced that slowness once. Once again I imagine the other stuff running interrupting all the OS calls and what not loading this information causes it to be slow.

I don't know what operating system you're talking about, but the bottleneck on my linux machine for asking for interfaces is the fact that stdout is write blocking.

I routinely have shy of 100 network interfaces active and `ip a` is able to query everything in nanoseconds.

Considering this whole conversation is about sometimes some people have a little bit of slowness drawing the quick settings area in Windows 11 and I gave commands like "netsh" it should be pretty dang obvious which OS we're talking about. But I guess some people have challenges with context clues.

And once again, on some Linux machines I've had over the years, doing an ip a command could hang or take a while if the device is in a bad state or being weird. It normally returns almost instantly, but sometimes has been slow to give me the information.

You hit on something there, I could type faster than my 2400 baud connection but barring a bad connection those connections were pretty reliable.

Reply on news.ycombinator.com