Sluggish UI and performance on Mac Studio M2 Max

[Hanz Meyzer]

The GUI is not fully GPU accelerated, so the more pixels, the slower it is. You could say that it is fast for CPU rendering. Still, using the CPU for that is a bad idea, regarding today's possible resolutions like two times 5k or similar... You are just ignoring obvious, visible facts here and seem to be to lazy to do a proper testing, too.

Regarding the second problem, laggy operations if you copy, paste song sections or simply switching tracks, so how would you explain those lags?

Compare this with Ableton, which gui runs blazingly fast on 5k, even upscaled on multiple monitors. There are no lags at all.

You can literally feel the difference.

Bitwig GUI input is somewhat delayed all the time, esp. in the arranger. No such thing in Ableton. I can't use BW on dual screen either, it will turn into a stuttering mess.

This is the obvious difference in speed of C++/near the metal (Ableton) compared to JAVA (Bitwig). Surely Bitwig did already a lot for speed, and certainly Bitwig handles way more graphics than an usual JAVA IDE. Also from developer perspective, JAVA might be a good choice, since you do not need to care for OS specifics.

Yet a DAW is about performance and precision in workflow, and this still is not really fixed since 2016....

Also that JAVA almost comes close to C++ speed in some specific raw tests simply is a lie. I have read those raw tests, too. But show me a single JAVA application with a lot of graphics engine which actually feels fast... Compared to a C++ thing or a browser engine driven application. Even a app written in Swift will feel faster, since here full GPU acceleration is not a problem.

Using JAVA in the real world commonly results in excessive memory usage, poor responsiveness, poorly GPU accelerated graphics. I can't find any example which would prove the opposite. Do you know those IntelliJ IDEs? Even VSCode is like 20 times faster than that, and VSCode mainly runs javascript in a chrome engine.

[Jac459]

The GUI is not fully GPU accelerated, so the more pixels, the slower it is. You could say that it is fast for CPU rendering. Still, using the CPU for that is a bad idea, regarding today's possible resolutions like two times 5k or similar... You are just ignoring obvious, visible facts here and seem to be to lazy to do a proper testing, too.

Regarding the second problem, laggy operations if you copy, paste song sections or simply switching tracks, so how would you explain those lags?

Compare this with Ableton, which gui runs blazingly fast on 5k, even upscaled on multiple monitors. There are no lags at all.

You can literally feel the difference.

Bitwig GUI input is somewhat delayed all the time, esp. in the arranger. No such thing in Ableton. I can't use BW on dual screen either, it will turn into a stuttering mess.

This is the obvious difference in speed of C++/near the metal (Ableton) compared to JAVA (Bitwig). Surely Bitwig did already a lot for speed, and certainly Bitwig handles way more graphics than an usual JAVA IDE. Also from developer perspective, JAVA might be a good choice, since you do not need to care for OS specifics.

Yet a DAW is about performance and precision in workflow, and this still is not really fixed since 2016....

Also that JAVA almost comes close to C++ speed in some specific raw tests simply is a lie. I have read those raw tests, too. But show me a single JAVA application with a lot of graphics engine which actually feels fast... Compared to a C++ thing or a browser engine driven application. Even a app written in Swift will feel faster, since here full GPU acceleration is not a problem.

Using JAVA in the real world commonly results in excessive memory usage, poor responsiveness, poorly GPU accelerated graphics. I can't find any example which would prove the opposite. Do you know those IntelliJ IDEs? Even VSCode is like 20 times faster than that, and VSCode mainly runs javascript in a chrome engine.

It seems you didn't take the time to read my post. Yet as I feel in a polite mood, I will repeat you again:

1 - I don't need to benchmark because I NEVER said that the UI was fast in every circumstances and it would be faster with a 3D acceleration. Of course it would be. I am not ignoring any facts. Please take the time to read other people posts before trying to be insulting, it doesn't make you look good. What I said is that many of us are unimpacted by these slowness and supporting 3D acceleration would have other negative impact like portability between Windows / Linux / MacOS and maintainability / simplicity of coding.

2 - I never said Java was as fast as C. Actually I said the contrary. What I said is that Java was the fastest language with managed resources / garbage collection (and yes, faster than .Net Core). I am sure you perfectly know that C is a compiled language and is not using JIT Compilation or Virtual layers like .Net and Java. Again, please read the post of the person you are reacting to, again make you look insulting, and not that smart...

3 - Laggy operation on copy paste can be due to many factors like algorithmic problem or optimisation for smaller number but certainly not garbage collection. Moreover, if you pretend to be able to know how a program react just by looking at it, I am sure you are earning billions being consultant for banks... (or maybe it is plain bullshit ).

Conclusion: I am absolutely agreeing with you on the fact that using C or C++ and hardware acceleration for Bitwig would most certainly make a more responsive UI (and I was already saying that in my previous post). What I am saying, (and please read me well) is that the massive refactoring to go to C/C++ and the reduction of maintainability stability it would generate is ABSOLUTELY NOT WORTH IT in my view and they should NOT do it. It would make the support of Linux much more complex and the whole program would be certainly much less stable (I guess we both know for a fact that C or even more C++ is a much more complex language to maintain and to keep bug free than Java).
But it is just my point of view, you are free to have your own priorities. Just again, avoid answering post without understanding what is said...

