Comment by firefoxd
18 hours ago
This took me down a rabbit whole. Why can a simple single purpose app not be just a couple megabytes if not less? The popular options are electron 100MB+, or embedding python3 in your executable which is at least 40MB.
But if you build it natively, you should have all of Microsoft tools at your disposition, dlls and such. In theory, this should allow you to make a 1 mb app or less. But in practice, it's the worse option.
Pictures and frame buffers. If you're running fullscreen at 4k, you're probably gonna take two roughly 3840x2160x3 byte frame buffers for the window. Your designers want a background image which moves as you scroll in some parallax style; that's over 3840x2160x3 bytes more for the pixel buffer backing the image layer. And let's say roughly 50% of your screen is text with subpixel (aka full color) anti aliasing; that means another 3840x2160x3x0.5 bytes for the pre rendered text.
3840x2160x3x3.5. That's 87MB, in pixel data only. And it's a very minimal example; for the parallax image, you're gonna want the image to be significantly taller than the window; you're gonna want a ton of smaller (tho still high DPI) images for icons; a few different font atlases for different font faces you've loaded at once; maybe pre rendered pixel buffers for all sorts of UI components; etc.
And lord help you if your designers want any part of this to be animated.
(I'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory. Though applications may wanna store CPU-side copies as well for various reasons.)
>Your designers want
Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.
Assuming the app even works - since we're talking weather, allow me to offer an XKCD
https://xkcd.com/937/
Sometimes, you have to realize Hacker News is full of nerds that care about stuff nobody else cares about. Looks are so fucking important for many normal people. There's people that decide for or against a phone simply because it comes in a fun color.
2 replies →
Many people enjoy a tasteful weather app. Granted a “minimal” UX toggle would be easy to add to reduce memory for those who cared.
1 reply →
And sometimes your engineers need to be a LOT less stingy. 1GB is clearly overkill for an app such as this, but ~300MB is perfectly acceptable if it works well, looks good and does what it should do.
There is such a thing as overdesign, but when you’re building a modern application, you must trust your designer’s sense of aesthetics and knowledge of UX patterns—two things engineers are often notoriously bad at.
5 replies →
Honestly if the image is of the current weather it kinda does. I don't mind e.g Apple's weather app design at all
5 replies →
On GPU, won't it be like BC3 compressed texture?
> i'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory
Yeah this is irrelevant here, windows doesn't share both in 99 of the case.
What do you mean by "windows doesn't share both"? Windows doesn't get a say, Intel iGPU systems literally don't have video memory
2 replies →
DWM quite literally does that all the time. For the general case it allocates GPU memory, but also swaps to system RAM or uses it as a synchronization mechanic when you have one screen on an igpu and the other on a dgpu.
Good point. Though 4k image assets mean more that they look in 4k, not that their size is 4k. It might not be 87mb, but still way more than the couple mb I suggested.
??? Fast and loose is an understatement, at best it's a view from a rendering engineer that thinks all software acquires a DXGI swap chain and handles buffering itself, but it's flat out wrong and over two times too high at the very least.
* Not every app is full screen (especially not a weather widget.)
* Very few people actually have a 4K display. 1080p and 1440p cover over 75% of users already.
* You do not allocate a separate buffer for the main content and the parallax, applying a different transform does not need a dedicated buffer, just something the size of your asset. It can be a 640x480 upscaled asset for all you care.
* You also don't allocate a dedicated buffer for text rendering/hinting. Your text rendering engine keeps a texture atlas in a buffer which is eventually maaaaaybe reach a 4k texture if you display a TON of various glyphs, realistically they won't. DirectWrite will also share this atlas with other executables unless you explicitly ask for isolation.
* On windows, you write to DWM, which keeps a single buffet for all your windows. Every window does not pay that memory price. I'm pretty sure most compositors do something similar.
* I never said all software handles the swapchain itself. The front and back buffers are obviously not usually allocated in user code. But they're allocated nonetheless and contributing to memory usage.
* Not every app is fullscreen, but I was using a maximized app as an example. If you make the window smaller then yeah obviously the numbers get smaller proportionally.
* A ton of people have 4k displays, it's difficult to find a moderately high end laptop without a 4k display these days. In any case, that was the hypothetical example I used.
* If you have a window that's roughly 4k resolution, and you want a background picture which fills the entire window, that's gonna be a roughly 4k resolution pixel buffer (unless you stretch a smaller image, but that looks ugly).
* Depends on the text renderer. I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer. I know that this is the typical recommendation for handling high quality rendering of longer pieces of text with Canvas on the web too. Maybe a typical win32 app actually does render each glyph fresh every frame from a font atlas, I'm not familiar with Windows APIs specifically. I apologise for the inaccuracy if that's the case.
* I'm pretty sure you're wrong here? If DWM has only one buffer which all windows share, how does it handle the case where a partially obscured window goes unresponsive for a bit as the user removes what obscures it? In old school non-composited X11, the answer is that the X server paints in the newly revealed area with grey pixels and asks the window's process to re-render that region, causing a lingering grey region if the app is frozen. Preeeetty sure that Windows 11 doesn't do that. But do you have documentation on this?
2 replies →
Let’s maybe ease up on the designers, there. It’s not like they are the sole cause of bad decisions and developers always do everything right if not for their pesky demands. There are order of magnitudes more shitty apps caused by bad programming than by a designer wanting a larger image.
Plus, if you’re doing everything designers ask without questioning or collaboratively discussing the tradeoffs, there’s a non-zero chance that could be a you problem.
It wasn't actually meant to be a slight against designers, the choice to have a big background image is sometimes perfectly fine. You're a bad developer if you argue against it because it'll use some small amount of extra memory that your users aren't gonna notice.
A lot of these applications run in Electron or similar libraries where a whole new browser instance, with all its overhead, is stood up for each application. The simplest answer is we need to stop trying to use web technologies as a one-size-fits-all GUI toolkit.
Chromium is actually fairly efficient when shared across multiple applications. If the webview2, which is probably what the weather app uses, would not create a whole browser per application but rather just the renderer process and the rest shared system wide it would be a couple hundred megs at most.
it can be. you just need competence and incentive for it.
see File pilot as an example of what is possible when competent software engineer attempts it
> This took me down a rabbit whole.
The rabbit was too hungry to even stop to chew you?
Haha, and it's far too late to edit!
Beware the rabid rabbit and don't let your whole near his hole . . .
I embed lua when I need it. 200 to 400kb and we're off. And it's infinitely easier to interoperate with c than python is
The visual assets alone will be tens of megabytes.
Why, though? You need some icons and some map imagery, not 4K texture maps
Well, for example, Apple Weather has several different animations that are displayed behind the temperature for various weather conditions, such as rain, window, and snow, and those will need to be hi-DPI animations.
Its 2026. You need 4k assets for job security.
Should be able to get by with using system graphics
For a weather app, you should be able to get by with a couple base vectors you modify based on conditions.
On disk yeah, sure. But you're gonna render them into a pixel buffer which lives in memory.
14 replies →
Do all visual aspects of a weather app need to be loaded at once? Is the cost penalty loading a hundred kilobytes per image from disk really unacceptable?
Even if the app is no longer using that memory it is not released until Windows thinks another app needs it.
And then people complain about how unresponsive applications are, all these little stutters as things pop in.
2 replies →
It can, but you have to know what you’re doing and you have to know it very well.
Looking at the opposite extreme, the guy that originally wrote the windows task manager (the thing that popped put when you pressed ctrl+alt+canc) posted a video about cloning the windows basic text editor in a 3kb binary: https://youtu.be/OG91c7xsNMc
Needless to say, the guy knows what he’s doing.