3.2.4 performs worse on Windows than previous stable version (3.2.2)

[redactedscribe]

Nicotine+ version: 3.2.4
Operating System/Distribution: Windows 11

Describe the bug

v3.2.2 was not a slow as the stable version currently is. It's noticeable when scrolling search results, or the Uploads/Downloads lists. Browsing someone's shares (the left side's list) seems normal, but maybe the right side is affected too. It's about 3 FPS when scrolling a list of search results, and the list doesn't even need to be large: I have one search term that's showing 3 users each with 10-14 files shown, and even this list is 3 FPS. In fact, it looks like it might be related when there are active transfers as performance increases a bit, maybe to 5-8 FPS, when there aren't any active.

Other than sluggish scrolling, the UI is slower to respond at times, sometimes hanging and even turning white (not responding) for a moment before Nicotine+ catches up. For example, the worst hang I've experienced was just now as I clicked the hamburger menu > Help > About Nicotine+ and it hung for like 30 seconds for no apparent reason. Doing the same action immediately after had no hang at all. There are small hangs too, like switching from tab to tab can either be basically instant, or delayed by a second. I don't know what's changed but I feel like the program's taken a step back in performance, at least on Windows and/or on my system.

Something that I know is an issue on my system is that the hard drive that I download to has some errors and can be slow to respond, but it hasn't gotten any worse and I noticed the performance degradation immediately upon upgrading from v3.2.2. It's taken me until now to report this because I wasn't sure if I was imagining things, but after numerous hangs, I'm fairly certain it wasn't like this before.

Anyone else notice that scrolling lists in v3.2.4 is slow, or that the program can respond slowly when interacting with the UI in some way?

Expected behavior

As good as or better performance than v3.2.2.

[mathiascode]

In fact, it looks like it might be related when there are active transfers as performance increases a bit, maybe to 5-8 FPS, when there aren't any active.

The easiest way to fully verify this is to perform a search, receive results, and disconnect from the server.

[mathiascode]

In addition to my previous comment, could you try this rebuild of 3.2.2 once it's ready, to rule out any regressions in external dependencies since 3.2.2 was released? https://github.com/mathiascode/nicotine-plus/actions/runs/2842645900

[redactedscribe]

In fact, it looks like it might be related when there are active transfers as performance increases a bit, maybe to 5-8 FPS, when there aren't any active.

The easiest way to fully verify this is to perform a search, receive results, and disconnect from the server.

I launched 3.2.4, a wishlist search appeared, I disconnected via the hamburger menu, and this is the sluggishness of a short list of results (it was probably marginally faster at the very start, but I doesn't seem related to active transfers). I'm not sure if this is normal Nicotine+ Windows performance, or for some reason, my system (8-core ~4.0 GHz CPU, 16 GB 3200 MHz RAM). Here's a short video:

Nicotine+.3.2.4.being.sluggish.mp4

Download link if it won't display in Firefox: https://user-images.githubusercontent.com/25013746/184350421-4478f5cd-6d03-4886-971a-0157c9e90391.mp4

As you can see, the cursor is smooth, but the scrollbar trails behind, and this video doesn't even capture some of the longer delays in stepping that I've seen.

In addition to my previous comment, could you try this rebuild of 3.2.2 once it's ready, to rule out any regressions in external dependencies since 3.2.2 was released? https://github.com/mathiascode/nicotine-plus/actions/runs/2842645900

I don't think the Windows builds succeeded. Could you link me the 64-bit build directly?

[redactedscribe]

or for some reason, my system

I have noticed that some softwares' windows resize sluggishly on my system, but it's a small number: foobar2000, Mp3tag, Directory Opus (all of which deal with displaying lists with columns, but it's only really Nicotine+ which is sluggish when it comes to actually scrolling the list). I'll try the rebuild once I have the link to see if 3.2.2 is/was any better.

[slook]

Try compare another Gtk application, such a Gedit for example.

[mathiascode]

That is definitely not normal scrolling performance on Windows. It's much better on my Windows test machine.

There were some changes related to treeviews in Nicotine+ 3.2.3, but all of them are related to making the treeview do less work, so it's strange that scrolling has degraded so much.

I'll get the build working asap.

[mathiascode]

Alright, the build should be ready: https://github.com/mathiascode/nicotine-plus/actions/runs/2847299615

[slook]

As you can see, the cursor is smooth, but the scrollbar trails behind

This looks like a display compositing problem, ie graphics/display driver related. If the Control Panel > System > Advanced > Performance dialog still exists in Windows, you might try turning off smooth scrolling, transparency and other such features to identify it that is affecting the issue or not.

[redactedscribe]

As you can see, the cursor is smooth, but the scrollbar trails behind

This looks like a display compositing problem, ie graphics/display driver related. If the Control Panel > System > Advanced > Performance dialog still exists in Windows, you might try turning off smooth scrolling, transparency and other such features to identify it that is affecting the issue or not.

It exists, but I'll have to try this when the performance drops again. It's not constantly as bad, or anywhere close to as bad, as in the video. Like right now, the performance seems fine: I have three search results containing a list of 10,000 files each and they all scroll snappily in comparison, so I'm not sure what's going on.

The performance has been poor several times in the past days since 3.2.2, so I'm expecting it'll happen again. If it does, I'll look into using 3.2.2 for a few days to see if I experience it with that too. I have a feeling this might be hard to track down.

[ctp9]

Here to confirm scrolling performance degradation was the very first thing I noticed upon installing 3.2.4...

Had me confused initially - I thought I accidentally installed a buggy nightly build, but no - it's the latest official build with very noticeable scroll lag that did not exist in previous versions.

[mathiascode]

@ctp9 Can you try the build in #2150 (comment) so we can confirm if this is a Nicotine+ regression or not?

[ctp9]

Went back to 3.2.2 because 3.2.4 performance was not tolerable. On top of the scrolling lag - the rest of the UI is also very laggy. For example: opening Settings -> takes a few extra moments (a few seconds and up to 10 seconds at its worst). Then once open, the interface continues lagging when switching between pages (a 1-2 second, noticeable delay between each page).

Switching between tabs has also become laggy when it never used to be in the past (ie. cycling between Downloads/Uploads tabs).

Unfortunately I won't have the time to test regression since I already went back to previous build - I'm really busy. Really apologize. OP should do this test and report back.

[mathiascode]

@ctp9 Fair enough. Are you also on Windows 11?

[mathiascode]

I installed Windows 11 on one of my machines and can reproduce the issue. Looking into it.

[mathiascode]

Unfortunately the issue lies somewhere outside Nicotine+. This will take some time to track down.

It seems to be related to text rendering though, as the issue disappears when hiding all columns containing text.

Might be related to https://gitlab.com/inkscape/inbox/-/issues/6979 and https://gitlab.com/inkscape/inbox/-/issues/7342

[mathiascode]

There seems to have been a performance regression in the default win32 PangoCairo backend for text rendering. I've set the backend to fontconfig for now, which restores the old scrolling performance.

@redactedscribe @ctp9 The latest 3.2.5.dev1 build should fix the issue. Could you verify that this is the case? https://nicotine-plus.org/doc/TESTING.html#windows

[redactedscribe]

I'll install it now and use it over the next few days and report back.

[redactedscribe]

There seems to have been a performance regression in the default win32 PangoCairo backend for text rendering. I've set the backend to fontconfig for now, which restores the old scrolling performance.

@mathiascode On launch, the performance seems fine, pretty snappy, but there are still initial and noticeable small hitches happening. Those performance artefacts could be lived with, but the problem begins to manifest in a very noticeable way when you click and hold the scrollbar and then drag it up and down for a period of time, e.g. 30 seconds. If done, the scrolling performance begins to degrade to 3-4 FPS and doesn't return back to its original snappier state. After that, I went to verify the version number and the About popup took several seconds to appear, so it seems the bug lives on. I'm using the portable x64 build if that happens to matter.

[mathiascode]

In other words, no difference on your end?

Before I reopen the issue, can you verify that you're running the latest build, perhaps re-download it just in case? If the emoji picker (right-click a text entry -> insert emoji) displays colored emoji, things should be working fine.

[redactedscribe]

In other words, no difference on your end?

No difference as far as I can tell. Tabs can still be slow when switching between them too.

Before I reopen the issue, can you verify that you're running the latest build, perhaps re-download it just in case? If the emoji picker (right-click a text entry -> insert emoji) displays colored emoji, things should be working fine.

I see coloured emojis.

[mathiascode]

Cursed platform. Astonishing how a problem completely disappears on one system, and remains unchanged on another.

Have you changed any system defaults when it comes to text rendering or fonts?

[redactedscribe]

Have you changed any system defaults when it comes to text rendering or fonts?

I don't think I have done anything out of the ordinary on the system level, but I just checked Nicotine+'s preferences and I noticed that my Global font was set to None but it had a font size of 10. Clicking the reset arrow button to the right, reset it to 0, i.e. default, and applying it looks to have immediately helped. Even resizing the program's window is noticeably faster, something that's bothered me for quite some time. I'll have to confirm this after some more use tomorrow.

[redactedscribe]

Okay, so the changes you've made to restore the old scrolling performance seem to have had the desired effect:

• 3.2.5.dev1 performed more or less the same as 3.2.4 at first.
• Resetting 3.2.5.dev1's Global font's font size to 0 brought your code restorations to life: great performance.
  • This seems to be a bug that the font was set to None but the font size was showing 10 because it's not possible to change the font size without selecting a font.
  • Changing the font to something other than the default and keeping the font size at 10 (which also appears to be the default) introduces the poor performance again.
• Testing 3.2.4 after the font size reset made in 3.2.5.dev1 (same config files) shows that 3.2.4 still performs poorly, therefore the code changes you made in combination with resetting the font look to be the solution. Obviously, if the UI's global font can be changed, it should perform just as well as the default font, but that's a somewhat separate matter to this issue.

[mathiascode]

Good observation. Somehow I only managed to select fonts that didn't cause lag before, but certain fonts indeed seem to perform worse.

[slook]

So what causes that then, something like the difference between TrueType/OpenType or other whatnot type of font?

[mathiascode]

Looks like a regression in Cairo 1.17.6. I'll downgrade it to 1.17.4 until I've investigated the issue.

[mathiascode]

@redactedscribe Can you try the latest test build with various fonts, and see if everything is fine? https://nicotine-plus.org/doc/TESTING.html

I know the colored emoji are too stretched with this Cairo version, I'll see if there's anything I can do.

[redactedscribe]

No fonts cause poor performance; bug appears to be fixed. Window resizing is always snappy too.

Additional observations:

• When opening the Pick a font window, the scrollbar is sometimes completely missing (mousing over it doesn't reveal it: can only use arrow keys / mousewheel to navigate). I don't know how to reproduce it but it has happened several times.
• Styles are ignored: Bold, italic, light, etc.
• Only Global font and Chat font are applied when Apply is pressed (all others require the Preferences window to be closed first via OK).
  • If you change a font other than Global or Chat, e.g. Search, you can then change the Global font's size, and then press Apply for all fonts to update without needing to close the Preferences window.

[slook]

bug appears to be fixed

That's great news! All efforts on this have been very worthwhile in that case. Thank you for bringing this issue to attention and for testing etc.

Additional observations

Are these points regressions caused by the recent commits, or are they prior existing issues?

[redactedscribe]

Are these points regressions caused by the recent commits, or are they prior existing issues?

Pre-existing issues already present in the stable build by the looks of it (they were noticed when testing the dev build).

[slook]

Ideal, then this bug is closed since the reported performance issues on Windows have now been satisfactorily resolved. Feel free to re-open if anything has been missed or if something related comes up during further testing of Nicotine+ 3.2.5.

Please create a new bug for your additional observations regarding the font selectors if this is reproducible and you feel it needs addressing. Thank you for your help as always nice work :)