[BobDog]

Can't see them moving away from Java myself, lots of work there!

I have had big problems with the BW GUI before on a MacPro trashcan with D700 Graphics Cards (4K), pdxindy I think had the same machine with D500s and did not have the same problem.

I now have it running on a iMac I7 with AMD Radeon Pro 5500 (5k) and I do not have the same problems, my little M1 laptop also seems to have no problems.

I tried to find my previous posts here about it but failed, I think the speed issue though was colourspace transformations.

So I think my point is that poor gui performance is machine/os/graphics card dependent, I guess BW don't have every combination to test.

[1234Hi5!]

It’s never felt overly laggy with my m1 air. The new ableton beta definitely seems a bit snappier but for the purposes of making music I don’t feel it matters that much

[Hanz Meyzer]

You can literally see jow slow the arranger/pianoroll GUI in Bitwig is here:
Proof slow gui

Also Polarity used a very low resolution, yet it stutters like hell, the more notes are appearing.

[pdxindy]

You can literally see jow slow the arranger/pianoroll GUI in Bitwig is here:
Proof slow gui

Also Polarity used a very low resolution, yet it stutters like hell, the more notes are appearing.

He rendered approx 12,000 notes in 24 bars!

You're upset the GUI slowed down. Me, I'm kinda impressed it managed to do it at all.

[BobDog]

Yep, I think that is a bit of an unfair test!

[muzicxs]

"A bit"?

Testing DAWs in this manner could be intriguing, purely for entertainment purposes, even if it offers no practical value.

[Hanz Meyzer]

There should be no slowdown at all, and performance not so drastically going down then suddenly. Pianoroll is very simple to draw in comparison to the arranger. So I think this clearly indicates how slow the gui is.

[Jac459]

"A bit"?

Testing DAWs in this manner could be intriguing, purely for entertainment purposes, even if it offers no practical value.

100% agree.

[muzicxs]

5.1.3 has a performance fix that could be interesting to the people in this thread reporting performance issues:

Improved GUI performance for projects with a large number of scenes and a large number of tracks [34662]

Does this fix it? Would be great to report back.

[pdxindy]

5.1.3 has a performance fix that could be interesting to the people in this thread reporting performance issues:

Improved GUI performance for projects with a large number of scenes and a large number of tracks [34662]

Does this fix it? Would be great to report back.

One person on the Discord is reporting a significant improvement on Windows on large projects.

[kresbeatz]

There was no GUI rendering speed improvements with latest Bitwig for me. Here is the sluggishness of GUI on 5.1.3 (MacMini M2 Pro 32Gb RAM, Sonoma 14.3.1, RME UFX, LG 40" UltraWide 5k2k, very easy project). Mostly Bitwig native instruments with small amount of modulations and couple of sliced audio loops which made with Slice-in-Place function (and it seems the amount of slices are the main culprit of sluggishness in GUI - but it's still very light slicing IMO). Just look on the play cursor as well as track volume meters and how stuttery they are. If I open something else, especially in a full view (like EQ+ or similar) things got worse.

https://youtu.be/LI71AdfrntY

[Hanz Meyzer]

They need to improve the gui drawing code, "simply"... I guess they already made the fastest gui available in JAVA world. Yet it can't compete in any way with a C++, metal, CoreGraphics whatever approach. Maybe they could also improve by reimagining / refactoring the rendering chain, reducing the gpu interruptions by the cpu or so... I imagine that there currently is a pretty wild rendering chain.

I've looked into Ableton a bit... It seems to use Qt, and this then provides an impressive performance. Is Qt available for JAVA, too?

@kresbeatz Can you report this to Bitwig support?

[kresbeatz]

They need to improve the gui drawing code, "simply"... I guess they already made the fastest gui available in JAVA world. Yet it can't compete in any way with a C++, metal, CoreGraphics whatever approach. Maybe they could also improve by reimagining / refactoring the rendering chain, reducing the gpu interruptions by the cpu or so... I imagine that there currently is a pretty wild rendering chain.

I've looked into Ableton a bit... It seems to use Qt, and this then provides an impressive performance. Is Qt available for JAVA, too?

@kresbeatz Can you report this to Bitwig support?

I will report it. I also think this GUI lag in such a small project is very unpleasing and it causing much worse experience as the project getting bigger. Usually I work with audio a lot (including chopping, fade in/out) and it is getting uncomfortable very soon (especially when using layered editing and there are several chopped loops across the tracks).

There was some graphics improvements, that's for sure (for example, it was almost impossible to use multi-samples in Bitwig sampler and automating the Select knob as FPS was down to the floor). Now I'm loading my old patches for Sampler which lagged a lot and now they're looking much faster. But still, A LOT of improvement needed, especially in Arrangement window and Detail Editor when using lots of slices.