There are quite a few misconceptions being perpetuated in this thread.
First of all, why is Dorico a separate product to Cubase? Because it makes more business sense for Dorico to be a separate program, appealing to different (though overlapping, of course) customers than Cubase, and with a completely different focus. Dorico is a music notation and composition application with strong MIDI editing and virtual instrument features, while Cubase is a fully-fledged digital audio workstation with strong scoring features. Naturally we want to bring Dorico and Cubase closer together, and we will do so, but the two products will not merge into a single one. I can’t talk about the finer details of how the two applications will come closer together, but if you continue to be patient, you will see.
Secondly, any sluggishness in Dorico’s performance is not due to its choice of user interface framework. No UI framework is perfect, but Qt is exceptionally feature-rich and really well-suited to an application like Dorico that requires very precise typography, 2D drawing, printing, graphics export, and so on. Of course we evaluated the use of Steinberg’s existing GUI libraries, but they were not at the time (and are still not today) suitable for use in Dorico, and we made the decision to focus on building our application rather than spending a year or more iterating on the existing GUI library – time that we considered to be essentially reinventing the wheel.
It doesn’t make any appreciable difference to the performance of the application what colours you use, and whether buttons have rounded corners. (The assertion that it does suggests a lack of familiarity with modern GUI tools and their performance characteristics.) It is also very important that an application that thousands of users are using for many hours at a time is comfortable and pleasurable to work in, so even if it were the case that drawing a button in a particular colour or with rounded colours had any impact on the performance of the application, that trade-off would very likely still be worth making if it improved the user experience of the software.
In addition, the parts of the user interface added in Dorico 4 – the Mixer, the Key Editor, the Keyboard and Fretboard panels, etc. – are built using a newer user interface technology that is part of Qt that is designed to make use of hardware acceleration and which can be very performant indeed. At the present time, the actual score display is using an older, imperative drawing technique that cannot itself take advantage of hardware acceleration, so when it is redrawn while you are scrolling the score on a very large display (e.g. a 4K or 5K display) at a low zoom level, such that there are thousands of glyphs and primitives on-screen, you will experience a slower frame-rate, but each redraw never takes even 100ms, even on large displays. Redraw is a negligible part of the overall response time to making an edit in Dorico.
We do plan to migrate the whole application to use the newer, hardware accelerated GUI framework in the months and years to come, but this is a big job and will not be completed in one development cycle. And, in any case, although it will be great to have the score scrolling at 60fps regardless of zoom level and the number of pixels in the display, that on its own will not make inputting and editing music in Dorico faster and more performant.
Finally, the performance characteristics of music layout and of text layout could not be more different. Both domains are very complex, much more complex than might be apparent to the lay person. Indeed, I don’t have any direct experience of working on text layout, but since it is such a fundamental aspect of how information is presented to the user when computing, it is something for which there are very well-optimised approaches (including strong support at the platform level, in terms of rich text, font layout, typography, script support, etc.). Developers of word processors and text processing tools can build on top of this excellent support. (Dorico’s text handling itself relies on these very same technologies, of course.)
In short: no text processing or word processing software needs to implement text layout on its own (unless its developers really want to, and have a good reason to do so).
Music layout is a problem of comparable complexity to text layout, but since it is a much more niche requirement, there is no platform-level support for it. So any music notation software has to implement music layout on its own – and Dorico is doing it to a level of sophistication that has not been attempted by any previous application, with the possible exception of Lilypond, which can require multiple minutes to lay out a score. Dorico is attempting to do this in as close to real time as it can. And music layout is only one part of the computation that Dorico is performing when it responds to each edit triggered by the user.
We aren’t satisfied with Dorico’s overall level of performance, and there is plenty of scope for us to continue to improve its performance, as and when we can put in the required effort in these areas. As I often say, we have a small team (smaller than before, because some of our developers are also working on other projects within Steinberg), and so we have to choose what we work on carefully. Improving performance is just one of many things competing for our time and attention. However, please be assured that the use of Qt as the framework upon which the application is built is not a factor that is holding back improving Dorico’s performance.
I’m going to close this thread now, since I don’t think there is much to be gained by further back and forth on this topic.