Heavy latency on focus after some while

[okaestne]

 * Nemo 4.6.4
 * Windowed Nemo
 * Mint 20 Cinnamon
 * Nvidia GTX 970, Driver 440.100-0ubuntu0.20.04.1
 * 64 bit

Issue

After resizing a nemo window multiple times, the window completely freezes for up to multiple seconds after focusing it.
New since Mint 20.

Steps to reproduce

1. Open nemo, home directory or sth.
2. Resize the window multiple times (20-25x), refocus window in between
3. Click on desktop or other window to lose focus on Nemo
4. Click on any file in nemo / try to resize the window again, watch the CPU usage rise until it responses
5. Notice that the file clicked on gets selected / the window getting redrawn after a huge delay
6. Performance and responsiveness as normal after the delay, until next refocus

Expected behaviour

Instant response

Other information

• opening a new nemo window is sufficient to fix (no complete stop using nemo -q necessary)
• GDB stackstrace during delay:

(gdb) thread apply all bt
.... (repreated output)
#1312 0x00007fdd86abb28b in gtk_container_propagate_draw () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1313 0x00007fdd86abb35d in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1314 0x00007fdd86b47fe8 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1315 0x00007fdd86ac0601 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1316 0x00007fdd86ac549c in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1317 0x00007fdd86b48ec5 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1318 0x00007fdd86cdad04 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1319 0x00007fdd86abb28b in gtk_container_propagate_draw () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#1320 0x00007fdd86abb35d in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1321 0x00007fdd86ce97c5 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1322 0x00007fdd86cdad04 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1323 0x00007fdd86ce4050 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1324 0x00007fdd86b8d3b4 in gtk_main_do_event () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1325 0x00007fdd86875f79 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1326 0x00007fdd868872e1 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1327 0x00007fdd868884b5 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1328 0x00007fdd86888674 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1329 0x00007fdd86428a56 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1330 0x00007fdd86447b28 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1331 0x00007fdd864480d3 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1332 0x00007fdd8687fcf3 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1333 0x00007fdd86869f4d in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1334 0x00007fdd8633ba28 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1335 0x00007fdd8633ae8e in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1336 0x00007fdd8633b240 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1337 0x00007fdd8633b2e3 in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1338 0x00007fdd86556fd5 in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#1339 0x000055af325ac106 in main (argc=1, argv=0x7ffd58cbb538) at ../src/nemo-main.c:104
(gdb)

I'm willing to provide more info or a screen recording if needed. :)

Thanks!

[okaestne]

Update: It does become worse over time during normal operation even without window resizing.
I'm using the current Nemo 4.6.5 from the Mint repos.

[RunkelRitter]

If you turn off image preview in nemo settings, does this issue persist?

[okaestne]

@RunkelRitter I disabled thumbnails as you suggested, but it still happens to me. Easiest way to reproduce is to open a folder with many files (e.g. Downloads), grabbing one window corner and moving the cursor in circles to alter the window size. After a few circles the window becomes very notably unresponsive when refocused.

Edit: I recorded my screen: https://streamable.com/b3wwu9

[SomeTroglodyte]

I concur, I noticed this too after the mint 20 upgrade.

[SparkyBluefang]

Does disabling Icon Captions help? #2605 (comment)

[okaestne]

@SparkyBluefang thanks for linking, it's indeed the icon captions as identified in #2605 . Disabling them works as workaround.

[mtwebster]

Does this occur in both list and icon views?
Does this occur with no extensions enabled? (edit->plugins-> disable all in the bottom section)
What icon and gtk3 (controls) themes are you using?
Can you attach the output of dconf dump /org/nemo/ please
Does this occur when a folder starts out with no thumbnails? Or are all the image files thumbnailed already?
How many files is 'many'?
How much ram do you have?

I have a folder with 5000 images and cannot reproduce this (trying with the initially provided method) - the window stays responsive throughout.

This behavior is curious because of the changes we did for 4.6 (mint 20):

The icon view no longer optimizes its row heights (each row as small as its largest occupant) - the space allocated for the icon is always the same, regardless of the shape of the actual icon/thumbnail. This was done because of some similar behavior that would occur when loading a large folder - it would get bogged down constantly having to recalculate the layout (for all files, even those out-of-view). Now, as files are added, or resizing occurs, the spacing is constant, and there's much less cpu being used there. The symptoms you describe suggest something similar may be happening.

• Thumbnailing and/or image loading no longer happens immediately, this helps reduce load time and memory consumption as well (a great deal with large folders). It occurs on-demand now, as icons scroll into view. Some don't feel this is an improvement unfortunately, but that's another discussion.

Thanks, hopefully I can narrow this down.

[okaestne]

Does this occur in both list and icon views?

Seems to be only in icon view for me.

Does this occur with no extensions enabled? (edit->plugins-> disable all in the bottom section)

Yes.

What icon and gtk3 (controls) themes are you using?

Icons and Controls: both Mint-Y-Dark

Can you attach the output of dconf dump /org/nemo/ please

[compact-view]
all-columns-have-same-width=true

