13 ms·
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 em
by firefoxd 2mo 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.
- trzy 2mo agoThe visual assets alone will be tens of megabytes.
- iAMkenough 2mo agoFor a weather app, you should be able to get by with a couple base vectors you modify based on conditions.
- mort96 2mo agoOn disk yeah, sure. But you're gonna render them into a pixel buffer which lives in memory.
- samrus 2mo agoHow did applications do it before? Like in the 90s or 00s
- deleted 2mo ago[deleted]
- nicoburns 2mo agoThey had fewer graphics, and much lower resolution screens.
- Dylan16807 2mo agoWindows 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.
- mort96 2mo agoWindows 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.
- Dylan16807 2mo agoCompositing 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.
- vel0city 2mo ago> 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.
- Dylan16807 2mo agoI 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.
- mort96 2mo agoWAY 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.
- deleted 2mo ago[deleted]
- SV_BubbleTime 2mo agoDo 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?
- doikor 2mo agoEven if the app is no longer using that memory it is not released until Windows thinks another app needs it.
- vel0city 2mo agoAnd then people complain about how unresponsive applications are, all these little stutters as things pop in.
- mrheosuper 2mo agoOur 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.
- vel0city 2mo agoBandwidth and latency are two different things. The latency of handling things in system memory is still pretty different than the latency of handling stuff on SSDs.
- mrheosuper 2mo agoStill, it should not be more than few miliseconds, it's solid state. Im pretty sure most of the latency come from the software.
- Micrococonut 2mo agoShould be able to get by with using system graphics
- anonymars 2mo agoWhy, though? You need some icons and some map imagery, not 4K texture maps
- znpy 2mo agoIt 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 https://youtu.be/OG91c7xsNMc Needless to say, the guy knows what he’s doing.
- mort96 2mo agoPictures 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.)
- 201984 2mo ago>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.
- mort96 2mo agoHonestly if the image is of the current weather it kinda does. I don't mind e.g Apple's weather app design at all
- mrob 2mo agoYou 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?
- 2mo ago
- ashleyn 2mo agoA 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.
- fireant 2mo agoChromium 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.
- lelanthran 2mo ago> This took me down a rabbit whole. The rabbit was too hungry to even stop to chew you?
- fuzzfactor 2mo agoBeware the rabid rabbit and don't let your whole near his hole . . .
- firefoxd 2mo agoHaha, and it's far too late to edit!
- deleted 2mo ago[deleted]
- vrighter 2mo agoI 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
- rk06 2mo agoit 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