Hacker News Reader

>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

Looks _are_ important. But "have everything animated" is not always best.

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.

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?

Dunno. Many designers are pretty bad at UX. They’re OK at aesthetics, but that’s not the same thing.

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

That still leaves a couple hundred megabytes spent on..?

> 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.

??? 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

In reply to user well_ackshually:

> Are you disagreeing just to disagree?

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.

On GPU, won't it be like BC3 compressed texture?

Hardware texture compression formats aren't really great for UI and result in visible artifacts, even with a good compressor -- mostly flat areas or gradients divided by sharp edges makes the compression loss more visible. BC3/DXT5 in particular can only encode interpolated colors between two endpoints in each 4x4 block, so two colored regions divided by a line in a third color gets smashed.

Alternate encodings like YCoCg tend to do better.

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.