Moving rit endpoints extremely laggy

Hi

Does anyone else see this? Just trying to move around the start and end markers for rit, accel etc.

And it only updates the screen about once per second, so it’s almost impossible.

Intel i9-10900X, 128GB RAM. Windows 11 Enterprise.

There’s no way it should be this laggy…

I note that VSTAudioEngine is using 65% of my GPU. Could this be causing it? It’s only a GTX1070, but it’s perfectly fine for everything else I run. I don’t know why the Audio Engine is using any GPU at all (not CPU, GPU).

Killing the VSTAudioEngine, does not make a difference to the lagginess. Although it quickly kills Dorico. I have Noteperformer 4 running, and I notice when I kill the audio engine the NP mixer windows disappear. But no effect on lagginess.

The CPU isn’t really changing while I drag the endpoint around, but the wait cursor is coming on and off. It’s like it has to re-render the entire score from bar 1 to the end each time it gets a drag on anything.

Suggest developers should run on machines more indicative of end user machines. It’s always a problem when developers have insanely fast computers. It makes sense for many things (reducing compile-time-waiting, increasing iteration speed for code changes), but it masks performance issues like this.

I suggest someone gets on a profiler and checks some of these things. I have spent years profiling code, and this kind of lagginess is a serious problem, considering how many people on here complain about lagginess, and how other programs don’t have this problem.

When you change the duration of a gradual tempo item, Dorico is editing the score. Depending on the scale of the score, that edit could be quite expensive (in particular, changing the duration of gradual tempo marks has an impact on spacing, the positioning of other tempo marks, rehearsal marks, etc., which can have an impact both on horizontal spacing and vertical spacing, and indeed on casting off).

If you have a particular situation in which dragging the circular handles for tempo marks feels especially slow, please do provide us with the project file and details of which tempo mark to edit, and how, and we’ll be pleased to investigate the specific case you’re experiencing.

(By the way, there is nothing extravagant about the machines we use for developing Dorico. I’m certain there are many Dorico users who have faster machines than our development machines!)

Hi Daniel

thanks for your response. I’ll send the file through. Any dragging of any tempo length affects it.

I think if there are potential casting off issues, it would be worth putting some effort into figuring out how far you can drag something before it affects the next page. Then you can limit the scope of re-calculation of layout within that window, which can have an immense performance and responsiveness benefit.

I also personally believe you shouldn’t need to recalc layout on a page that cannot be seen. That should only be necessary when the user moves to that page. Just-in-time calculation.

i know there is a philosophy of “always correct”, but this comes at a significant performance penalty which can really seriously degrade usability. Even off-line recalculation would be better in another thread - just don’t block the user actions waiting for stuff that affects things they can’t even see.

Even if all you did was recalc the next page, and see if it changed (compare the bitmap). That could limit cast-off processing to the current + next page. And therefore that problem would not scale with score size until the user performed an action that affected the next page.

I know there are other things too, like updating parts and cues which can be gnarly. But sacrificing the 99% use case to cover the 1% doesn’t seem like such a great idea. The lagginess really affects usability, which is a huge proportion of the time spent using. The making sure everything else is displayed correctly on a dependent page could be recalculated when that page is viewed, or exported or printed. Maybe background processing would be better. So it’s correct within a few seconds of making the change, rather than blocking the change. I think I’ve probably said this in the past. the more rules are added, and the more objects, the worse this problem gets.

1 Like

It would help so much if such things could be made to show a shadow while dragging, and defer recalculating until mouseup. For example, resizing a frame in engrave mode works this way.

I am sure the Development Team has evaluated the alternatives and come to the conclusion that the current arrangement is best, at least for the present. There may come a time when on-the-fly, just-in-time formatting will prove the better option, but apparently computers do not (in the aggregate) have that kind of processing speed yet.

Keeping Tabs to a minimum and Condensing turned off provides the best current option for speed.

1 Like

Hi @adrien
In addition to what @Derrek said, I see an improvement in speed during editing large scores, if I go in Engrave mode and click on the Lock Layout icon on the left (in the graphic editing). So that Dorico maintains all the background changes in the same frame (or page), reducing or limiting I think somehow the amount of calculations that he needs to do.
You can then unlock the Layout later or when the frames get too full.

And also work in Galley view instead of page view :slight_smile:

1 Like

OK thanks.

I think serious thought should be given as to whether this is the best way to handle the issue - by putting some task onto the user to perform some magic that appears like it should perform some other function. I wonder how many people never find this, and decide not to go with Dorico because it’s laggy. It should be snappy out of the box. I can edit much larger scores in Sibelius and it doesn’t seem to be a problem, and I don’t get problems with correctness either. Sure there’s a lot more going on with Dorico, esp if you’re doing condensed scores etc. I just have a strong hunch that some profiling could help a lot here. I don’t know how much is done already.

1 Like

7 posts were split to a new topic: Dorico crashes when running Logic Pro at the same time