[desktop]
computer-icon-visible=false
desktop-layout='true::false'
font='Ubuntu 10'
home-icon-visible=false
network-icon-visible=false
trash-icon-visible=false
volumes-visible=false

[icon-view]
captions=['owner', 'none', 'none']
default-use-tighter-layout=false
default-zoom-level='standard'
labels-beside-icons=false

[list-view]
default-column-order=['name', 'size', 'type', 'date_modified', 'date_created_with_time', 'date_accessed', 'date_created', 'detailed_type', 'group', 'where', 'mime_type', 'date_modified_with_time', 'octal_permissions', 'owner', 'permissions']
default-visible-columns=['name', 'size', 'type']
default-zoom-level='small'
search-visible-columns=['name', 'size', 'type', 'where']

[plugins]
disabled-actions=@as []
disabled-extensions=['NemoFileRoller', 'NemoMetadataTab+NemoPython', 'EmblemPropertyPage+NemoPython', 'AudioPropertyPage+NemoPython', 'ChangeFolderColor+NemoPython', 'NemoShare']

[preferences]
click-double-parent-folder=false
click-policy='double'
close-device-view-on-device-eject=true
context-menus-show-all-actions=true
date-format='iso'
default-folder-viewer='icon-view'
enable-mime-actions-make-executable=true
executable-text-activation='ask'
ignore-view-metadata=true
last-server-connect-method=0
never-queue-file-ops=true
quick-renames-with-pause-in-between=false
show-advanced-permissions=false
show-compact-view-icon-toolbar=false
show-computer-icon-toolbar=false
show-edit-icon-toolbar=true
show-full-path-titles=true
show-hidden-files=true
show-home-icon-toolbar=false
show-icon-view-icon-toolbar=false
show-image-thumbnails='local-only'
show-list-view-icon-toolbar=false
show-location-entry=true
show-new-folder-icon-toolbar=false
show-open-in-terminal-toolbar=true
show-places-in-to-menus=true
show-reload-icon-toolbar=true
show-show-thumbnails-toolbar=false
size-prefixes='base-10'
start-with-dual-pane=false
thumbnail-limit=uint64 104857600
tooltips-in-icon-view=false
tooltips-in-list-view=false
tooltips-on-desktop=false

[sidebar-panels/tree]
show-only-directories=true

[window-state]
bookmarks-expanded=true
devices-expanded=true
geometry='1380x1025+580+186'
maximized=false
my-computer-expanded=true
network-expanded=true
side-pane-view='places'
sidebar-bookmark-breakpoint=1
sidebar-width=181
start-with-sidebar=true
start-with-status-bar=true

Does this occur when a folder starts out with no thumbnails? Or are all the image files thumbnailed already?

It even happens in folders with no images: for i in {1..5000}; do echo "test" > $i.txt; done

How many files is 'many'?

No too much, my home directory without hidden files is enough (26 files).

How much ram do you have?

32 GiB (3.08 in use)

Thanks :))

Edit: @mtwebster Just pull the bottom right edge of the window and spin it in circles for a few seconds. It becomes worse over time until nemo is unusable

[SparkyBluefang]

Does this occur in both list and icon views?

• List view does not have any delay on focus/interaction regardless of scrolling or zoom level.
• Compact view has about a 1/2 second delay on focus/interaction. However it does not get worse on scrolling or zoom level.
• Icon view progressively gets worse the more you scroll around. And doing these back-to-back, even the act of scrolling is choppy compared to the other views.

Does this occur with no extensions enabled? (edit->plugins-> disable all in the bottom section)

Yes, I have disabled all actions/extensions.

What icon and gtk3 (controls) themes are you using?

Adwaita Windows/Controls and Gnome icons.

Can you attach the output of dconf dump /org/nemo/ please

org.nemo.txt

Does this occur when a folder starts out with no thumbnails? Or are all the image files thumbnailed already?

With captions disabled, I scrolled through the folder to generate all of the thumbnails. Then, during testing, I would start by scrolling through to make sure nemo loads all of the thumbnails.

Even with all of the thumbnails pre-generated, scrolling the icon view can be stuttery and refocusing the window becomes progressively worse.

I can also still reproduce (but not as severely or as quickly) with thumbnails disabled entirely.

How many files is 'many'?

My current test case is 1,763. But I also have folders up to 15,000 (which also behave much worse).

How much ram do you have?

64GB (reported 62.5GiB)

This behavior is curious because of the changes we did for 4.6 (mint 20):

I can go back and try testing older version to see if there was a specific version that regressed. i.e. 323d0f0 was in 4.6.1 and d937f06 was in 4.6.3

I honestly don't recall when this regression showed up. I jumped from 4.0.x to 4.4.x in the Feb/March 2020, and from 4.4.x to 4.6.x in June/July 2020.

The icon view no longer optimizes its row heights (each row as small as its largest occupant) - the space allocated for the icon is always the same, regardless of the shape of the actual icon/thumbnail. This was done because of some similar behavior that would occur when loading a large folder - it would get bogged down constantly having to recalculate the layout (for all files, even those out-of-view). Now, as files are added, or resizing occurs, the spacing is constant, and there's much less cpu being used there. The symptoms you describe suggest something similar may be happening.

