[CAN-10814] MixConsole: Off-screen drawing of racks slows everything down while scrolling Mixer

Cubase
,
#1
  1. New project
  2. Add 256 audio tracks
  3. Open and maximize MixConsole
  4. Disable Left and Right Zones
  5. Have the following racks enabled: Routing, Inserts, Equalizers, Channel Strip, Sends.
  6. Enable Racks * button > Fixed Number of Slots
  7. Disable Racks * button > Exclusive Expanded Rack
  8. Zoom out maximally: show the maximum amount of channels.

Case A: Major slowdown
9. Have all Rack tabs expanded. (it doesn’t matter how much content is visible in the view)
10. Scroll horizontally using the scroll bar
-> Very low refresh rate while scrolling. Noticeably slows down everything.

Case B: Minor slowdown
9. Have none of the Rack tabs expanded.
10. Scroll horizontally using the scroll bar
-> Some slowdown while scrolling.




Conclusions:

  • MixConsole scrolling is the most CPU intensive UI interaction in Cubase.
  • In both case A and B the same amount of area is drawn (the full window).
  • The big difference is how many elements need to be drawn while scrolling, but:
  • Even if the rack contents is off-screen (outside of the rack area), it slows down more!
  • The solution is to not calculate any off-screen graphics in the racks or anywhere else.


    The GIFs were recorded on Windows 10.
#2

Is your system the one in your sig?

#3

Yes. Keep in mind, the point of the report is not the exact performance on my system. The point here is to avoid drawing off-screen/out of view graphics that aren’t visible.

This will make for better performance on any system, especially in Cubase’s case of (presumably) single-core software rendering. Resolutions are increasing to 4K so there can’t be time wasted drawing invisible stuff.

#4

I’m not sure if I get the point? You create 256 Audio channels and open 256 channel editors at the same time (though the screen is to small to display them all) and you find this slowdown surprising?

#5

I’m not sure why you started to reply to every new thread I post with counterarguments and retorts. Did I do something wrong to you? Anyway:

I did not open 256 channel editor windows… you already know that. Elements that aren’t visible shouldn’t waste CPU unless the coding is extremely naive.

I just scroll around in the mixer which happens at 60 fps in my alternate, hardware rendered DAW, but at 1-2 fps in Cubase. Yeah, my PC could handle this if it was optimized, it’s not like great math problems need to be solved here. I suspect it’s just too much unnecessary software rendering.

#6

Any idea what the CPU load is for arming 256 audiochannels?
I suggest to look into your taskmanager cpu utilisation
In other words, it’s not the GPU drawing slow, but the CPU to feed the GPU with the most current information. And since you hover back and forth like a maniac, you’re generating more requests than your CPU can deliver. Remember big part of Cubase is realtime, you can’t compare that with graphics rendering in cad/cam or DTP

#7

I can’t reproduce this at all. But it’s interesting, will check it out on the system where I can reproduce a couple GUI problems.
djw, I’m going to send you a PM between today and tomorrow morning.

#8

Alright, I’ll be available to help as best as I can.

#9

Just checked on that system (my home DAW, by the way). With all racks expanded I see a slow-down. Not as extreme as you see, but noticeable.

#10

That’s probably because I don’t have the fastest PC, though it’s decent at multicore processing. The MixConsole scrolling performance stands out as a lot slower than any other UI interactions however.

#11

That’s because with the mixer updating, you query the status of all mixer objects, so everytime you move the mixer position, with 256 channels, you query the status of all components of each channel * 256 multiple times per second.
I don’t think you can speed this up, unless the interval gets bigger, generating less polling requests.
You can validate this by for example running prime95 in the background on all cores, I suspect screen refresh will be even slower.

#12

I think it’s all related to drawing, not reading a bunch of variables.

A lot of elements actually stay static when scrolling but they are probably re-drawn, which is another possible optimization.

#13

Yep, that can be a design choice, I don’t have insight into that.

#14

I have a similar issue - but with vst interfaces and resizing track heights, widths, etc…stutters which can almost bring the system to a halt. Strangely, if I switch audio drivers (to the generic asio) and back while program is open, stuttering disappears for a while. Have trashed pref’s, to no avail. First time c9 has “misbehaved” for me, ever. I’m on win7, quad capture, i73700.

#15

I have a report about track manipulations here: https://www.steinberg.net/forums/viewtopic.php?f=253&t=122729

However, I have heard about this time related slowdown before (for VST plugin graphics too) and it seems like its own issue. You could report this in its own thread, preferably with an exact way to reproduce it (even if it means to leave Cubase on for a longer time, or using it for x hours).

#16

I’ve amended my original issue report from August 19 w steps to reproduce, so hopefully someone at SB will notice.

#17

If you want to be sure it’s noticed, send the issue to MySteinberg technical support if you haven’t.