[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: 1769866661603.png (274 KB, 598x830)
274 KB
274 KB PNG
Why do nocoders so often complain about resource usage of programs they don't understand?
>>
>>108021440
>150MB for a fucking picture that gets covered up by windows anyway
He's not exactly helping his case here.
>>
>>108021440
they can probably sense how badly made, ineffecient and bullshitter does a search for a code sample created modern framework software is and how talentless the people generating software are these days
>>
>>108021456
this
clown show
>>
>>108021456
>first reply is a tech illiterate showing everyone he doesn't know how technology works
>>
>>108021440
I don't care. Make it work better, codemonkey
>>
>>108021440
I agree to an extent that unused ram is wasted ram, but 150 MB for a wallpaper?
>>108021470
how does it work then?
>>
>>108021470
No he's right. It's fucking ridiculous and I spent two decades writing sotware. Windows 95 had a requirement of 4MB of ram for the entire thing and yet it could do wallpaper, how the fuck does that need 150MB. Indicator something is seriously wrong there.
>>
>>108021440
Hyprland has ads, no thanks
>>
>>108021480
Because the image is always stored in memory raw, so it can easily be copied to the framebuffer. Do you think it is decompressed every vsync frame? That would be CPU inefficient.
>>
>>108021480
>>108021491
The tweet literally explain how everything works and why. This thread getting more than 0 replies is a blatant show of this board's tech illiteracy
>>
>>108021440
Damn, sure would be nice for the kernel to provide a way for you to "map" that wallpaper file into memory in a way can be evicted, so that it isn't the user's job to minmax their memory usage with settings you made up.
>>
>>108021491
1080p is 4x the amount of pixels compared to a 800x600 screen, everything was done in C++ back then with minimal language runtimes and now everything is a bloated js wrapper around a web browser. Optimization becomes secondary because modern hardware is so powerful it allows you to ship shit and it still can perform to a decent level so no-one spends any time making sure what they have built is working as well as it could.
>>
>>108021500
>>108021503
>>108021619
Ok, let's do the math then.
>3840*2160 pixels * 3 bytes per pixel.
How much do you think this is? 150MB?
No, it's 25MB. Suckerland is wasting 125MB of RAM for absolutely no reason.
>>
>>108021700
There is 6 wallpapers that switch periodically.
Congratulations detective!
>>
>>108021708
Lol old fags beat the fuck out.
>>
File: ebasedi.png (172 KB, 460x460)
172 KB
172 KB PNG
>>108021708
usecase for wasting ram on something you never see?
>>
>>108021470
>>108021503
>>108021500
Why the fuck would you cache the raw 150MB pixelbuffer you retarded cunt? There's no need for Alpha transparency on wallpaper, but even counting that in, just cache the downscaled buffer for the display resolution. On a 1080p 16:9 display, that's 7.91 MiB at 32 bit per pixel (including wasteful alpha), on 4K that's 31.64 MiB, on 8K that's 63.28 MiB. Removing Alpha, you can have 10 Bit per color HDR at 8K for 59.3 MiB. Have a 1GiB wallpaper for all I care, but why the fuck would you cache a pixelbuffer larger than the maximum available display resolution?

>>108021708
>>108021726
Jesus fucking christ you ignorant moron, there is still NEVER a need to cache more than 2 pixelbuffers in memory. You just load in the next pixelbuffer when you need it. Wallpapers DO NOT CHANGE on frame timescale, and the decompression and caching is a negligible workload over even a second. Have you heard of Asset Streaming in your life, Vaxry? You retarded little cunt. And even then, depending on your transition animation, it can be cut down even further.
>>
>>108021740
But people who use WMs just stare at their rice all day. They aren't doing any work with their computer.
>>
>>108021440
>Why do people that don't build cars complain about the build quality of the Tesla with body panels that don't even fit together?
>>
>>108021750
>There's no need for Alpha transparency on wallpaper
Are you fucking dumb? How am I supposed to see what's behind my monitor then?
>>
>>108021763
Buy a webcam and point it to where you want to look.
>>
>>108021763
Many ways:
>By taking a drill and tearing through it
>Building a double periscope
>Turning the monitor around
>Streaming with a camera on a stick
>Through the eyes of a telepath
>Hallucinating
>Just don't, your cable management makes me want to puke, you sick cunt
>Having me puke after I'm done 69ing your mother, to melt the screen off
>Your peepee contains your third eye, use the elongator
>By getting off your seat
>>
>>108021491
>how the fuck does that need 150MB
because an image is compressed on disk, and it isnt compressed when loaded into ram ready for usage. lets say its an 8K image with alpha channel, then you need:
(7680*4320*4)/1024/1024 = 127MB of ram
>>
>>108021861
But you only have a 4k monitor (or worse), so 75% of that ram is just wasted.
>>
>>108021893
agreed, its a little retarded. personally I just have a solid color as a wallpaper because there are windows in front of it anyways
>>
>>108021763
why would you need to see behind a window (assuming you meant window and not monitor)?

shouldn't all of your applications be tiled in a way that doesn't allow overlapping?
>>
>>108021927
>assuming you meant window and not monitor
No, I mean behind my monitor. If I use a transparent wallpaper I can see behind it.
>>
>>108021440
>unused (by your fucking wm) RAM is wasted RAM
It's like these faggots don't do anything with their computer except rice their stupid ass WMs. Some people run actual programs and would rather their RAM be used for actual, meaningful computations. Hell last decade or so you need all the RAM you can get just to run a fucking web browser.
>>
>>108021499
what do you mean ads? ads where?
>>
>>108021440
>150MB
>these wallpapers are quite high-res
Yeah no shit, like 10k or something?
Why the fuck?
>>
>>108021750
>You just load in the next pixelbuffer when you need it
Vaxry specifically stated he wants to avoid that to avoid stutters.
You fucking retard, how fast do you think it is to decompress a 4k image? It is more than one frame.
>>
>>108022007
>It's like these faggots don't do anything with their computer except rice their stupid ass WMs
True. Dasha was right about them
>>
>>108021980
again, usecase?
there's no reason your windows shouldn't just be tiled
>>
>>108022113
Tiled windows have nothing to do with this. What are you even talking about?
>>
>>108022097
Xorg doesn't have this problem.

>>108022016
The faggot that made this piece of shit wayland WM is trying to monetize it by putting ads in the free version and forcing you to pay to turn them off.
>>
>>108022155
Wait what?
>>
>>108022174
https://account.hypr.land/pricing
>>
>>108021440
Can they actually prove that they are preloading assets when more memory is available or are they just lying and full of shit trying to save face?
>>
>>108021440
>you don't understand we need to use 150MiB to show the wallpaper even though your screen is 1080p/24bit so the actual displayed pixels only need 6MiB
>muh unused ram is wasted ram
wasted ram is also wasted ram
>>
>>108022007
>Some people run actual programs and would rather their RAM be used for actual, meaningful computations
Parts of the DE that you're interacting with on a daily or hourly basis should always be pre-loaded into memory. 100MB is nothing if it means opening your application menu or file manager is instant or almost instant.
If you would rather wait 3-5 seconds for your menu/launcher to open or 3-10 seconds for your file manager to open then you can disable aggressive caching or use a lighter DE.

If you're in the market to only use one or two programs and not interact with the desktop in any way, then you're looking for a POS device and an OS/distro designed for POS.
>>
>>108021500
the issue is that it's storing both the entire image and the scaled image at the same time for no good reason. i would rather decompress/scale the image anew on resolution changes (which are pretty rarely used nowadays) than have the whole huge res raw in ram going unused 99.99% of the time
>>
>>108022280
Okay, so every time you plug in a monitor with different resolution you have to restart the whole compositor?
Face it, Vaxry is a genius developer, genius. And this is the best and the only correct way to do it.
You are just mad because he is a Pole with a jewish grandmother, which are the two ethnicities /pol/ hates
Hatred for Vaxry is not organic, it is pure seethe
>>
>>108022081
8K into a 32bpp buffer (not unusual to put 24bit pixels into 32bit memory addresses since it's often just faster to work with 32bit numbers than 24bit numbers) is 135MiB
>>
>>108022298
>you have to restart the whole compositor?
literally how did you get that from my post?
idk wtf the rest of your post is about
>>
>>108021440
Let's be honest, if you're using Hyprland you're not going to care about RAM usage. If less is used that's great but it's not a priority, it's a later optimization.
>>
>>108022313
You plug in a monitor with higher resolution, but you only have the downscaled image because you downscaled it to fit the original monitor and freed the original full resolution image/
>>
if decompressing your massive 8K wallpapers is too taxing for your users, you could supply it in a few sizes, like what icons do, or just cache the scaled version in ~/.cache so you don't need decompress/scale the full picture each time you start it (which is what windows has done since like '98)
>>
>>108022298
That's not even true, Hyprland does automatically detect monitors if configured properly. What you do is configure the known monitors with settings you want and the last option is detect automatically. It might not end up with the best settings but it's automatically detected.
>>
File: 1761217534277543.jpg (17 KB, 412x82)
17 KB
17 KB JPG
>>108022155
>>108022174
>>108022214
they give you a shitty experience on purpose to charge you for money. want more minimal experience? that'll be $5 more
>>
>>108022298
The fuck are you talking about? Does your compositor have to restart when you change your wallpaper?
>>
>>108022511
You can't change the wallpaper if you free the original wallpaper from memory, moron.
>>
>>108021440
>Hyprland
I do not give a fuck what Nazis say. Fuck off DHH and your cronies.
>>
>>108021470
>first reply to first reply to OP is a tech illiterate showing everyone he doesn't know how to optimize
Why. The Fuck. Is. The Background. 100 MEGS RAM!? If that shit is covered by Windows, despawn it.
>>
>>108022332
>You plug in a monitor with higher resolution, but you only have the downscaled image because you downscaled it to fit the original monitor and freed the original full resolution image/
No? Setting an image as a background image should create a copy of that image to some location. That copy is the "original" wallpaper image.
Based on that original image, each of your monitors would be assigned a compressed/resized image that's stored either in your memory or disk cache. So you would end up with an "unused" wallpaper.png (the original copy), and wallpaper-cropped-for-screen-1.jpg, wallpaper-cropped-for-screen-2.jpg, etc.

>>108022517
I really hope you're trolling.
>>
>>108022016
You will randomly get a pop up that asks asks if you want to subscribe to a paid blog. They try to say this isn't an Ad because it also asks for donations, not just shilling the paid blog.
>>
>>108022533
I'm confused, too.
>let's assume 4K background, or 3840×2160 pixels
>four bytes per pixels (8 or 10 bits per channel doesn't really matter)
>8,294,400 pixels
>33,177,600 bytes
>let's assume the worst - that the image is tiled and loaded into 2D VRAM, where it doubles in size
>approx. 66 MB
>in VRAM
>not normal RAM because properly tiled

What am I missing?
>>
File: file.png (338 KB, 1104x304)
338 KB
338 KB PNG
>>108022155
>putting ads in the free version and forcing you to pay to turn them off.
Why do you lie on the internet? You are just paying for support and conf files, there is no ads in the free version of Hyperland
>>
>>108021440
>people still crying about RAM in 2025
Even my old Q9550 shitbox has 16GB of ram.
>>
>>108022633
Then why does this Ad pop up on your desktop unsolicited? https://github.com/hyprwm/hyprland-guiutils/blob/c2e906261142f5dd1ee0bfc44abba23e2754c660/utils/donate-screen/src/main.cpp#L36
>>
>>108022567
>png
>jpeg
>when talking about framebuffer
I sincerely hope *you* are trolling
>>
>>108022686
Then KDE Plasma also has ads.
>>
>>108022355
Imagine using SaaS WM.
>>
>>108022721
So? Not relevant to this conversation. Don't use that gay shit either. Now that you have accepted defeat find or make yourself a better window manager like the rest of us.
>>
>>108022746
>buy product
>product's box has brand's logo
>OMG MUH UNSOLICITED ADS
>>
>>108022746
>make yourself a better window manager
Luckily the bar is very low.
>C++, for fucks sake
>>
>>108021750
Because you have three 4k screens?
>>
>>108022654
It's still 2025 where you are?
And people will always cry about RAM as long as it's being wasted. Even probably still cry when that stops.
>>
>>108022567
>PNG
>Lemme just draw this image on the screen
>First we need to decode the image
>Takes half a second
>Now we have a 100 mb image in RAM
>>
>>108022633
do they ignore the welfare forum issues?
>>
>>108022839
>Now we have a 100 mb image in RAM
... do you understand how pixel buffers *work*?
>>
>>108022850
You decode the image before you write it to the framebuffer
>>
>>108021750
Why don't you fix it?
>>
>>108022857
... one: no, you don't write it into the framebuffer. You'd write it into VRAM, which is different.
Two: target sizes are not random. It's width x height x pixel size in bytes (usually 4 bytes). For 100 MB with 4 bytes per pixel you'd need an image of 5000 x 5000 pixels.

What kind of screen do you HAVE that you need a 5000 x 5000 pixel image?
>>
>>108022786
If your shoe laces started giving you Ads you would not have bought them because they are meant to just sit there and be shoelaces. If your car has brand logo on it, you bought it for that Ad to be there, and is serving its purpose.
>>
>>108022886
>What kind of screen do you HAVE that you need a 5000 x 5000 pixel image?
So you're saying we're back to the real question of
>why the action of "setting a wallpaper" doesn't create a procedure that will resize the image to match your screen resolution

The user shouldn't have to manually resize images for each screen they use. The wm process of handling wallpapers should do that on the fly.
>>
>>108022886
>What kind of screen do you HAVE that you need a 5000 x 5000 pixel image?
Three monitors are not unusual. If they're 4k then that's 100 MB.
>... one: no, you don't write it into the framebuffer. You'd write it into VRAM, which is different.
Your frame buffer is a specific area of VRAM (or main RAM with an igpu).
>>
>>108022940
>The user shouldn't have to manually resize images for each screen they use.
OK. Sure. So we're back at >>108022611
>33 MB
>66 MB at most if tiled in VRAM
Still makes no sense.
>>
how much ram do you have? out of curiosity
>>
>>108022924
>started giving you
it's a one time screen when you first use it to make you aware of who made it. kys
>>
>>108023062
>shareware is okay if it's GPLed code
Nah kill yourself faggot.
>>
>>108023062
>one time screen
Ad
>>
>>108023116
Its not even just one time, they serve you this Ad do it twice per year https://github.com/hyprwm/Hyprland/blob/db6114c6c53edc4a60695a12d7f857308b6cd6cd/src/config/ConfigDescriptions.hpp#L1728
Can hyprtrannies stop the blatant lying in their coping?
>>
Hyprland also uses a shitton of VRAM.
Install Niri.
>>
>>108022113
>>108022123
like this?
>>
>>108023112
>shareware
who are you quoting?
>>108023116
the program's name is also an ad
>>
>>108021700
This can't be right. Then Windows 95 displaying a 1024x768 wallpaper takes up 2MB of RAM which is a quarter of the 8MB you had back then just for the wallpaper. And 8 is only the recommended, Win 95 boots with 4MB so it would be literally half the RAM just to display 1 image.
>>
>>108023508
But I solicited obviously. When you buy your shoestrings you are fine to see the brand in that moment alone.
>>
>>108023619
Windows 95 didn't use full-res wallpapers.
https://windowswallpaper.miraheze.org/wiki/Windows_95
>>
>>108023619
One: resolution was 1 byte, with a palette.
Two: they probably kept the decoded image in the pagefile.
>>
>>108022258
>even though your screen is 1080p/24bit so the actual displayed pixels only need 6MiB
The image only needs to reside in video ram
>>
File: 1769887494946.jpg (48 KB, 979x968)
48 KB
48 KB JPG
tis the fate of every kiss suckless diy hyper grifter inexperienced in general development to make something decent (e.g. jonathan blow, vaxry, htmlx guy, acerola to a certain extent) and be forever burdened by people who are simple themselves trying to sabotage the project 24/7 over perceived inneficiencies as the intelligence floor for interaction lowers and lowers until your issues section is filled with 10yo discord kids with delusions of grandeur who would never accept that they messed up something on their end because "they're too good for that" and don't understand the very basics of bug reporting and will just textually describe something with no real explanation like "why haven't you fixed x yet???" as if everyone knows what x is outside of their 5 friend clique, with no context
man no wonder OSS is so fucked, no matter what you do it always devolves to people who don't know anything trying to crash the boat into the iceberg just so the rafts can go their merry way instead of having a minor near collision with the entire ship
if you ever feel like you want to become one of these guys you should really just make a closed source startup for like 5 years and slooooowly start open sourcing your generic / supporting domains only after they're already mega polished and you're fine not really even listening to the community and just maintaining your own internal cherrypicked fork
>>
>>108021440
>arse linux
of course it's those people
>>
>>108023811
Whatever you say, schizo.
>>
File: 1769887893151.gif (3.25 MB, 256x320)
3.25 MB
3.25 MB GIF
>>108023832
>>
>>108022533
>>108022611
Why is the background a bitmap if it's solid color?
>>
>>108022097
>Vaxry specifically stated he wants to avoid that to avoid stutters.
In what world did you not understand the
>Wallpapers DO NOT CHANGE on frame timescale
part?
And if there is a specific condition requested by some mentally ill ricer that needs you to cache the wallpapers for iterating through them frame by frame, just handle that instead of shitting up ALL scenarios with a minimum 2x additional memory overhead over whatever is actually needed in memory at the time.

And better still, you can still just store uncompressed pixelbuffers on disk if you REALLY REALLY need to cycle through wallpapers every single frame.
But chances are that hyprland probably doesn't even support cycling through wallpapers on frame by frame basis.

>>108022804
We all know we're talking about the general case. Nobody's talking about a specific setup where wallpaper cycle times are perfectly synced across three monitors to force loading all 6 wallpapers into memory for a few frames to do a switch. The whole point is the wastage. A 1080p single desktop monitor setup with cycling disabled shouldn't be caching more than 6—8 MiB of pixelbuffer data.

>>108022871
Because I don't care about or use hyprland.
>>
>>108023170
I spent more time writing this reply (let alone reading your drivel then I have in seeing a donation box request once or twice a year on a tool I’ve used for three years
Kys
>>
I have 16gb of ram I couldn't possible care less about memory usage.
>>
File: file.png (8 KB, 1103x74)
8 KB
8 KB PNG
>>108024342
Yep. Minimum temporal resolution is in seconds as expected.
>>
>>108021470
low quality ragebait
>>
>>108024357
I fucking love how everyone is focusing on
>muh RAM size
, but never about
>muh cache usage

>t. 64 GB RAM masterrace, you can all suck my dick
>>
>>108022611
>>in VRAM
>>not normal RAM because properly tiled
Oldfag here.
This was how it worked last time I did it in the 00's.
Has something changed or is technology regressing?
>>
>>108022174
Learn the difference: software made in the EAST side of the Bay Area, freedom, hippie, ideological. Software made in the South Bay: corporate, closed. Software made in San Francisco: gay, slow, aesthetics focused, they want their VC money back
>>
>>108024403
youre retarded
>>
File: swizzle_example.png (266 KB, 1046x800)
266 KB
266 KB PNG
>>108024433
>how it worked
How *what* worked? That you would supply data over the bus for every frame? Because nowadays you have enough memory on the GPU to allocate memory and store assets in it directly, and there's essentially two types of memory:
>linear: used for buffers that are written to directly by the CPU. Not optimized for 2D access, takes the same amount of memory as in RAM
>tiled: used for 2D textures, automatically tiled by the driver. Cannot be written to directly, requires additional memory for mipmapping (2D engines that don't use 3D or distances usually create one 2D image and load in all sorts of subimages into it, this is called atlasing).

Essentially, for images you want to make sure your shit is always tiled, even if it requires more memory.
>>
>>108024524
>You're
>>
>>108024531
That you loaded all your textures into VRAM, not system RAM.
>>
>>108022097
And that is not something that should be causibg stuttering
>>
>>108021440
sorry faggot, i miss the meeting where we decide to learn to write fucking code in order to compare the resources needed for some tasks, what the fuck is your problem? you fucking idiot. I dont need to code a fucking kernel to critisize if my OS boot slower, or if my OS doesnt load the fucking file manager as fast as i experienced before, its common sense.
>>
>>108023331
What does this have to do with anything? We're discussing the fact that a wallpaper with transparency allows your monitor (physical video output device) to be see-through.

>>108023619
Windows 95 mainly used tiled wallpapers which were mostly 32x32 or 48x48 images, or it used a single color background. This doesn't require much memory because you're just repeating a pattern. It only had a few 640x480 wallpapers to pick from by default.
>>
>>108024569
Some years ago I read about some Linux compositors that kept a copy of the frame buffer in system RAM, so that they wouldn't have to read that shit back for small changes. But nowadays you have shit like resizable BAR so that you can perform tiny changes to VRAM without having to issue full DMA copies.
>>
>>108024348
So that is an excuse to be homosexual? Wrong again gaywad
>>
>>108024627
I have too many windows open so you can't see it.
>>
>>108025557
>I have too many windows open
close them and open linux, this isn't a windows thread
>>
>>108021456
it's ricer wm
they take screenshots with one single floating window in the middle all the time
>>
>>108021757
I disageee
>>
File: 1000004165.jpg (46 KB, 945x630)
46 KB
46 KB JPG
Vaxry seems like a massive insufferable faggot who suffers from a severe case of unwarranted self importance. He acts like he has a massive chip on his shoulder.
>>
>>108025786
He kinda seems indian, desu.
>>
>>108025865
this makes onions and desu.
>>
>>108025865
I'm pretty sure he is central European. Polish or Czech or something.
>>
>>108021440
This post should have gone in the /sfq/ (stupid fucking questions) thread.
>>
>>108021440
A program so mysterious that every program before it that did the same thing did not have this problem. Fix your shitty code.
>>
File: 1694817900461217.jpg (34 KB, 600x315)
34 KB
34 KB JPG
>>108021440
>"unused RAM os wasted RAM"
>>
>>108021440
Remember when dedicated GPUs had dedicated accelerators for 2D rendering on screen?
>>
File: ARGYLE.png (200 B, 32x32)
200 B
200 B PNG
am i the only one who still uses tiled wallpapers?
>>
>>108021861
Nigga just use DLSS and store only 640x480
>>
>>108021440
Why do troons think you need a degree to know your program is shit.
>>
>>108028775
Because they are narcissists with really weak egos, and to defend it they always assume that someone else is at fault. It's the number one reason why I have absolutely no problem carrying off troons and their supporters to actual concentration camps where they can live out the rest of their days in misery.
>t. grew up with a narcissist
>>
>I need 150 MB for the wallpaper
An uncompressed 8K wallpaper is 127 MB, wtf are these retards doing, not rescaling to screen resolution?
>>
its amazing he can say that last line and not make the connection
>>
>>108022097
codelets like (You) can't into threading lmao
>>
File: 2026-02-01 10.00.39.png (21 KB, 579x211)
21 KB
21 KB PNG
Trying to find OP's tweet lmao wtf
>>
>ramlets itt
>>
>there are no poorly written programs, you just don't have enough RAM
This is what retards actually believe.
>>
File: 2026-02-01 10.13.43.png (29 KB, 589x239)
29 KB
29 KB PNG
He's a degenerate Polish moron lmao.

>wastes 3 seconds of boot time loading wallpapers in a blocking way
>can't imagine not reloading/rescaling all wallpapers in a blocking way when "needed"
>>
i have a daemon fill a tmpfs with urandom files dynamically to keep my ram full at all times because unused ram is wasted ram ;)
>>
>>108029059
how come nothing else has this problem?
>>
>>108022097
>how fast do you think it is to decompress a 4k image
It's fast as fuck. Something like 40ms for a PNG, so easily covered with a fade animation or such.
If you want it to change on each frame, you have a video... Then you use a video format like h264 which is more efficient to both store and decode (And you hand it off to GPU as to not be wasteful)
>>
X allows me to have my background handled by a completely separate process from the WM and does not have this problem.
>>
>>108029079
i get 107ms average decoding of their first wallpaper (8K) using libpng (single threaded)
>>
>>108029059
>>108029077
Because he's being retarded.
But the question is, how did he manage to make it take 3 seconds?!
Is it not a clue that you can open a photo on your PC or even online in your browser, that's usually 16MP or more, and it opens almost instantly?

>>108029118
Oh cool, where did you find their wallpaper?
But that makes sense, loading from disk and resizing should be less than 100ms each... So how did he manage to make it 10x slower than it should be?
>>
>>108021440
And he's absolutely right.

>>108021456
I preload swayimg to roughly 4GB when I use directories, this way I move through high-res pictures effortlessly.

Empty RAM should not be allowed, it costs literally zero extra energy and makes everything faster.

'Optimized' is the semantics game being played here.
I rather have my RAM filled so everything feels near instant, which is my definition of an optimized experience.

Benchmark fags feel the word "optimal" entails low RAM usage. So when the computer does need RAM, it takes 10ms less time to fill. As opposed to it taking 10ms extra to wipe the less necessary data from a fully used RAM.

Even worse, most gamer fags think they need 32GB, if you'd remove 24GB they wouldn't even notice.
>>
>>108029077
Skill issue. Programming is a constant IQ test and that vaxry is clearly not scoring very high.
>>
>>108029154
>Oh cool, where did you find their wallpaper?
https://github.com/hyprwm/Hyprland/tree/main/assets/install
>>
>>108029155
>and makes everything faster
Opinion discarded, I'm laughing in your face.
>>
>>108022097
more than one frame, but less than the time it takes for a modern monitor to sync to and display an image when turning on or changing resolutions
>>
>>108029155
there's a difference between precaching a folder of pictures for quickly flipping through them in an image viewer, and precaching a bunch of wallpapers which change every few minutes on a cycle. one is useful, the other is wasteful. i don't need a wallpaper that won't show up for 10 minutes to be in ram ready to go
>>
why can't he load the next image into memory in a background thread without any stuttering?
>>
>>108029155
no you mongoloid retard, I want you to not shit up my ram so I can fill it with other programs. what's so hard to understand?
>>
>>108029208
So what do you do in the meantime?

Job in the background, whatever. What do you do in the foreground?
>>
>>108029219
>What do you do in the foreground?
React to user input so everything stays responsive and he can work without any stuttering?
>>
>>108029227
>monitor configuration changes
>doesn't display anything
>user hits random hits without any feedback
Genius.
>>
>>108029212
>>108029179
must be freeing being this retarded.
the abundance of ram makes all your arguments mute.

but please do tell, what is your real usecase where your computers absoutely shit the bed if pre allocation is a thing.
>>
>>108029219
>What do you do in the foreground?
You keep the UI running without waiting for a stupid wallpaper to be loaded lmao.
>>
>>108029245
>the abundance of ram makes all your arguments mute
Keep believing that, retard. We need more laughter in this world.
>>
>>108029155
>>108029245
But it's not faster. In fact, it's very slow.
High ram usage and being slow (because of inefficient computation) have the same root cause, laziness/incompetence.

In fact we have the story of how vaxry came to waste this ram:
>retard codes his compositor, adds wallpaper functionality
>fucks up coding the loading of wallpapers by blocking main
>fucks up to somehow make a <0.3s process take 3s
>retard adds cache to cover up his failure

This is more common than cache being used for good.
>>
>>108029219
A fade animation can cover it easily, how long do you think it takes to decompress nigga?
>>
>>108029255
i'm still waiting for your real usecase example.
>>
>>108029245
>the abundance of ram makes all your arguments mute.
have you seen the current ram prices?
>>
>>108029261
>keep browser with hundreds of tabs open to listen to music while playing one (1) video game.
literally the most common usecase of all time
>>
>>108029258
>>108029237

>>108029261
Why would I help out a retard?
>>
>>108029267
and where in this usecase does prefetching make your system unstable or slower?
>>
>>108021456
>>108021440
Did I hear that right? 150 (one hundred and 50) MEGA bytes? What a waste!!!! Don't these NERDS understand every crumb of a byte counts?
>>
>>108029219
>>108029237
Use your common sense anon. You keep drawing, keep being responsive. For the wallpaper you can draw gray pixels until it's loaded, or just do what windows does and don't give a fuck and display the old wallpaper incorrectly until it's loaded.
>>
>>108029273
I didn't say it makes my system slower, I said your app doesn't own all of my system memory. I didn't buy RAM so your stupid app can hog all of it, I bought RAM so I can use many apps at the same time.
>unused RAM is wasted RAM
This argument is retarded because who said the RAM is unused? It's used by other apps you retard.
>>
>>108029291
So it doesn't make your system slower.
It's even safe to say it makes your system faster.

RAM can be instantly flushed if necessary.
I repeat, when necessary, RAM is allocated to processes that absolutely need it. Some wallpaper eating 150MB is a non-issue. Memory leaks where Firefox or whatever eats up 30GB of RAM is.

And the fact that so many here are livid on this tiny issue is moronic. It almost feels like audiophilic levels of retardation. But then again this is /g/ so why would I be surprised.
>>
>>108029275
I'm starting to suspect that this is vaxry himself shitposting in his own thread lmao. The problem, you hack, is that pre-loading all the wallpapers at boot to keep them in RAM shows that you're a low skill moron who makes terrible decisions. What if you had 100 wallpapers on rotation, would you take a minute to fill up 8 GB of RAM with them?
>>
>>108029155
Now realize you could prefetch 4 times more if you weren't as retarded as vaxry. That's what wasted RAM is.
>>
>>108029319
>RAM can be instantly flushed if necessary.
It can't. It's already allocated and the OS has no way of knowing what allocated RAM is important and what isn't.
It's not like the RAM wasted on wallpapers can be automatically freed once you're low on RAM.
>>
>>108029320
you lost
>>
>>108029319
>someone doesn't know what page tables, TLB pressure, and cache invalidations are
>probably also doesn't know the difference between reservation and commission
>which is why everyone calls you a retard
>>
>>108029338
Yeah it's 100% vaxry lmao
>>
>>108029319
>It's even safe to say it makes your system faster.
>RAM can be instantly flushed if necessary.
It can be, but it's usually not, in fact what usually happens when you run out of ram is that something is slowly and painfully swapped to disk and everything grinds to a halt. And that's the better option.

>>108029344
>>108029320
It seems like it, because the posts are retarded, he's getting angry for being called out while we just laugh.
>>
im a tech inept retard yet not underage so i have personal experience how software in the past was faster despite running on magnitude slower hardware. this alone proves modern software devs incompetent.
>>
File: hero_data.png (18 KB, 1100x610)
18 KB
18 KB PNG
>>108029380
>how software in the past was faster
Oh, believe me, we had stinkers too.
>>
>>108029380
i should add that the one thing that has improved over the years is load times but our boys are doing their best bring those back to mechanical drive speeds again.
>>
>>108029397
That was solely the cause of SATA SSDs. Modern NVMes are completely underutilized because our kernels are mentally stuck in 1970, and no, Ioring/io_uring didn't change that either. At most you now have kernel threads blocking for opening a single file instead of a user thread, but they are still blocking for single files, and you still cannot tell the kernel to map a bunch of files into your address space.
>>
>>108021478
Fork it and do it yourself retard
>>
>>108029434
>do my job
I guess Linux really doesn't want any new users. That's fine. I can just debloat Windows, while you can tinker on an OS no one will ever use because you want people to do your job.
>>
File: 2026-02-01 11.45.37.png (829 KB, 879x838)
829 KB
829 KB PNG
>>108029380
Honestly even though in this case it's definitely a matter of incompetence, even when we're competent we might not realise that we do something painfully inefficient and the fact that we develop on fast machines with lots of RAM hides inefficiencies.

For instance until yesterday I was continuously scanning a process' memory for allocations, and for each allocation I would print a label showing information (the text in the coloured rectangles) to a string every time the memory was scanned. It made sense when I didn't scan continuously or when I only had barely 2000 allocations, but when I tested on 300,000 allocations it was quite slow, so I changed it to only make the string if the rectangle is on screen and is large enough. In theory I could have done this from the start, but I didn't think about it until it became slow enough, and because my PC is fast it took a lot to make it slow, whereas if my PC was much slower I would have done something about it earlier. So my code is generally less efficient because the power of current hardware hides inefficiencies.
>>
>>108029434
>just fork it bro
>no I won't merge your changes into my branch
>just maintain your fork forever
The FOSS way
>>
>>108028934
>not rescaling to screen resolution?
From what I've read around it seems like there's multiple copies of the wallpaper stored in memory for some reason. That's why apparently the new async resource loader thingy will make it more memory efficient.

>>108029059
This is such a retarded argument.
Plugging in new monitors on any OS will have a 1-2 second delay anyway from what I've noticed. No matter if it's Windows or Linux, no matter the DE used. And the delay is even longer for TVs since they love displaying their logo for another 3 seconds. And during all this time of the display being blank or only displaying a logo the OS can actually utilize it (you can move windows and the cursor to it). So there's ALREADY a 3s delay which exists during which he can load in any assets he wants without it being noticed by the user.
Besides, plugging in a display is not something that people just do instantly and expect to use their OS immediately. You usually fiddle with wires or something. You're not actively using the PC at that time. Even your entire OS freezing for a couple of seconds would be irrelevant.

>>108029380
>how software in the past was faster
It wasn't. Windows was fucking slow in the 98-XP-7 era. Even in a VM on new hardware XP is noticeably less snappy than modern Linux.
>>
File: 2026-02-01 12.07.45.png (89 KB, 592x551)
89 KB
89 KB PNG
>>108029542
>there's multiple copies of the wallpaper stored in memory for some reason
I'm not sure but it seems like those 5 wallpapers are the ones in that folder lmao: https://github.com/hyprwm/Hyprland/tree/main/assets/install
>>
>>108029542
You are right for 7, but completely wrong for xp. I am capable of running xp in a VM where host is a 18 years old laptop with 3GB of memory, zero stutters even without guest additions.
XP really is a miracle of engineering, especially sp3
Linux lags a little even on a modern host with guest additons.
The thing is I think XP draws everything using CPU, while Linux desktop uses a gpu which is considerably harder to emulate.
>>
File: image.jpg (857 KB, 2048x1554)
857 KB
857 KB JPG
>hyprland has retarded hungarian notation conventions like beginning classes with the letter C
eww, no thanks.
>>
>>108029608
>The thing is I think XP draws everything using CPU, while Linux desktop uses a gpu which is considerably harder to emulate.
XP doesn't have a compositor at all, while on linux it's optional. if you don't use a compositor on linux, the gui should be just as responsive as XP in a VM without graphics acceleration. if you use a compositor without a gpu, then it will be done using llvmpipe, a software renderer, which will require much more cpu time to render anything
>>
>>108021456
Even Windows 11 only uses 15mb
>>
>>108029608
I really disagree on XP. Maybe it's the fact it's almost exclusively single threaded, or the fact it "uses the CPU to draw things", or the difference in speeds between old ntfs and new ext4/btrfs, but everything just feels so fucking slow when using it. Mainly the rendering layer actually.
Like opening a folder. On XP when I open a folder, the current folders file icons are unloaded, the file list becomes blank for the next 300ms or so, and then the new folder file icons appear. This is not even counting thumbnail loading/generation. Meanwhile KDE's Dolphin opening the "same" folder only displays a "blank page" for 16-32ms (1-2 frames on 60Hz), then within the next 32-64ms thumbnails are displayed. So Explorer in XP feels 3x-6x slower than current Dolphin where folder navigation is a 50-100ms process. This is not even looking at more lightweight file managers.

That's at least how I remember it. It's been a few years since I've used XP be it on bare metal or VM. So I'd have to double check if what I'm saying is right.
>>
>>108029388
>reading 1 byte at a time
this is something Linus would go ballistic over in the past
is this decompiled from some notable software?
>>
>>108029388
My favorite childhood software for making games was written in visual basic and used win32 api and GDI functions (software rendering)
Also it didn't support png sprites, but only GIF. and it didn't support transparent GIF either, you had to have two gif files, one normal and one mask.
https://github.com/smbx/smbx-legacy-source
>>
>>108030059
Warlords Battlecry 2. If there are players of that game who ever wondered why loading your hero list games so fucking long ... now you know:
>reading 1 byte at a time
>>
>>108028983
lmao
>>
The more RAM you use the more power you use, because you have to write that data to RAM and transfers use more power than idle.
It will also impact memory latency elsewhere because these stupid reads and writes you scheduled for no reason (like 150MB of wallpaper) needs to contend with same bus as other actual important stuff.

And the impact on caching? whew. Nothing like replacing all your cachelines with a static wallpaper every few mins. My god
>>
>>108030394
I think they're just loaded at boot and kept in RAM forever.
>>
>>108030394
Stop watching N64/NES/SNES optimization videos. Cache is literally irrelevant in multiprocess operating systems because it will become invalidated every context switch anyway.
It is impossible to optimize for this.
>>
>>108030435
>Cache is literally irrelevant in multiprocess operating systems
>what is L1/L2 cache
>what are process-aware TLB entries
>why are the Factorio devs aware how much they fucked up, but are powerless to do anything about it
https://factorio.com/blog/post/fff-215

You are such a retard that I could kill you, and not even the cops would miss you.
>>
>>108021440
what about not needing the ram in the first place
>>
>>108030435
multiprocess systems use cache coherent interfaces and snoopable caches at most layers of hierarchy.
They absolutely do not invalidate everything upon a context switch. Modern systems allow multiple contexts sharing a cache while their data remains isolated, they do not invalidate as a security mechanism
>>
>>108030560
>>108030469
Do you realize that you have like 300 processes running right now? Cache is not big enough to have separate process-aware entries.
>>
>>108021491
>No he's right. It's fucking ridiculous and I spent two decades writing sotware. Windows 95 had a requirement of 4MB of ram for the entire thing and yet it could do wallpaper, how the fuck does that need 150MB. Indicator something is seriously wrong there.
/thread
>>
>>108030596
More like 160, with most of them sleeping so hard the kernel doesn't even bother waking them up because there's no reason to. About 75% have about 1% CPU load, for whatever reason, oh, *and it doesn't matter because the processor only keeps data in the cache that's actually being used*, not the entire working set.

And now fuck off and fix your fucking compositor.
>>
>>108030628
You do NOT need cache friendly compositor. It would change absolutely nothing. If your hardware is made in this decade, then Hyprland will only ever peak at 5% CPU usage, maybe 10 if you are REALLY unlicky. Don't fix what isn't broken.
>>
>>108030647
Vaxry, optimize your shit. I installed your compositor on a 4 year old computer and got <15fps and constant segfaults. Then I deleted it.
>>
>>108030668
Not Vaxry, though I am flattered that you think I am him.
Your computer must be SHIT then. Some Chinese knockoff brand.
>>
>>108030647
imagine thinking that's an acceptable amount of cpu time for a window manager
my wm has consumed 16 seconds of cpu time... over 7 days. if that was constant that'd be 0.003%
>>
>>108030710
X11 WM != wayland compositor. Retard.
compositor is like WM process, Xorg process and Xcomposite process COMBINED.
>>
>>108030647
>source: trust me, dude
For the record: it would absolutely drive up CPU usage for the simple reason that the kernel cannot tell if the CPU does actual work or just waits for data to arrive in memory, and it cannot avoid them, either - the context switches alone would be several orders of magnitude more costly than just waiting for a single read. Your only hopes are out-of-order execution and hyperthreading, and both can only work within the current process context.

But let's say that Hyprland somehow breaks the laws of physics by NOT driving up CPU usage - what about the programs whose data you've just evicted? Are they capable of breaking the laws of physics, too? Why, do you think, does memcpy switch from normal to non-temporal writes that don't pollute the cache once certain payload thresholds have been reached?
>>
>>108030728
>But let's say that Hyprland somehow breaks the laws of physics by NOT driving up CPU usage - what about the programs whose data you've just evicted? Are they capable of breaking the laws of physics, too? Why, do you think, does memcpy switch from normal to non-temporal writes that don't pollute the cache once certain payload thresholds have been reached?
Who cares about other processes? Not my process, not my code, not my problem. Go open a bug report on their bug tracker and notify them that their shitty program is spiking your CPU
>>
>>108030722
if i include X then it comes to 0.7%. i don't use a compositor
>>
>>108030739
>Who cares about other processes?
The data and instruction caches, the TLB, the memory bus and prefetchers, our broken kernel infrastructure that still blocks on I/O every so often, the user, actually competent developers ... in short: you'd have to be an incompetent autist not to care about other processes.

Now here's a counter-question: who cares about the opinions of incompetent autists, as you have shown yourself to be one? Because I don't.
>>
>>108021500
>Because the image is always stored in memory raw, so it can easily be copied to the framebuffer.
Texture compression exists. I tried compressing those wallpapers with ASTC. With 8x8 block compression I get about 8MB per wallpaper:

16:14 anon@anons-pc:/tmp/hypr
$ ls -lh wall*
-rw-r--r-- 1 anon anon 8.0M Feb 1 16:12 wall0.astc
-rw-r--r-- 1 anon anon 14M Feb 1 16:09 wall0.png
-rw-r--r-- 1 anon anon 8.0M Feb 1 16:14 wall1.astc
-rw-r--r-- 1 anon anon 5.9M Feb 1 16:09 wall1.png
-rw-r--r-- 1 anon anon 7.7M Feb 1 16:13 wall2.astc
-rw-r--r-- 1 anon anon 27M Feb 1 16:09 wall2.png


You could just mmap those .astc files and directly upload it them the GPU whenever you need them.
>>
>>108030952
How the hell is ASTC *smaller* than PNG? WTF
>>
>>108030973
>how the hell is a lossy format smaller than a lossless format
Y'all are fucking retards.
>>
>>108031006
Oh I assumed that you were not a retard and did not use a fucking lossy format for a png wallpaper.
>>
>>108031013
One: NTA.
Two: your retarded eyes wouldn't see the difference anyway. Just shoot yourself now.
>>
File: A.png (3.34 MB, 2215x1630)
3.34 MB
3.34 MB PNG
>>108031006
Here's two 100% crops of wall2.png. One's the oiginal the other's been encoded to 8x8 ASTC and then decoded. Tell me which is which.

1/2
>>
File: B.png (3.71 MB, 1990x1532)
3.71 MB
3.71 MB PNG
2/2
>>
>>108028643
>bro just use vram instead
retard
>>
>>108031104
>>108031132
Erm: >>108031020
>your retarded eyes wouldn't see the difference anyway.
>>
>>108031132
This one is better
>>
>>108022298
Vaxry man, I thought you were cool with you C++ rewrite, but you're just another schizo...
Fix your design man, it sucks
>>
>>108022721
You can completely disable the kde e-begging though.
>>
>>108021440
I can't code a web browser but I can still see that there's something wrong when Firefox is using 44GB of RAM and 80% of my CPU
>>
>>108031348
luddite dumbass
>>
>>108031666
Are you just using random insults thst make no sense, you cretin?
>>
>>108031688
Of course not, you lolly-gagging feet-sniffer
>>
>>108029155
defending vector shit wallpaper which is a png with 13.5MB size
there is no fucking reason to use png for the wallpaper when the wallpaper is already enormous
even if the wallpaper would be exact fit for the display it would be fine in jpg
just export a fucking jpg version for wallpaper usage and keep png for editing purposes only
BUT another thing is that it's fucking vector shit
it doesn't need to be a fucking picture, it could be rendered as vector graphic, no fucking enormous memory needed to store enormous picture that is mostly empty
I haven't seen such retarded choice in a long time
nothing makes sense here
the easiest optimization even disregarding the vector shit would be to
downscale the wallpaper to fit the display when you change your resolution, keep it and use it (on demand)
or downscale the wallpaper into common resolutions and choose the closest fit (ahead of the time)
use jpg, because png doesn't make sense
just converting it to jpg at 90% quality in this retarded 8k resolution makes it 1.3MB, it's 10% of the size
if you downscale it for the user first into for example 1440p (sensible resolution) and to jpg, it's 225KB
for 1080p it's 150KB
that's 1% of size for 1080p which is high resolution already
if you just do the braindead optimization (having several versions ahead of the time) and choosing the closest fit to user resolution it's 50-100 times less memory for the most users
this shit is undefendable
the choice and the way wallpaper is used is unhinged and retarded
anyone that says it's fine to waste that much memory for a fucking picture you see once in 30 minutes when you alt tab is a retard
you don't even need to do some things that someone suggested and calculating which rects are covered and which are exposed and doing some tedious shit
the problem is TRIVIAL, it's not even an optimization, it's FUCKING COMMON sense
anyone that defends the usage of mem for that VECTOR SHIT wallpaper is a retard and should just kys at this point
>>
>>108031688
sorry but I got good digits and you didn't therefore me based and you cringe
>>
>>108021440
Nocoders are not human, it should be a bannable offense to be a nocoder on /g/
>>
>>108032334
Fair enough. Digits don't lie. I'll lower my voice.
>>
>>108023708
Cool little wiki
>>
File: mem.png (44 KB, 938x332)
44 KB
44 KB PNG
To be honest I don't know what this means.
I uninstalled swaybg and restarted between screenshots.
>>
>>108035947
>wallpaper is bloat
Based
>>
>>108035947
>>108035964
Swaybg seems to be using 14mb for a 2560x1440 wallpaper. Coinciding with my original screenshot.
>>
>>108030647
>If your hardware is made in this decade, then Hyprland will only ever peak at 5% CPU usage, maybe 10 if you are REALLY unlicky. Don't fix what isn't broken.
Holy shit this sums up exactly what is wrong with every retard on this board yelling "luddite!!!" and "muh RAM!!!".

It's fucking embarrassing that my old 386 with a full blown DE somehow manages to run better than this modern hipster wayland bullshit on a modern system. Where do these dumb faggots come from that think hogging 5+% of a multi-core 4+Ghz CPU while taking over 200MB of RAM is acceptable in any world?

No wonder they're LARPing as programmers in the Linux world. They couldn't get a job with an actual software company.
>>
>>108036093
>They couldn't get a job with an actual software company.
Cutler got a job with Microsoft, the fucking retard. The bar has always been ridiculously low.
>>
>>108036121
>He got a job with microsoft
Do did every other dumb pajeet. They wouldn't have gotten a job with microsoft in 1999. Since they wouldn't have gotten within a mile of the front door.
>>
>>108036131
>They wouldn't have gotten a job with microsoft in 1999.
Sure would've. ReadFileScatter/WriteFileGather was introduced in 1997.
>>
>>108036162
Alright thanks for outing yourself. No one would defend this absolute faggot that can't code for his life but himself and his gay little discord fan club.

Wayland is shit and your little WM that eats RAM because you're too retarded to do anything correctly is shit and will always be shit. Imagine paying $5 a month to access a private forum full of trannys.
>>
>>108036168
>No one would defend this absolute faggot
In what universe did I defend him? All I said was that standards have been ridiculously low for decades.
>>
>>108021440
Fucking incompetent devs lol. Doing a shit job and transferring every cost upon the consumer to pay for newer (jewer) hardware.
>>
>>108036208
Cry more about it.
>>
this is nuts
>>
>>108036093
i don't know why but /g/ has really gone to shit recently



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.