FreeTube [Bug]: Settings tab is extremely slow

Guidelines

[X] I have encountered this bug in the latest release of FreeTube.
[X] I have encountered this bug in the official downloads of FreeTube.
[X] I have searched the issue tracker for open and closed issues that are similar to the bug report I want to file, without success.
[X] I have searched the documentation for information that matches the description of the bug I want to file, without success.
[X] This issue contains only one bug.

Describe the bug

Go to the Settings Tab
Click on any Settings (General settings, Theme Settings, etc)
It takes about 5 to 20 seconds to open or close the relevant tab

Expected Behavior

It should open instantly I suppose

Issue Labels

usability issue, visual bug

FreeTube Version

v0.19.0 Beta

Operating System Version

Fedora 38, Kde spin. Kernel: 6.4.11-200.fc38.x86_64, using Wayland

Installation Method

Flathub

Primary API used

Invidious API

Last Known Working FreeTube Version (If Any)

No response

Additional Information

this last update is great

Nightly Build

[ ] I have encountered this bug in the latest nightly build.

Aug 21 '23 08:08 galure

Hi @galure could u try to install .rpm so we can check if this is an issue with flatpak

Aug 21 '23 09:08 efb4f5ff-1298-471a-8973-3d47447115dc

I installed the .rpm version and it is as slow as the flatpak version

Aug 21 '23 09:08 galure

On my laptop running Fedora 38 Gnome version and Wayland there is no problem. Also Flatpak version.

Aug 21 '23 09:08 galure

Working on Gnome but slow on KDE

I cant imagine KDE being the issue here

Aug 21 '23 09:08 efb4f5ff-1298-471a-8973-3d47447115dc

I cant seem to reproduce this on my fedora machine

Aug 21 '23 19:08 efb4f5ff-1298-471a-8973-3d47447115dc

Installed the .rpm version of FreeTube (v0.19.1 beta). Have the same issue, still not resolved.

Interesting behaviour:

When clicking on a category in the settings menu, it is not opening directly.
It is about a 10 to 20 second long wait, to see what's in the selected category, BUT.
but, when doing a scroll down or up, this waiting time isn't there any more, the section/category will directly open.
When doing scrolling “too fast”—(about 20 lines down or up), I could open more sections in the settings menu. WHICH is annoying as hell.

Thoughts: Is there some kind of mouse event happening?

Else, where in those control+shift+i settings can I see what's happening as “mouse events”?

Oct 18 '23 22:10 Julienist

@Julienist #2436 is unrelated to this

Oct 18 '23 23:10 efb4f5ff-1298-471a-8973-3d47447115dc

deleted the line

@Julienist #2436 is unrelated to this

Oct 18 '23 23:10 Julienist

I wonder if KDE delays rendering of things until you scroll or something, because this problem doesn't exist on Windows (tested myself) or Linux with Gnome (as mentioned by @efb4f5ff-1298-471a-8973-3d47447115dc).

Oct 21 '23 14:10 absidue

Doing a quick search for KDE rendering delay(s), with or without scrolling as search indexers (doesn't really add much). But you will basically run into the following discussion: KDE is slower then gnome, because [reason]. To be objective, where to find the rendering (delay) inside FT itself? because FT itself is based on chromium (that's what the dev. console gives me).

Oct 21 '23 15:10 Julienist

This is due to xwayland and electron being an oddly buggy combo. Its not a KDE thing as I've had the same issue in Gnome and I've seen this in other apps that fall into the same category. Using the correct electron flags while using native wayland fixes this appeared lag and makes things as snappy as it should be. I have a PR in the flathub side that you can test. Fixed the issue for me! Hoping it can be merged in to clear some of these related open issues.

Oct 21 '23 17:10 JoshuaMacklin

@galure are u available to test that PR?

Oct 21 '23 18:10 efb4f5ff-1298-471a-8973-3d47447115dc

I followed this instruction: flatpak install --user https://dl.flathub.org/build-repo/57891/io.freetubeapp.FreeTube.flatpakref and it seems to work. No more stutter, no slowness.

Oct 21 '23 18:10 galure

I would like to come back to before I installed the PR, just to be sure it fixed the issue (I should have tested the issue was still there, I'm an idiot), is there a command to do that? flatpack remove etc... doesn't work

Oct 21 '23 18:10 galure

What about flatpak uninstall?

Oct 21 '23 18:10 efb4f5ff-1298-471a-8973-3d47447115dc

same as flatpack remove:

error: Invalid id https:: Name can't contain :

Oct 21 '23 19:10 galure

When is the merge of the correct electron flags with the main branch possible? Because if snappy behaviour is possible then I guess the next thing to do, would be to merge it with the main FT-branch as flatpak -> thus also making it possible to do this with the .rpm versions.

Oct 21 '23 22:10 Julienist

Okay so big question, if those flags are added by default, will it break FreeTube for anyone using X instead of Wayland?

Last time someone mentioned wayland flags they also said something about it removing X support or something.

Oct 21 '23 22:10 absidue

Okay, so I do not have the following knowledge: — Wayland or Xorg compositors (I did not read an explanation of how these 2 work). — Wayland protocol. — x11 What I do know: Large amount of apps which work on x11 or Xorg work on Wayland, thanks to Xwayland. (a fallback).

Next thing: I do not want to have support for x11 to be gone, for the people who still use it/those who refuse to go to Wayland/ or just can't.

Confusing but safe path: A safe path would be to make like a branch-off for Wayland only (testing), but then you would make 2 main chains of FT (which is more confusing). ..... → indirect this “wayland-only testing branch” could be tested on x11 for checking compatibility.

Oct 21 '23 22:10 Julienist

Hopefully there is a way to do it without having to release lots of different versions just for linux, especially as most of the freetube devs don't actively use linux, so having to keep vms around to test loads of different versions would be horrible.

Oct 21 '23 22:10 absidue

If most of the FreeTube devs do not actively use Linux, how is x11 support in question? I think in that case, there could be a risk made by taking the correct electron flags in the main branch. Then the question next could be, does xwayland work with the electron flags to fallback on x11. in that way, x11 and wayland support at the same time, is done. Basically, making the electron flags to be supported by xwayland.

Oct 21 '23 22:10 Julienist

I would like to come back to before I installed the PR, just to be sure it fixed the issue (I should have tested the issue was still there, I'm an idiot), is there a command to do that? flatpack remove etc... doesn't work

You can just remove it through the Software Center Gui, find the app, click the flathub drop down and remove the version that has the user tag

Oct 23 '23 01:10 JoshuaMacklin