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.
They don't know why nerds care, but they will find out when they have to replace their PC just to have enough RAM to run a weather app.
But they won’t make the connection
Flashy beats functional nine times out of ten
Just look at the automotive industry
Many people enjoy a tasteful weather app. Granted a “minimal” UX toggle would be easy to add to reduce memory for those who cared.
I think the issue is with the recent definition creep of “tasteful.” Seems you might have the same mindset if you consider “minimal” to be the other option.
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.
> ~300MB is perfectly acceptable if it works well, looks good and does what it should do.
No it isn't. It isn't a word process for gods sake. It has one literally one job and 300 MB is like an order of magnitude off for that. This mentalty is the slippery slope that led us to the situation in the OP today.
Dunno. Many designers are pretty bad at UX. They’re OK at aesthetics, but that’s not the same thing.
You're off by 2 orders of magnitude if you think that a not completely incompetently coded weather app genuinely needs that kind of resources - even allowing for aesthetic choices and modern UX patterns.
gp was talking about 87MB without animations how do you end up at your estimate?
Ah yes, Microsoft is famous for good modern UI/UX.
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
You probably have a SVG renderer in memory already, and you already have a frame buffer and/or compositor buffer(s). Why should adding a graphical representation of the weather require more than a few KiB?
In a composited window system (i.e., any Mac since Mac OS X and Windows since Vista [I think]), rendering from an SVG would have to occur in a window buffer owned by the application, so it wouldn't save any appreciable amount of memory, assuming the buffer is the size of the window. The days of having an application draw directly into the framebuffer are well in the past.
Because a big picture looks pretty sometimes?
Not sure what you think "having an SVG renderer in memory" means exactly, typically the way an SVG renderer works is that you give it a huge chunk of memory and ask it to draw pixel data there from the SVG file. So even though the SVG is small on disk, rendering a 1000x1000 image from an SVG is gonna need a 1000x1000x3 byte pixel buffer (assuming no transparency or HDR shenanigans)
> 1000x1000x3
Cool, that's 3 MB
Which, if you'll do the math, is more than a few kB
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
IGPU systems on Windows usually set aside a fixed pool of memory for the graphics usually set by the platform. As in, if you need more video memory you need to go to the BIOS and reconfigure it. When you look at total system memory available in Windows it's the total installed minus however much you defined for the video memory. If you need to have the GPU mess with something you still have to a copy it from the system side to the GPU side. Applications can run out of video memory while still having available system memory.
It's only been somewhat recent that I've personally seen much hardware that allows for that reservation to be dynamically defined, and not with any Intel integrated graphics so far.
Iris Xe in 12th-gen do this, no idea since when it's added. There's still a minimum configurable shared allocation option in the BIOS, probably for legacy OS, but after booting Windows it can take up to 8 GB of the system RAM.
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.
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.
??? 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?
>it's difficult to find a moderately high end laptop
Terrible news for you, people work on dogshit dells given by their company and netbooks, not high end laptops. Macbook Pros, high end laptops, etc are exceedingly rare. (And can also deal with the high memory usage by virtue of having more memory).
>you want a background picture which fills the entire window
Which you rarely do, and also you don't develop for either, you're going to have a 1080p image at best, and then a bug report from that one client saying "background is blurry" in your backlog for the next 5 years.
>I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer.
Then you're using it wrong/using the wrong tool. Re-paying text layout at every render is already painful and it should be cached, your font rendering should absolutely be in a texture atlas.
>If DWM has only one buffer which all windows share
Slightly inaccurate in my answer there, but DWM only keeps one final composition buffer, which it handles itself from the various windows (that do have their own buffer, but only for their size and are only kept active if the window is visible.)
Are you disagreeing just to disagree? My numbers are obviously not going to fit every app in every situation, but I think they illustrate a perfectly realistic use case
For the text rendering thing, I think we're talking past each other? Nothing I mentioned implied redoing layout every frame? You render to a pixel buffer, upload that pixel buffer to the GPU, then just draw that texture every render.
For DWM, it sounds like you agree it has one shared composite buffer (which I didn't count in my calculations) and one front buffer and one back buffer per active application. Exactly as I said
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
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.
> 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.
How did applications do it before? Like in the 90s or 00s
WAY lower resolution screens so pixel and frame buffers were a tiny fraction of the size, non-composited graphical environments which meant there was one fewer frame buffer per window, and a visual style which typically emphasized large pictures/animations less.
They had fewer graphics, and much lower resolution screens.
Windows 98 SE kind of went overboard with the graphics (remember Active Desktop?), and a common screen size at the time was 1280x1024. But if you run modern stuff at 1080p (60% more pixels) or 720p (fewer pixels), you're not going to see comparable memory use.
Windows 98 wasn't composited, which makes a huge difference.
And to be clear, there's a ton of unnecessary bloat today as well. It's just that even a lean and mean highly hand optimized native app is gonna be way bigger today than it was then, due to compositing, higher resolution assets, higher resolution screens and different design sensibilities. But most apps aren't lean and mean highly hand optimized native apps so.
Compositing means you can excuse an extra dozen megabytes per megapixel of window size. The window in the article is less than a megapixel. That factors in the relevant part of screen resolution too. High resolution assets should scale alongside window size too, adding a fraction of the above dozen megabytes.
And I'm saying 98SE already had image-heavy design sensibilities all over.
You don't have to highly hand optimize to run a weather UI in a lean way.
> and a common screen size at the time was 1280x1024
Maybe if you were really rich and only used high end desktops. A lot of the computers I used back then were still 800x600, fancier ones were 1024x768. If you happened to also have a 2D accelerator card you'd potentially have 1280x1024. And lots of apps purposefully ran at a much lower color depth, it was common for games to run at 8 or 16 bit color mode.
I saw a lot of computers set to 800x600 but I don't recall any that couldn't be switched to at least 1024x768. Which is still quite close to 720p for making this comparison.
And yeah lots of fullscreen-ish things ran in lower color, but this is about desktop mode and I never saw a desktop mode that struggled based on color depth.
Cheapest local brand 15" CRTs could do 1280x1024 in early 2000s. because you weren't limited by the panel unlike LCDs.
You'd need better than perfect vision to be able to make use of it, though.
It's less of a question of if you could get a CRT that could do it versus having a PC with the video RAM and drawing performance to do it effectively at high color bit depth. Tons of extremely common desktops at the time shipped with only 2-4MB video memory with their integrated graphics chipsets. You're not doing 1280x1024 at 32-bit color with 2MB of RAM.
Early 90s maybe. By the end of the 90s and definitely early 2000s CRT screens were 1024×768 for the cheap crap and 1600×1200 for the high-end (with 1280×1024 as a mid-range).
Yeah sure you can take a machine with only 4MB of video memory and try to draw a 1600x1200 CRT, but you're not going to be able to have that many colors.
It often wasn't a limitation of your monitor, it was a limitation of your video adapter. Rattling off some common specs of monitors isn't telling the full story of what most random people were actually experiencing.
I still remember having to upgrade our main home desktop at the time of Warcraft I I'd release because it didn't have enough video memory to meet the 8MB minimum needed. That was in 2002 on a machine purchased with XP, a Pentium 4 HT with 512MB of system memory. Not necessarily a low end machine, but obviously not a gaming PC at the time and much newer than many systems sold for Windows 98.
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.
Our storage can transfer Gigabytes of data, do hundred thousand operations every second. The hardware is more than capable. If your software stutter when streaming few hundred KBs of data, it's on you.
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.