Delay (lag) between selecting a note and it being highlighted (and subsequent actions)
Since updating so MuseScore 2 I have observed a delay between clicking on a note and it being highlighted. Consequent actions, like moving the note are also delayed. The delay is quite short (less than a second) but does cause problems with composing, slowing down the workflow.
Upon clicking on a note the note sounds quite quickly but the highlighting is delayed. If I start MuseScore in debug mode I observe the note selection change being delayed. (In debug mode there is outline of what is selected.
I am running MuseScore 2.0.2 on Xubuntu 14.04 with QT5.3 on an Intel Atom 1.3GHz with 1GB RAM. I expereince same issue using PulseAudio or ALSA.
Comments
The speed of responsiveness is dependent on the size of your score. Linked parts essentiually double that. And debug mode slows things down further; also *compiling* MuseScore in debug mode slows it down. And the Intel Atom is an extremely low powered CPU, so it is not surprising that there would be a delay in scores that would present no difficulties for other processors.
In reply to The speed of responsiveness by Marc Sabatella
I understand that a (relatively) low power processor will take time to process large amounts of data but I am experiencing degraded behaviour compared to previous version (v1.3) on the same hardware and OS. This happens with an empty score so the score size is not causing this. Something has changed to introduce lag.
In reply to I understand that a by riban
Well, lots of things have changed indeed. In general, performance should be extremely similar to 1.3 and is on all three of my machines, and should be virtually instantaneous for an empty score. I guess one thing to consider is that the default soundfont for 2.0 is much larger, and perhaps your processor is struggling just to play the single note you clicked. Trying a smaller soundfont might help. Or turning off the reverb. ESee the Handbook under Soundfont and maybe go back to the 1.3 soundfont TimGM6mb, also disable the effects in View / Synthesizer.
Disabling all effects and using the previous soundfont do not improve this. The delay occurs even when Musescore is configured to not play notes on selection or when selecting a non-note element, like a rest.
Can you point me at the code that is triggered when an element is selected? I will try to figure out what extra processing has been introduced between V1.3 and V2.
Cheers
In reply to Disabling all effects and by riban
Well, so much code has been rewritten, it's not likely you'll be able to easily figure out what has change,d but if you have access to profiling tools, maybe you'll be able to figure out where the time is being spent.
Anyhow, the process begins with ScoreView::select(), most of the real work is in Score::select(). It's not really a particular expensive operation that I can see, so it's hard to imagine there is much opportunity for significant gains. Is it really just selection that seems slower to you, or perhaps is *everything* slower? I believe you mentioned the latter. In which case, lookiung at the selection code won't be relevant. Could be something else completely, like maybe your build of MuseScore was done in debug rather than release mode and thus did not use optimization, etc.
In reply to Disabling all effects and by riban
@riban: I think you are unlikely to find the problem is with MuseScore itself. I could be wrong, but I think the problems is more likely to be with the software libraries that MuseScore relies on, such as Qt, which may not be optimised for your hardware. You could try updating these dependencies and/or compiling MuseScore yourself from the source code. (Also, try doing a factory reset now if you haven't already because that's nice and quick, just run "mscore -F" from the terminal.) However, in the end it could just be that your hardware isn't able to cope.
In reply to Disabling all effects and by riban
I have run some profiling and found most of the delay happening within Inspector::setElements. The delays are indeed within the QT library. The following two lines of code are taking most of the time:
QWidget* ww = sa->takeWidget();...
sa->setWidget(ie);
Is there any optimisation that can be done around this? Do these need to be called every time an element is selected?
Cheers
In reply to I have run some profiling and by riban
What if you simply close the Inspector?
In reply to What if you simply close the by Marc Sabatella
Closing the inspector makes no difference. The delay persists. The Inspector::setElements function is still called.
In reply to I have run some profiling and by riban
I can't see an equivalent to the inspector in 1.3. Is this new functionality?
In musescore.cpp MuseScore::selectionChanged I have wrapped a condition around updateInspector() thus:
if (_inspector && _inspector->isVisible())updateInspector();
This works around the problem by not updating the inspector when it is not shown. updateInspector() gets run when the inspector is shown so this patch does not seem to have adverse affect. I can submit a patch or git pull if required.
I think it is still worth investigating whether the QT widget code needs to be called so regularly. If there is further optimisation possible there, then the inspector may be able to be shown without the lag.
Cheers
In reply to I can't see an equivalent to by riban
The Inspector is indeed a 2.0 improvement.
Feel free to submit a PR for your change if you have tested and verified it has no other side effects (eg, hide inspector, change selection, then unhide Inspector - does it show the correct values?).
I have no idea how easy it would be to reimplement the Inspector to perform better on mobile device processors like the Atom series.
In reply to The Inspector is indeed a 2.0 by Marc Sabatella
I have submitted pull request #2258. I tested to ensure the correct behaviour, including ensuring the correct element is selected in the Inspector when made visible and parameters are updated correctly.
I have reviewed the Inspector code and see that it may prove challenging to remove this delay.
This update will provide the improvement required. It is seldom necessary (in my workflow) to have the Inspector open. The Inspector is a new feature which one may suggest requires a more powerful machine.
Thanks for your assistance.
In reply to I have submitted pull request by riban
It just got merged.
In reply to I have submitted pull request by riban
Great job identifying this particular source of slowdown and finding such a simple fix!
In reply to I have submitted pull request by riban
I'm surprised the Inspector was the cause of the problem since it's just a simple toolbar. Maybe there is an inefficiency somewhere in the update algorithm (e.g. it might check all elements rather than just the changed ones) or perhaps there is an underlying Qt problem after all.
In any case, well done for sorting it out!