I've been continuing to play with this (and checking in new commits on the above branch) as I'd like to get it to a place where I can issue a PR with confidence, or get someone else to take it over.
Here's a commit showing my changes, which as you can see are extremely simple: I assume that's easy to fix - probably my test "if (s = this)" should really be something like "if score is currently in an active viewer". The layout fixes itself when you click in the other window.
#Noteflight pizzicato how to#
I didn't bother to figure out how to handle multiple open tabs (split screen view), so if you have the score and a part displaying simultaneously, editing the part shows the score change but the layout not fixed. And yet when I switch tabs between score and part, the changes appear with layout intact (although I pay a penalty in tab-switching speed now that I am doing layout there). More importantly, edits to parts are now virtually instantaneous even in my debug build, since they aren't laying out the whole score. Edit times for the score are now the same speed with or without parts - still slow in my debug build, but twice as fast as before when parts are present.
I then added a doLayout() call to MuseScore::setCurrentScoreView(), which might be overkill (not sure all of the places this is hit) but I wanted to see what was possible. So I wonder if that much at least we could optimize? Don't actually layout all linked scores immediately immediately upon an edit.Īs an experiment, I tried altering the loops in Score::endCmd() and Score::update() to only call doLayout() for the current score (s = this), but to still calling setUpdateAll() for all linked scores.
#Noteflight pizzicato full#
In 2.0, editing one part also updates the score which thus forces a full layout of everything. For 1.3, editing a part was usually very fast, since it didn't need to re-layout the entire score. The one thing that will be noticeably slower is editing the parts, however. So as long as one waits to generate parts until one is done with most note entry - which would probably be normal - basic score editing won't seem noticeably worse than 1.3. So I guess now we know how much a different debug versus release build makes! And when I delete the parts (1.3 didn't have parts to deal with on every score edit), performance is worst only very slightly slower than 1.3. Not too bad, I guess, for 100 pages of layout. I went and downloaded a nightly build (which I should have done in the first place, I acknowledge) and can report similar results - a bit under a second maybe on average per operation.
0 kommentar(er)
