Hacker News new | ask | show | jobs
by chownchown 1759 days ago
Can it run anything with thumbnails in the filepicker?

I kid. Now what I really wanted to ask.. Is it using Wayland?

2 comments

Only framebuffers are currently available and a typical Wayland compositor runs through DRI (direct rendering infrastructure), which is a whole bunch more complex.

I haven't ruled out Mutter having a framebuffer backend, but I suspect she just ran it through X, which has one.

Edit: Looks like DRI is there after all: "Sven and the #dri-devel crew helped me spin up #2, which is what I'm using now."(https://twitter.com/alyssarzg/status/1429583864679129098).

"DRI" is a fuzzy term :)

What's there is a basic KMS driver, so rather than one single framebuffer, userspace can do pageflips. Mutter can run with a display-only KMS driver + llvmpipe for rendering by now I'm pretty sure. wlroots has landed this feature recently-ish too.

> Can it run anything with thumbnails in the filepicker?

This is of course a harder and more pervasive problem than one might realize. macOS Finder RAM usage can explode catastrophically and take down the whole system if you have image previews enabled and click on a very large (gigabyte) TIFF.

> macOS Finder RAM usage can explode catastrophically and take down the whole system if you have image previews enabled and click on a very large (gigabyte) TIFF.

I've experienced (and confirmed with a quick search) that Finder won't display a preview for any file that doesn't have the resources to show.

Watch what can happen: https://imgur.com/a/BAmzgkm

It's quite amazing.

I’ve experienced QuickLook bringing my whole system to a halt just opening a Save dialog. Not actually previewing anything at all.
Both QuickLook Satellite and also com.apple.appkit.xpc.openAndSavePanelService are affected. Who knows what else. I think the save panel is actually trying to generate a preview in those instances, though.
That sounds like an edge case that should just be accounted for in finder. lgnoring for certain file sizes is a fast solution that can be expanded upon as your thumbnailing programs grow in efficiency and improve their handling of low-IO situations or large files.
Should! But apparently isn't. In fact, nearly every image viewing/accessing program assumes that your image content will just happily fit entirely in available RAM after decompression and doesn't bother with things like live tiling.
>In fact, nearly every image viewing/accessing program assumes that your image content will just happily fit entirely in available RAM after decompression

Sounds like a totally reasonable assumption, for 99.9% of the cases (including graphic designers).

Absolutely, and the pervasiveness of that mindset leads to things like tearing through swap and grinding the computer to a halt because the user clicked on a random file. It doesn't take supergenious or paranormal powers to realize that files might be arbitrarily large. Engineers mostly just fail to care.