Ignoring that icon view scrolling is not as smooth (with captions enabled), it really seems like this is related to window focus events. Like it's triggering a layout reflow and something is leaking/accumulating.

The best performing was the list view, where every single row/column is a fixed static size. The compact view had a fixed row height, but the column widths differ because they expand to fix the file names. I would have assumed the icon view would have been comprised of a grid of fixed size containers, and then internally they would flow the icons/labels appropriately, but that doesn't seem to be the case.

Also, this doesn't seem to be related to displaying additional file metadata (like size and mod time) because the list view contains that data.

Does the icon view and desktop view share the same implementation for the icon component (icon, name, captions)? If so, this might also explain why the desktop is still having problems keeping things aligned to the grid if those components are having layout/flow issues.

[mtwebster]

Hi, can you guys confirm something for me:

dconf dump /org/nemo/icon-view/ > saved-icon-view-prefs.txt  # saves your caption settings (if you've modified them)
gsettings set org.nemo.icon-view captions []

Restart nemo, and try to reproduce this at any zoom level.

Once you're done you can run:

dconf load /org/nemo/icon-view/ < saved-icon-view-prefs.txt

This will restore any setting changes you've made previously.

Thanks

[SparkyBluefang]

I can not reproduce the problem with either captions=['none', 'none', 'none'] or captions=@as [].

[Jeremy7701]

I do not get this problem either:

dconf dump /org/nemo/icon-view/ =
[/]
captions=['none', 'size', 'octal_permissions']
default-zoom-level='small'

[okaestne]

My saved-icon-view-prefs.txt:

[/]
captions=['size', 'none', 'none']
default-use-tighter-layout=false
default-zoom-level='standard'
labels-beside-icons=false

When disabling the captions (captions []), I can't reproduce this issue.

But after loading the old gsettings, it appears again - even without restart.

[okaestne]

(Sorry for video quality, had to get it below 10MB for GitHub)

As you can see, resizing becomes slower and slower and when refocusing the window (click on any file) the window doesn't react at all for a few seconds.

nemo-issue-2472.mp4

[Jeremy7701]

I played this back at half-speed [using VLC], full screen.
I notice that during the crazy re-sizing sections, nemo is at the top of your active tasks using about 12% - and this continues even when you cease resizing for a few seconds.
I'd suggest that nemo is getting lots of events that the window needs to be redrawn - but can't service them quickly enough?

Is this a real bug though - do you (in normal practice) resize the nemo window at the rate shown in the video?

[okaestne]

I notice that during the crazy re-sizing sections, nemo is at the top of your active tasks using about 12% - and this continues even when you cease resizing for a few seconds.

Exactly, it uses a full CPU thread until it is responsive again.

Is this a real bug though - do you (in normal practice) resize the nemo window at the rate shown in the video?

Of course I don't do this crazy resizing. It's just the easiest and fastest way to reproduce this issue. It also slowly builds up like this if I switch folders, scroll around and do typical stuff. Until I get to the point that I can't use it anymore without restarting with nemo -q.
Imagine sorting files, e.g. images with two windows and every time you want to focus the other window, nemo takes 10 seconds to react. Same with drag and drop. It's just unusable.

[SparkyBluefang]

I reproduce this without resizing the window at all. I trigger the problem simply by scrolling around and changing window focus (i.e. scroll, open an image, close the viewer, scroll, open a different image, etc). The longer I do that, the more pronounced the latency gets on focus.

In case you misread my previous comment, I can not reproduce this problem with captions disabled. I CAN reproduce it with captions enabled, which makes nemo unusable fairly quickly (at least with sufficiently large folders).

[mtwebster]

You don't have to do any more convincing - I can reproduce the issue, I just wanted to confirm the factor captions are playing while I was working on this.

[SparkyBluefang]

No worries, I just wanted to make sure @Jeremy7701 wasn't conflating (unrealistic) window resizing with this being a non-issue :)

[mtwebster]

Hi if you want to test the fix, you can get packages here: https://github.com/linuxmint/nemo/releases/tag/master.mint20

I'm also triggering a build on our daily ppa if you wish to try that way:
https://launchpad.net/~linuxmint-daily-build-team/+archive/ubuntu/daily-builds

[SparkyBluefang]

I can confirm that this appears to have resolved the runaway latency.

Though icon view does still have about a consistent 1/2 second delay in focusing the window (in my test case with 2k images, compared to list view), but that at least appears to be fixed and isn't too obtrusive.

The thing I find strange is that this unclosed gtk_style_context_save seems to have been around since nemo was forked from nautilus. So I'm not sure why it suddenly started being a problem.

[mtwebster]

Theming has changed a lot with Gtk over the years (just ask theme developers). I'm not sure when this issue started, but I wouldn't be surprised if it could be pinned down to a major Gtk3 version change (like what we get moving from mint 18 -> 19 -> 20), though I stopped digging once I found the culprit.

[SparkyBluefang]

No worries. I expect the remaining focus latency is most likely a different problem. It's noticeable, but not a usability blocker. I can file a follow-up issue if you think it's worth tracking.