Smooth scrolling in the score view

• Apr 27, 2014 - 20:51
Type
Graphical (UI)
Severity
S5 - Suggestion
Status
duplicate
Regression
No
Workaround
No
Project

Lasconic and I had a few conversations on IRC about the topic of smooth scrolling.
We came to the conclusion that smooth scrolling, which was enabled during 1.3 on at least the mac but not on linux, isn't enabled in the current nighties.

Let me clarify what smooth scrolling is: When using the touchpad/trackpad free or combined with the shift/ctrl modifier, the score is scrolled. Currently, this happens incrementally, a number of pixels at a time. Everytime the input device goes over a certain distance threshold, the score is panned by exactly that amount of pixels.
Smooth scrolling means that the score starts to move as a direct reaction of the input device scrolling even only one px. It is enabled on most modern Desktop environments and on phones anyway to scroll through images or text.

Not using smooth scroll seems very oldish(esp. since there was support for it in 1.3) and scrolling is also less precise.


Comments

There are two aspects to what you may consider 'smooth scrolling' - the first is responding appropriately to high-resolution scroll events, like you would receive on Mac OS from an Apple trackpad or on Windows with a Logitech smooth scrolling mouse with Flow Scroll installed. This I am tackling now; it's quite straight-forward (MuseScore's current scroll handling has been deprecated in Qt5 so it's definitely worth doing anyway).

The other aspect is interpolating larger scroll events (like from traditional mice and older trackpad drivers) to scroll smoothly by moving an appropriate delta each screen paint. This is a little more involved and I've not done such a system before. It's also somewhat reinventing the wheel (or trackpad, hurr hurr hurr), as Qt already implements this in its widgets. However, because it looks like MuseScore 2 has changed to its ScoreView to directly subclassing QWidget and manaully reimplementing scrolling etc, we can't easily benefit from this.
Qt provides a scrolling container that other widgets (like, for example, a score view) can be placed inside, and handles all scrolling very nicely and consistently with the user's platform. However, this would require some heavy-handed changes to how the UI is currently put together. I'm not comfortable enough with either of Qt or MuseScore to do this, but it would seem to my mind to be a better end-result.
On the other hand, MuseScore could just continue reimplenting things that Qt already provides. This would probably be less consistent with users' platforms (alternatlvely, would take a lot more effort to achieve consistency), but require less changes to how the UI is built. I'd be comfortable tackling this way, however I believe the first approach would be the better one here.

Just food for thought for now. Back to implementing pixel-based scrolling. :)

Severity S1 - Blocker
Workaround No
Regression No

The piano roll feature already has smooth scrolling where the page moves continuously in the window. No 'leap frogging'. Would it be possible to adapt this feature for playback? I would think the programmers could use the piano roll code as a basis and apply it to playback.
I have no idea how difficult this could be, but I think it would be easier than trying to develop a whole new module.
I think this feature takes new urgency in the era of worldwide quarantine. We are now using various internet video tools to a much greater extent than before.