this post was submitted on 06 Feb 2025
130 points (82.5% liked)

Curated Tumblr

4232 readers
541 users here now

For preserving the least toxic and most culturally relevant Tumblr heritage posts.

The best transcribed post each week will be pinned and receive a random bitmap of a trophy superimposed with the author's username and a personalized message. Here are some OCR tools to assist you in your endeavors:

Don't be mean. I promise to do my best to judge that fairly.

founded 2 years ago
MODERATORS
 
top 16 comments
sorted by: hot top controversial new old
[–] Fubarberry@sopuli.xyz 46 points 11 hours ago* (last edited 11 hours ago) (3 children)

I tried to figure out if this was real, and the closest I found was this article where setting a solid color background in windows 7 would cause up to a 30sec delay during login. The solution was apparently to make a small image in the color you wanted, and tile that image so that it would cover the whole desktop.

Here's a hackernews discussion on it, includes some other fun stories like how windows 95 progress bars would complete faster if you were wiggling the mouse the whole time.

[–] adarza@lemmy.ca 4 points 7 hours ago (1 children)

i always ran solid color backgrounds with win7. never experienced this 'issue'.

[–] starman2112@sh.itjust.works 15 points 7 hours ago

Maybe you did, and you didn't even notice

Imagine how much faster your computer could have been

[–] NickwithaC@lemmy.world 11 points 9 hours ago
[–] Badabinski@kbin.earth 24 points 11 hours ago

I bring up the mouse wiggling thing all the time when I'm sharing my screen at work. I get impatient with computers very easily, so I start wiggling and jiggling and doing figure 8s with my mouse cursor and say that "it makes the computer go faster." Then I get to be distracted by telling someone how that used to be kiiinda true back in the good ol' days of PS2 and single threaded cooperatively-multitasked operating systems (the fact that PS2 sends hardware interrupts still blows my mind a bit).

Funnily enough, I learned about it from a greybeard who did a stint at Novell. He'd constantly jiggle his mouse around while waiting for shit and I bet he was just waiting for me to ask him why he thought it made the computer "faster."

[–] e8d79@discuss.tchncs.de 90 points 13 hours ago (1 children)
[–] LodeMike@lemmy.today 6 points 5 hours ago (1 children)
[–] fallingcats@discuss.tchncs.de 1 points 14 minutes ago

That has nothing to do with single threading that shit, an Arduino could draw that image faster. Most likely something fails to start correctly and windows waits for a 30 second timeout to run out before continuing anyway.

[–] CancerMancer@sh.itjust.works 50 points 13 hours ago (1 children)

Even for Windows, as shit as it is, this seems hard to believe.

[–] qjkxbmwvz@startrek.website 21 points 12 hours ago

Yeah, the only thing I could imagine would be that image loading/processing uses an optimized library, but a single color is (unlikely but possibly) implemented poorly as a loop over every pixel, with some egregious overhead.

Most likely shit post though...

[–] PartiallyApplied@lemmy.world 32 points 13 hours ago (2 children)

Perhaps I’m just lost or the fool here, but wouldn’t it be usual that the overhead of spawning a thread would be much higher than just drawing the next pixel? If the post is true, could someone explain to me how a renderer with so much thread contention could optimize drawing on a CPU?

[–] PotatoesFall@discuss.tchncs.de 52 points 13 hours ago (1 children)

Yeah the explanation can't be true. It would take a single thread like 0 milliseconds to render the background image. That must be a shitpost.

That being said, I can imagine the first part being true due to some random windows fuckery

[–] kryptonianCodeMonkey@lemmy.world 14 points 13 hours ago* (last edited 13 hours ago)

Also the potential number of threads would be in the millions if you used the entire color pallette on your background (limited by your display resolution). Even if you aren't approaching that, surely most backgrounds have color values in at least the tens of thousands even with color compression. That just moves the bottleneck to your number of cores. Even the thread switching alone would have astronomically more overhead than just having one thread render the whole background.

[–] adarza@lemmy.ca 17 points 13 hours ago

sounds like shitpost material to me.

[–] mindbleach@sh.itjust.works 5 points 11 hours ago (1 children)

If the initial claim isn't simply bullshit, I'd suspect it's a tiling issue.

You could avoid special handling for solid-color backgrounds by using the image-as-background setup plus a solid-color image. And that image might as well be 1x1 px, right? But if image tiling is a loop that goes "open image, draw to buffer, close image" then you're waiting on the filesystem about a million times... while it's busy doing whatever the fuck Windows does at boot.

I have absolutely no idea if this is how any version of Windows does things. But even having pulled it from my own ass, I must say, it's plausible. It'd be quick to slap together with primitive DirectX. You'd never notice it for an image that repeats, like, twice. (Did Windows 95 default to the felt-green background, or that dithered-to-hell blue image?) As computers got faster and Windows ballooned, it could stick around for a while.

But it still might be bullshit.

[–] Zagorath@aussie.zone 2 points 5 hours ago

You could avoid special handling for solid-color backgrounds by using the image-as-background setup plus a solid-color image. And that image might as well be 1x1 px, right? But if image tiling is a loop that goes “open image, draw to buffer, close image” then you’re waiting on the filesystem about a million times

This makes sense to me. But unfortunately, according to a comment above, using a smaller image and tiling it is actually the solution to the slow loading.