pulsar-edit
Settings tab uses weird and sluggish slow smooth scroll
Thanks in advance for your bug report!
- [X] Have you reproduced issue in safe mode?
- [X] Have you used the debugging guide to try to resolve the issue?
- [X] Have you checked our FAQs to make sure your question isn't answered there?
- [X] Have you checked to make sure your issue does not already exist?
- [X] Have you checked you are on the latest release of Pulsar?
What happened?
The settings tab uses a weird and sluggish slow smooth scroll when I use the mouse wheel.
Pulsar version
latest on flathub, 1.110.0 x64
Which OS does this happen on?
🐧 OpenSUSE based
OS details
openSUSE Leap 15.5 x64
Which CPU architecture are you running this on?
64-bit(x86_64)
What steps are needed to reproduce this?
- install pulsar via flathub/flatpak on Linux (I don't know if it's an OS-specific issue),
- click "Edit" > "Preferences",
- click "Core" in the "Settings" tab if not selected,
- place mouse cursor over the content area where the settings are listed,
- scroll up or down using mouse wheel.
Expected behaviors that aren't currently met in my personal opinion would be:
-
The scrolling behavior should always match how scrolling happens in code files as well. This currently doesn't seem to be the case at all, in code files I get a fast but non-smooth sort of abrupt scroll. In my opinion, this one looks less nice but is vastly superior in usability.
-
If smooth scrolling is ever used, it should be faster than it is now. As in, velocity ramps up faster, is higher, and tapers down slower.
-
If smooth scrolling is ever used, then the "Core" tab should have an option to easily disable it.
Additional Information:
Note on this bug report form itself: This report form says "64-bit" for x86_64, then lists M1/M2 separately. That seems very confusing, since M1/M2 is also 64-bit. Wouldn't it make sense to list and support ARM64 more generally? (As in, not just M1/M2 and not just macOS, but also for at the very least Linux as well? I think Linux desktop use on Raspberry PI and other ARM64 devices that often will be fast enough to run Pulsar these days is somewhat common.)
Another note on the bug report form: The debugging guide doesn't really seem to apply upfront for some more obvious bugs and weird behaviors beyond the basic safe mode already covered by the other checkbox (i'm speaking of bugs here that arent exactly feature requests but aren't likely to be some weird corner case issue if it happens every time even in safe mode). In addition, checking for being on the latest version also doesn't really work for flathub/flatpak, I'm constrained to whatever version is offered there which I assume occasionally won't be the latest. I would therefore suggest these two checkboxes for debugging guide and latest release are turned into not mandatory, unless you want to encourage users to lie about it. Or alternatively it could be reworded to just reading the debugging guide and using it where easily applicable and to checking to the latest version available via the respective install channel. Sorry if this feedback isn't helpful, it just struck me as a little odd while entering everything into the form.
A note on safe mode: This is commonly engaged via "About", but not in Pulsar. If it's not there, a lot of more newcomer users depending on how they installed Pulsar won't know how to launch it from command line with the requested option. (For example, when using flatpak the way you suggest to launch it doesn't work. On Windows, I imagine a lot of newer coders also won't know how to do that.) So I think this should be fixed as well, especially since you're communicating that's supposedly mandatory to test that for any bug reports. Other than that, I think that the checkbox for that is mandatory does make sense.
Just a quick note - the Flatpak version isn't distributed or (yet) supported by us officially precisely because of some of these issues that aren't quite the same as dealing with the native packages so you may well find some oddities.
In regards to the CPU thing, you are correct, I think the form pre-dates me adding ARM Linux to the built binaries and I never updated it, I'll get a PR in for that as we should indeed have it (although I hesitate to lump the M1/M2 chips in, I know they are ARM but some macOS users may not know the distinction where they will (or at least should) know if it is an M1/2 model.
As for this scrolling issue, I can't say I've ever really noticed it, you are correct in that it does seem to have smooth scrolling compared to an editor pane but I don't notice it being "sluggish". This smooth scroll is also used in other areas like the Welcome package. At least for me right now, the scroll "distance" is similar for both (i.e. number of lines per scroll measure, in my case right now a laptop touchpad).
Out of interest is there any difference if you try a non-flatpak version such as the .rpm (or even just the tar.gz or appimage if you don't want to install anything)?
There is also a potential solution in that you can append --disable-smooth-scrolling as an option when you launch it (from a .desktop or the terminal) which does seem to disable it, no idea if you can easily pass that to the flatpak though.
Not reproduced on openSUSE Tumbleweed with (RedHat) rpm Linux.pulsar-1.110.0.x86_64.rpm
The issue is less so the scrolling distance but that it has a noticeable delay to start and stop scrolling, it feels like there's a huge input latency. I've seen way snappier smooth scroll than the one in pulsar which I find personally quite off-putting, hence the issue to point it out. Also, whatever method is used, maybe it's just me but I find it jarring if it's not the same for all tabs including both code and settings. And for smooth scroll it would be really great if there was an in-application switch to disable it.
Fresh install of 1.118.0 on mint@ubuntu22 (X11) x86_64. Exactly same -- weird and sluggish. ell1e says about Settings>Core, but for me this is true for all tabs. Packages and Install tabs are especially frustrating to use. IDK if it's relevant, but scrolls in latest atom were ok on same machine.
One way to help troubleshoot this would be to do a performance profile:
- Open a settings page
- Open developer tools from the menu or via keyboard shortcut
- Go to the Performance tab
- Click the “Record” button
- Scroll
- Stop the performance profile
- Export it to JSON via the toolbar button and attach it to this issue
Even once the performance part is addressed, there should be an option to disable smooth scroll that actually applies to all tabs if possible. (Sorry to be repetitive, just hoping it won't get lost.)
Even once the performance part is addressed, there should be an option to disable smooth scroll that actually applies to all tabs if possible. (Sorry to be repetitive, just hoping it won't get lost.)
I don't mind the repetition, don't worry. But it's not quite that easy, since TextEditor instances use a complex technique for scrolling that involves absolute positioning and transforms.
In addition to the performance aspect, I'm curious how the scrolling experience is different for you between code editors and other tabs. I spend my day inside of Pulsar using a mouse with a wheel (with old-school discrete-unit-based mouse wheel behavior) and I don't really notice a difference, despite the fact that they use different techniques to do the actual scrolling. If you could attach a screencast, that'd be fantastic.