Bug 2127618 - Nautilus thumbnailing doesn't work on hidpi screens
Summary: Nautilus thumbnailing doesn't work on hidpi screens
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F37FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-09-17 13:08 UTC by bztdlinux
Modified: 2022-10-10 10:19 UTC (History)
12 users (show)

Fixed In Version: nautilus-43.0-2.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-10-03 00:20:30 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME glib issues 2767 0 None opened GFilesInfo fails to find x-large and xx-large thumbnail paths 2022-09-26 09:35:18 UTC
GNOME Gitlab GNOME nautilus issues 2487 0 None opened Files does not generate Hi-DPI thumbnails 2022-09-17 13:08:07 UTC

Description bztdlinux 2022-09-17 13:08:08 UTC
Description of problem:
Nautilus does not generate thumbnails when using a hidpi screen.

Version-Release number of selected component (if applicable):
43.rc1

How reproducible:
Always

Steps to Reproduce:
1. Open Nautilus in a directory of pictures

Actual results:
No thumbnails are generated

Expected results:
Thumbnails are generated

Additional info:
Note the upstream bug says "takes forever to generate", this the literal definition of forever as they in fact never generate.

Comment 1 Fedora Blocker Bugs Application 2022-09-22 05:43:07 UTC
Proposed as a Blocker for 37-final by Fedora user tdaede using the blocker tracking app because:

 > For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: 
> file manager

Not having any thumbnails in the file manager is a very visible functionality loss (although technically files can still be managed).

Comment 2 Geoffrey Marr 2022-09-26 17:22:10 UTC
Discussed during the 2022-09-26 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug and accept is as an "AcceptedFreezeException (Final)" was made in order to gather more info on how bad the CPU load issue is. We agree that the lack of thumbnails is an annoying cosmetic issue but not serious enough to block on. It's definitely serious enough (and in a component of the Workstation live, so not fully fixable with an update) to grant an FE.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-09-26/f37-blocker-review.2022-09-26-16.01.txt

Comment 3 Lukas Ruzicka 2022-09-27 16:18:27 UTC
Yesterday, during Blocker review meeting, I promised I would test this with my setup, but I was not able to trigger this. Although, I have set scaling to 200%, I could always see the thumbnails in Nautilus. I did not see any bigger increases in CPU activity either. It seems my displays are not HI-DPI enough.

Comment 4 Adam Williamson 2022-09-28 16:49:13 UTC
hum, it *ought* to happen with scaling set to 200%. I'll see if I can reproduce on my hidpi laptop, though.

Comment 5 Adam Williamson 2022-09-28 19:32:23 UTC
So, I can reproduce this. But you need to hit a file that *doesn't already have a thumbnail*. Apparently this change doesn't make nautilus re-generate new hi-res thumbnails for files that already have them. So I had to create a new directory and download some random photos into it. Then when accessing that directory the bug occurred.

I put two fairly high-res JPEGs in the folder. On my other laptop - CPU is a dual-core i7-7500U - I see two processes using about 30-40% CPU time each, so I think together they're burning about 40% of the total CPU time across two cores. This persists as long as nautilus is showing the affected directory.

Comment 6 Adam Williamson 2022-09-30 16:42:43 UTC
-6 blocker in https://pagure.io/fedora-qa/blocker-review/issue/918 , marking rejected blocker (it is still accepted FE).

I really think we could backport the simple workaround in nautilus here, it is safe and simple and restores previous behaviour. A slightly blurry thumbnail is much better than no thumbnail and a spinning CPU.

Comment 7 Fedora Update System 2022-09-30 19:54:05 UTC
FEDORA-2022-2f7ae3de74 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2f7ae3de74

Comment 8 Fedora Update System 2022-10-01 02:13:15 UTC
FEDORA-2022-2f7ae3de74 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2f7ae3de74`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2f7ae3de74

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2022-10-03 00:20:30 UTC
FEDORA-2022-2f7ae3de74 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Kamil Páral 2022-10-03 07:32:28 UTC
I can confirm that the nautilus update fixed this problem.

Comment 11 Adam Williamson 2022-10-10 10:19:40 UTC
Note, the nautilus update more 'works around' than 'fixes' the problem, by just reverting the change to nautilus so we go back to always using lower-res thumbnails. But we can track the "true fix" (to get higher-res thumbnailing working when appropriate) upstream, I think.


Note You need to log in before you can comment on or make changes to this bug.