Some thoughts on troubleshooting the UI responsiveness issue

This post is to solve some people’s doubts about what I asked and suggest regarding computer graphic accelerators.

I occasionally read this thread filled with complaints from Dorico users who had met UI responsiveness issues:
https://www.steinberg.net/forums/viewtopic.php?f=246&t=103521

It has something weird to me that most of them are having their issues met on Windows. My purchased version of Dorico 1.0 does not have unexpected UI responsiveness issues through the following configurations I tested:

  • Intel Skull-Canyon NUC (i7-6770HQ @ 2.6GHz) running Windows 10 RS1 Educational, Iris Pro 580 with 16GB VRAM (it uses 1/2 of my total system RAM). Note that I hadn’t try Hackintosh installation on this model yet, awaiting for next macOS Sierra update due to the Skylake NVMe support.
  • ThinkPad W530 (i7-3740QM @ 2.70GHz) running Windows 10 RS1, using NVidia Quadro K2000M discrete-only mode with 2GB VRAM and 32GB RAM.
  • The same W530 running Hackintosh macOS El Capitan, using only Intel HD4000 under 1600x900 resolution.
  • My main laptop: MacBook Pro 13-inch Early-2015 (i5-5287U @ 2.9GHz) running macOS Sierra 10.12.0, Intel Iris Graphics 6100 w/ 1.5GB VRAM occupied from 8GB RAM.

What I am thinking of is to encourage those people who are not having UI responsiveness issues with Dorico to post their hardware components information below, including actual OS type and version, your actual CPU model, the graphic card / accelerator w/ VRAM, total system RAM. (Do not forget to address whether your graphic card is Quadro or NVS or Geforce or FireGL or FirePro or Radeon, etc. since it may matter.)

The reason is that these information could be used as cross-reference, helping Steinberg to figure out what could trigger the graphic issues. At least, suggesting Mac users to use those mac models with at least HD4000 is not a bad idea, despite that it is not official suggestion from Steinberg.

According to Daniel, “Steinberg does not have any official guidance about which kinds of graphic adaptors work best with Dorico.” Thus, my information are supposed to be non-official suggestions only.

We don’t believe that any of the responsiveness issues that users are experiencing with Dorico are related to speed of screen redraw or are related to specific models of GPU. Dorico’s performance is CPU-bound, not GPU-bound.

Thanks. I edited my initial post, suggesting people to provide their CPU information as well.

What I mean, Shiki, is that we are quite aware of the exact causes for specific operations in Dorico to be slower than is ideal, and they are not related to specific hardware configurations. I don’t think that collecting CPU and GPU information is going to be particularly informative, since I’m pretty sure all it will show is that faster hardware runs Dorico faster, and in any case without a proper set of tests that can be run in an automated fashion, you are entirely reliant on subjective feedback from other users about what feels slow to them.

We have reliable performance benchmarks that we run as part of our automated build process. We know that a number of operations in Dorico are slower than they should be. As has been pointed out by both Ben and Paul over the last few days, we have emphasised safety over speed in terms of our approach to processing edits to the score, and we are in the process of optimising a number of operations at the moment. I am pretty confident that the program will feel significantly faster on all configurations for many operations in the first post-release update.

There’s no mystery here, as far as we’re concerned. Some operations are slower than they should be, we know why, and we’re in the process of speeding them up.

Any idea when lyric entry is going to be faster Daniel? It is a real productivity delay at the moment as I am a fast touch typer - but Dorico doesn’t keep up!

I’m afraid there won’t be any improvement in this specific area in the next minor update, Basso, but we do certainly intend to try to improve it as soon as we can.