Load wallpapers with the same sourceSize, set to a square with a side length based on the largest dimension of the screen resolution. This required quite a bit of "pass it on," but the results are worth it: this saves 60MB of RAM when using the default wallpaper on the BQ E4.5. Wallpaper.qml is updated to be smart enough to warn a developer when they use it correctly. Read on for extended discussion of why every wallpaper needed the same sourceSize and why it's a square based on the largest dimension of the screen resolution. Images are almost always the most memory-intensive part of a QML application. To reduce their memory usage, you can set their sourceSize property. Setting sourceSize tells Qt to scale down or crop the image as it is loaded[1]. However, there's a problem with sourceSize... Whenever sourceSize changes, the entire image file must be reloaded from disk and stored in memory. QML has an image cache, but it only stores images based on their exact sourceSize. An image reload for a smaller sourceSize is faster than one for a larger sourceSize[2], but not nearly enough to make a reload fast enough to do during a quick transition. There is always a user-noticeable effect[3]. With that in mind, it's important to do a few things to save both load times and memory use: 1. Set sourceSize as small as possible 2. Change sourceSize as rarely as possible 3. Make sourceSize the same on every instance of the same image source The best possible sourceSize for memory use would be the exact resolution of the largest screen that Lomiri is currently running on. This would prevent multiple instances of the same image from loading (one per screen) and use a pretty small footprint. However, that creates a problem on mobile. Devices rotate. The Shell rotates with them. When the Shell rotates, the sourceSize would likely need to change. That can cause the transition on rotation to take noticeably longer to complete, which is not acceptable. Instead, we can compromise a little further on memory. If we set all instances to use a square sourceSize with the square's edge length based on the largest edge of the largest screen, we avoid reloading the image for a rotation event and still save considerable memory in most situations. We save the most memory on the lowest-spec devices, which generally have lower resolution screens to match their low RAM size. An image taken with the BQ E4.5's camera is 3264x2448px. Its screen resolution is 540x960. If we set the wallpaper's sourceSize to 960x960, Qt implicitly scales our requested size so the loaded image's smallest edge matches 960px but retains its aspect ratio[1], changing our camera image to 1280x960. That's 85% fewer pixels to store in RAM. For a concrete example: I ran Lomiri with --mode=shell and sized it to 540x960. Without this patch it uses 213MB of RAM. With this patch it uses 153MB. Of course the RAM savings become less impressive if the user's wallpaper is smaller than the beefy 4096x2304 of xenial's warty-final-ubuntu.png. Devices with a larger resolution in any direction will have worse results compared to the number of pixels on the screen, too. Sorry 2:1 screen heroes. But even with the unfortunate facts of geometry, the memory savings will be higher than zero on any device which has a wallpaper larger than its largest screen dimension. [1] https://doc.qt.io/qt-5.12/qml-qtquick-image.html#sourceSize-prop "If the image's actual size is larger than the sourceSize, the image is scaled down. If only one dimension of the size is set to greater than 0, the other dimension is set in proportion to preserve the source image's aspect ratio." I was unable to verify this behavior with the Qt Creator QML profiler. I setsourceSize to an aspect ratio that did not match the original. Whether the image's fillMode was set to Pad or PreserveAspectCrop, the Image Load event listed the image being loaded with a scaled resolution. However, the image with fillMode: Pad appeared on screen as a cropped square if sourceSize was a square, despite the profiler stating the image being loaded in its original aspect ratio. I'm not sure what's going on. [2] At least for JPG and PNG, I didn't test any other formats. JPG is slower to load than PNG for a given resolution and has larger improvements based on the sourceSize. [3] The UI thread pauses if asynchronous is false, the background flashes on screen if it's true.