this post was submitted on 06 Feb 2025
201 points (85.8% liked)
Curated Tumblr
4272 readers
5 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:
-
FOSS Android Recs per u/m_f@discuss.online: 1 , 2
Don't be mean. I promise to do my best to judge that fairly.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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?
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
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.
sounds like shitpost material to me.
Definitely a joke. If you used a thread per pixel, the OS would grind to a halt trying to spawn a million threads to render a typical photo. That's like GBs of RAM worth of thread overhead.