Delay in selecting lines/ped/cresc.
Anyone else notice that markings like lines have a slight delay in their being selected? E.g., insert a pedal marking and then select it via mouse or ALT+Direction. There is an almost one second delay before highlighting the mark. Same with crescendos. Obviously it can be "patiently" not worried about, but in another sense this is not acceptable, as it should be practically instantaneous, and it warrants a bug report.
Comments
In order to investigate, we'd need to see the specific score in question. My guess is that it's large enough that the time to do a layout is what you are seeing, but it's impossible to say for sure without the score.
In reply to In order to investigate, we… by Marc Sabatella
No, unfortunately it isn't due to size.
Any freshly made score with one staff performs this way over here. As an example, provided below is a capture of a two measure score with a one-staff instrument. The demonstration is one of ALT+RIGHT to select the next element (*viz., a crescendo). Notice the delay from the ALT+RIGHT to the highlighting of the element. It would be kind if a demonstration could be provided showing that it isn't this way for someone else, or a verification that it is indeed like this everywhere (@ 3.2.3 version)
In reply to No, unfortunately. Any… by worldwideweary
Unfortunately I can't really tell what is going on from your vide, I don't know when exactly what is happening. All I can say is that it is exactly as instant on my system as I'd expect. It takes no longer to select a line than anything else, whether in MuseScore or any other program. So if the issue isn't unique to your score, it may be unique to something else about your system. like maybe you have some sort of macro utility grabbing keystrokes or something?
In reply to Unfortunately I can't really… by Marc Sabatella
Hrm. Well thanks for saying it's instant on your system, meaning there's something weird going on over here. The video should be fairly clear, but if it's not and you have a specific issue with it, let me know and I'll in the future adapt. It's in gray so maybe the highlighting is less easily apparent, as it only appears bolder. On a fresh restart with no macros or anything, Cpu idling around 3% usage, this delay still happens. Will test out on windows and see (this is on a linux distro in xfce) if the same thing happens or not, and then on another system.
In reply to Hrm. Well thanks for saying… by worldwideweary
What's not clear is exactly what you are doing and in what order and why and how what I see it lining up. There are steps involving extending a line that don't seem to have anything to do with selection, unless they do and I'm missing it somehow. The fact that it's a GIF rather than something I can pause, rewird, single-step frames etc, doesn't help.
If the issue is simply time it takes to select an element with Alt+right, then it seems the simple wy to demonstrate this would be, a score with say four empty measures, hairpins on each measure, then set the cursor at the start, turn on the recorder, and press and hold Alt+Right. For me, the cursor would be at the end of the score before I could even blink. Sounds like for you it would get hung up at each hairpin. Not that seeing this would help me understand why.
One thing I can say is that the act of finding a line is much more involved computationally than finding a note, because the lines are stored totally differently, I think maybe if I try hard I can see the difference, maybe it's 10 milliseconds to select a hairpin versus 5 to select a note? But either way it's a negligible amount of time
In reply to What's not clear is exactly… by Marc Sabatella
Ok, thanks for the feedback. Too bad mp4/avi files aren't uploadable, huh? Anyways, it seems more than 10 milliseconds, more like just shy of half a second (which is still a negligible amount). This is easily endurable, but if it's not merely my machine (you said it was instantaneous on yours) it would be worth trying to make efficient whatever's happening for the purpose of making it as instantaneous as possible.
Based on your input, here's another screencast:
In reply to Ok, thanks for the feedback… by worldwideweary
mp4 files are uploadable, just not here :-). So you could always upload one somewhere else then include a link. But not necessary here, I get what you are seeing and this video is clear enough. It's a somewhat more exaggerated version of what I see - a noticeable difference once you stop to look., but I can think of a lot of things more worth spending investigation time on.
In reply to mp4 files are uploadable,… by Marc Sabatella
Keep it domestic :) Anyways, the point is that there's something going on that if anyone who sees this who has any programming time on the side might want to investigate during efficiency testing, similar to the 2/3 second delay of saving preferences in 3.2.3 as previously referenced (which is probably more important than this). Or, the fabled cross-staffed/voiced playable arpeggio...
I tested on ubuntu studio, MS 3.2.3 and there is, indeed, a slightly longer delay in the crescendo getting the focus but on my system the delay is smaller than it takes me to look at the keyboard and plan what I am going to do. It is no-where near one second though I don't have any very long scores to test it on.
I compared the action with MS 2.1 on the same machine and MS 3.2.3 definitely has a slight delay that 2.1 does not show. And, yes, it does seem to affect lines, crescendo, voltae. Articulations, glissandi show no delay. Slurs are in the Lines palette but they show no delay.
In reply to I tested on ubuntu studio,… by underquark
Thanks for the input.
In reply to Thanks for the input. by worldwideweary
For the record, to give an example of when this inefficient implementation becomes moreso a burden is when there are multiple connected pedals lines that need to be position-edited: the delay between selections can be a little tedious. The 'scarier' thing is that whatever is happening may be something that is tending toward instability of behavior, as there have been instances of ALT+Direction that ended up crashing the program a few times (haven't spent attention to the specifics), and maybe this delay-behavior plays a role in it...
In reply to For the record, to give an… by worldwideweary
I doubt it, I don't think there is any code at all that is shared.
The code for finding the element you are clicking is surprisingly clumsy, it's basically a matter of checking the position of every single element on the page to see if any overlap the mouse pointer. And lines are recorded differently from other elements. Not clear why that matters, but apparently it does. Anyhow, nothing like that happens on keyboard navigation.
BTW, regarding the pedal lines - I saw you posted something about some unusual special case editing you are doing. I am not sure you'd want to make your pedal lines look like that, some context would help in prioritizing that suggestion.