Cura 4.0.0 incredibly slow on Mac OSX High Sierra

[3dnerd 6]

Hello,

 

today I updated to Cura 4.0.0 on my Mac OSX High Sierra V10.13.6, 2.8 GHz Intel Core i7 (2011), 16GB RAM.

But Cura4.0.0 is incredibly slow. I cannot work with it. I made a video where you can see how lazy Cura 4.0.0 acts on scrollbars, or 3D view changes, rotation of 3D objects:

 

Video of lazy Cura4.0.0

 

Why is cura so slow??? I cannot use it this way!

 

 

Thanks fpr any help...

 

Edited March 28, 2019 by 3dnerd

[nallath 1,120]

It seems like that you have encountered an issue caused by the drivers of OSX. See https://github.com/Ultimaker/Cura/issues/4505

[ahoeben 1,951]

As a direct answer to why Cura is so slow on your computer: Instead of drawing the interface and the gcode using hardware acceleration, everything is being drawn using a software renderer. This happens because your hardware renderer does not support OpenGL 4.x. But instead of OS X saying "sorry, I don't support that" (in which case Cura would use OpenGL 2.x which your computer does support and everything would work ok), OS X says "sure, I can do that" but then proceeds to do everything really slowly. In a future version of Cura, this oddity must be detected and worked around.

[3dnerd 6]

@nallath:

 

Thanks for reply, but what is the solution now? When there will be a fast Cura also for iMacs?

 

 

@ahoeben:

 

Thanks for reply,

 

In a future version of Cura, this oddity must be detected and worked around.

 

I agree! So I'm singing '...all we can do is sit and wait...'

 

Thanks god I have also Simpilfy3D installed - and this is incredibly fast!

 

[burtoogle 514]

14 hours ago, ahoeben said:

In a future version of Cura, this oddity must be detected and worked around

 

So can't we just have a user preference that forces the use of OpenGL 2?

[nallath 1,120]

That would be one of the solutions yeah.

[ahoeben 1,951]

I would consider such a preference a workaround. This can be detected by looking at the opengl context description. It is just not something that needed to be done before.

 

This is what happens on other Windows and on Linux (and on older versions of Cura, which used an older version of Qt) with a GPU that does not support the advanced opengl features):

Cura: Hey OS, can I have an advanced rendering context?

OS: No, sorry, the GPU does not support that

Cura: Ok, can I have a simpler rendering context?

OS: No problem, this GPU can handle that just fine

Cura: Ok, awesome! I'll just use the simplified layerview.

 

On OSX, with the same hardware, the following happens:

Cura: Hey OS, can I have an advanced rendering context?

OS X: Sure thing, here's your context (it uses software rendering, but you don't mind, right?)

Cura: Ok, awesome! I'll use that context for everything!

 

That last "Ok" from Cura is the problem. Cura should not accept software rendering when asking for an OpenGL 4 context at the start of Cura.

Edited March 29, 2019 by ahoeben

[ahoeben 1,951]

Note that the same can also happen on Linux if you run Cura in a virtual machine (depending on the VM).

[burtoogle 514]

So it is possible for Cura to detect that the OpenGL context will use software rendering by inspecting the response from OS X?

 

If so, then that should be done so the program is at least usable. If not, then it has to be a user preference.

[nallath 1,120]

It's still stupid as hell that OSX is basicly not giving you what you ask for. I asked for a cola, not a pepsi 😉 

[ahoeben 1,951]

Actually, it gives you exactly what you ask for. You ask for a 4.1 context, you get a 4.1 context. It is unfortunately that you can not ask specifically for a hardware accelerated 4.1 context.

 

I had a look. The problem is that you need a window to query the gpu_type (or gl.initializeOpenGLFunctions will fail and subsequent gl.glGetString calls will segfault). So OpenGLContext would need to open a (small, invisible) window to check the gpu_type of the context.

 

I'll try to continue this train of thought later today.

Edited March 29, 2019 by ahoeben

[3dnerd 6]

Hi guys,

 

great work here - please keep going on.

 

Thanks a lot...

[hoegge 6]

Not sure why this is so great work. The speed issue has been around for long and seems to be finally fixed in Cura 3.6 and then it is already f..... up again in version 4.0 without testing on Macs that are not brand new running High Sierra? It took almost a year to get Cura back up to a usable state / speed. Come on - how can software be released in that state?

 

 

[ahoeben 1,951]

You would rather have no people putting their time in to fixing this issue? Ok, I guess.

[hoegge 6]

21 minutes ago, ahoeben said:

You would rather have no people putting their time in to fixing this issue? Ok, I guess.

Sorry - think I misunderstood 3dnerd's comment. Your work is greatly appreciated. The frustration was directed at Ultimaker - waiting for so long to get decent performance and then they seem to have broken it again.

 

So my apologies.

 

/Hoegge

[nallath 1,120]

I think you seem to not realize how much time it would take to do what you suggest. Ultimaker has grown quite a lot the past few years, but there is a limit to the amount of testing we can do. So that means we have to make choices. Which also means that we don't test on every single setup that we theoretically support (or even close to that).

That being said, there have been multiple issues with OSX in the past with speed. Some of them are actually completely out of our control as they were caused by the framework we used (and the smouldering hatred apple seems to have for developers). This in turn leads to us not even being able to support older OSX versions because we can't build for them (or if we did, we'd have to spend so much time and money on it that it would cost far to much).

So yeah, I get the frustration. I really do. But calling people out when we are trying to resolve your issue isn't helping (and especially not if they, unlike me, aren't even paid to do so ;))

[3dnerd 6]

Hi,

 

@nallath: what does that mean now? Can we expect a better performance under OSX High Sierra in a reasonable amount of time?

Or should we switch to Windows?  

[ahoeben 1,951]

It means I am still trying time to work on it in my spare time. Even if I or someone else fix it, you will have to wait until the next release of Cura.

[3dnerd 6]

@ahoeben:

 

Thanks fo making it clear to me.

Edited April 3, 2019 by 3dnerd

[nilrog 103]

Do you have a plan, after fixing this slow performance on current MacOS versions, for how to handle the fact that OpenGL is deprecated in MacOS Mojave?

[ahoeben 1,951]

"deprecated" does not mean it will no longer work.

 

Cura does not talk directly to the GPU or to OpenGL. It uses a cross platform GUI framework named Qt. We're going to have to see how Qt will handle the deprecation of OpenGL.

[nilrog 103]

25 minutes ago, ahoeben said:

"deprecated" does not mean it will no longer work.

I did not say that it doesn't work...but given the aggressive way Apple tends to remove deprecated stuff means that the days are numbered for using OpenGL on MacOS.

[ahoeben 1,951]

I have made some progress in detecting the issue, and made a "pull request" here:

https://github.com/Ultimaker/Uranium/pull/478

Unfortunately this needs to be fixed in a place in the Cura code that is not easily accessible. So it needs to be integrated into (test-)builds before it can be tested on affected OSX machines.

[nallath 1,120]

1 minute ago, ahoeben said:

I have made some progress in detecting the issue, and made a "pull request" here:

https://github.com/Ultimaker/Uranium/pull/478

Unfortunately this needs to be fixed in a place in the Cura code that is not easily accessible. So it needs to be integrated into (test-)builds before it can be tested on affected OSX machines.

Damn, you beat me to it 😉

[ahoeben 1,951]

3 minutes ago, nallath said:

Damn, you beat me to it 😉

 

I gave you enough time 😉