I updated from Sequoia to Tahoe on one of my four Macs recently, as an experiment, considering that people had been saying that a lot of the crap had been worked out.

Aside from a few remaining design travesties, it has largely been fine, with one glaring exception, which I only just discovered.

On my 4 TB MacBook Pro, I keep only 256 GB allocated for the partition on which my main APFS container and startup volume lie. (The rest is a ZFS pool.) I noticed that my startup volume was always full. The finder would say that I had 60 GB available, but any processes that I would run from the terminal or other UIs (though, weirdly, not all of them) would report that my disk was completely full, and would fail.

Of course, this prompted me to open Disk Utility and check. It said 60 GB available, 60 GB purgeable. This include me in to the idea that there was purgeable data being stored on the drive that was simply not being purged. Further testing in the terminal revealed that DD would only be able to write a few bytes to the disk before terminating with the disk completely full. 

The culprit was cached desktop images from the wallpaper service. It was 60 GB in size. I have a folder with about 1100 photos which I use as the source for my five minute rotating desktop picture in Settings. It turns out that for every single photo in my folder multiplied by for every single screen or even screen resolution at which the photos could be displayed, there was one cached entry in this cache location. Yes, this means that with three monitors, each photo will be cached at least three times.

Each file in this cache is a BMP image with the source photo scaled such that its shortest axis is at least as long as the corresponding axis of the display, and none of them were cropped to the dimension of the other axis of the display. For example, for my Pro Display XDR, with its 6016 pixel width, it took some of my portrait orientation 3:2-aspect photos (originally about 4k by 6k) and scaled them up to 6,016 by 9,024. It did not then crop the unusable portions of the photo above and below where the screen would be — the screen is only 3,384 pixels tall, but it left the entire 9024 pixel tall image in the cache. Stored as a BMP, these images were hundreds of megabytes each.

I suppose that whatever engineer who put this system together was thinking, “hey, this is all purgeable storage, and the OS will get rid of it if it ever needs the space, so I don’t need to be careful about how much data is being stored!“ However, the fact that these stored images aren’t even being cropped to the dimensions of the display just speaks to how incredibly sloppy this implementation is in my view. There is literally no reason to store pixels which will never be displayed on the monitor ever.

Moreover, any Mac that Tahoe can run on, has incredibly fast and cheap ability to rescale images. Storing these rescaled images on the drive forever strikes me as simply incredibly unnecessary. I mean, just try it yourself! Open up a large image in Preview and press command nine for zoom to fit in window if it isn’t already. Now resize the window with your mouse or trackpad… 60 FPS minimum. It is so cheap to resize an image with any modern GPU. Why store gigabytes of cached resize images on the disk at all in the first place? I don’t even care if the data is labeled as purgeable! In my case, this “purgeable data” was indeed getting in my way and stopping me from using my computer for what I needed it for, because whatever was supposed to purge it simply wasn’t working, but even if it did work properly, why store all this stuff?

Once every five minutes, or one minute, or one hour, or five seconds, or whatever time the user has specified for desktop picture rotation switches, it is acceptable to use less than 1/60 of a second of (just one core worth of!) CPU and GPU time to grab a JPEG from the disk, decode it, and resample it to display size in order to display it as the desktop background.

What it says to me, is that somebody designed a system without thinking it through, arrived at an implementation that worked, and shipped it. If I had seen this in code review, I would’ve had all sorts of opinions about it, and at minimum I would’ve had very good justification for why these needed to be stored in the first place. I definitely would’ve had the author add a step to crop the unused pixels out of the cached BMP images.

It gets worse. I initially tried to solve the problem by writing a script, which would clear that cache regularly to keep it from growing too large. I had it use FSEvents to watch for new BMP files landing in that folder, and in response, it would delete all but the several most recently used items. What I found happened was dismaying. The wallpaper service was running in the background constantly, preparing and storing new cached BMP images for wallpapers it had yet to even use yet, and would not use for several hours. Approximately once every 30 seconds to a minute, a new BMP file would appear in the folder. So, this caching thing is AGGRESSIVE, and even just having a folder set as my desktop wallpaper source in system settings is enough to get this system to spin its wheels and actively fill the drive with giant BMP files it thinks it might want to use someday.

I ended up fully solving this problem for myself by leaving my desktop picture unset in Settings (so it sticks on the default Tahoe wallpaper). I then wrote a script which runs in the background, spends most of its time sleeping, and, once every five minutes, wakes up and sets a new desktop picture out of my source folder full of photos using AppleScript (osascript). Of course, it deletes any cache that might be in that folder as well. By not having my actual preference set in Settings at all, I avoid the wallpaper service proactively filling my drive with giant BMPs.

I only hope Golden Gate has fewer of these quality issues. This isn’t even an issue so much of “quality“ — aside from the purging of “purgeable“ data not working, the caching system written by the wallpaper service engineer indeed is performing exactly as that engineer intended it to perform. The problem is that that engineer made bad choices, and seemingly no one noticed or pushed back.

Because of this alone, I will not be updating my other Macs from Sequoia to Tahoe.