Godot: Poor 2D editor performance on macOS 10.13.x and newer with Intel Graphics

[hmans]

Godot version:
3.0.2 for macOS (without C#)

OS/device including version:
MacBook Air 2017, 1,8 GHz i5, 8 GB RAM, Intel HD Graphics 6000

Issue description:
The Godot editor is running quite slowly, best described as "stuck in 15 FPS" (very unscientific, I agree, but that is what it feels like.) This is while working on a very simple 2D game (which I have included for reference.)

The game itself runs smoothly, it's just the editor that is sluggish. It doesn't matter if I'm moving around in the 2D editor or editing code, everything is just relatively unresponsive.

The log output states OpenGL ES 3.0 Renderer: Intel(R) HD Graphics 6000, but the whole thing feels like it's falling back to some sort of fully software-based rendering mode.

(I should add that I'm fully aware that a HD 6000 is no GeForce GTX, but it's not _entirely_ useless, and Godot is _running_ the game on it just fine.)

Steps to reproduce:
Start Godot on a Mac similar to the one described above and edit the attached game (or probably any other game.)

Minimal reproduction project:
SpaceRage2-master.zip

[akien-mga]

On an HD 3000 as you had mentioned in the title initially I would not be surprised (it barely supports OpenGL 3.3, if at all on macOS), but on an HD 6000 it's indeed surprisingly bad.

[hmans]

Yeah, the "3000" was a typo.

[ghost]

Can't confirm this issue on my MacBook Air with MacOS Sierra 10.12.6.
Here everything runs smoothly.

So this could eventually be a problem specific to MacOS High Sierra?

OS/device including version:
OS: MacOS Sierra 10.12.6
MacBook Air 11"
2015
1,6 GHz Intel Core i5
4 GB RAM
Intel HD Graphics 6000

[hmans]

Addendum to my initial bug report:

When I continually decrease the size of the editor window, there is a _noticeable_ improvement in responsiveness/render speed, moving from the perceived 15 FPS when running in fullscreen all the way to perceived 60 FPS once the window is really, really small.

What kind of performance _should_ I be expecting? I have been (naively; I know nothing about Godot's internals) assuming the IDE would make full use of the graphics chip's rendering capabilities (like it appears to do on Windows). Is this correct?

Either way, if there is any additional information I can provide, please let me know. Sadly I don't have access to other MacBook Airs or same or similar configuration that still run Non-High Sierra to test @Foxcataria's hypothesis.

[gabriel-aranha]

I have the same MacBook Air and comparing with my windows desktop I can't reproduce this low FPS.

[hmans]

@aranha92, would you describe your IDE's performance as "perceived 60 FPS"? The best I can get -- only after reducing the window size to less than fullscreen, though -- is something that feels like 30. My biggest problem right now is that I have no idea what kind of performance I should be expecting.

[ghost]

@hmans, if we imagine some kind of scale where we have 60 FPS for the smoothest reaction of the editor down to 0 FPS where no reaction is present than you normally should expect the full 60 FPS. This should normally be independent of the editor size. So whether it is fullscreen or not, you always should have best performance.

The solution to this issue is really hard to find...did you compile the engine yourself or do you just use the stable release you can download in form of a binary (that's the way I did)? And does this behaviour always occur across every project or is just this specific project?
And what could also be important: Is it only Godot that does not work properly?

[hmans]

Thanks @Foxcataria, it helps me to know that I actually _am_ dealing with unexpected behavior, and not just being ignorant. :b

did you compile the engine yourself or do you just use the stable release you can download in form of a binary (that's the way I did)?

I'm using the stock binary available from the website.

And does this behaviour always occur across every project or is just this specific project?

I will try some more projects, but I don't remember the editor ever being any kind of smooth on my system.

Is it only Godot that does not work properly?

Overall, things appear to be working fine on this system -- do note that Godot actually _plays the game_ just fine (with the expected 60 FPS, it's a really simple project.) So I doubt this is a general issue of my system.

If there is anything else I can do to help, or anything I could look into, please let me know.

[ghost]

Hm...that's really strange...
I tried to 'reproduce' the editors behavior with your project one more time, but I was not successful...
So at the moment I don't have any idea of what could cause the problems, sorry :/

[hmans]

I will try to get my hands on a 2017 MacBook Air that has a fresh High Sierra install (or maybe wipe mine if I find the time to set up everything fresh...) and try again then. Other than that, I don't know what to try next, beyond waiting for that new Vulcan-based renderer that was mentioned on the blog. It's all a bit frustrating :/

[hmans]

PS. - if you want to close this issue for the time being, please go ahead and do so. I'm happy to reopen it (or create a new one) if I find any leads. I'm not closing it myself since I don't know what your regular process regarding issues like this is.

[hmans]

Quick question to subscribers to this issue (thanks for sticking around): is there a way to get a FPS debug counter for the Godot IDE (not the running game -- just the IDE)?

[akien-mga]

Quick question to subscribers to this issue (thanks for sticking around): is there a way to get a FPS debug counter for the Godot IDE (not the running game -- just the IDE)?

Run Godot in verbose mode: godot --verbose.

[hmans]

Thanks @akien-mga! Unfortunately, the logging appears to stop once I open a project.

When opening the project directly via --verbose -e, I get continued logging, but the output doesn't include FPS information. I only get:

...
load resource: res://assets/ship.png (cached)
load resource: res://scripts/FunkyCam2D.gd (cached)
load resource: res://scenes/Background.tscn (cached)
load resource: res://scenes/RigidPlayer.tscn (cached)
load resource: res://scripts/FunkyCam2D.gd (cached)
EditorSettings Save OK!
Audio Driver CoreAudio average latency: 11ms (frame=512)
Audio Driver CoreAudio average latency: 11ms (frame=512)
Audio Driver CoreAudio average latency: 11ms (frame=512)
...

Getting some editor FPS info would be a great help for trying to further isolate this issue.

[ghost]

I'm also interested in the way we can get for example FPS information about the editor, because all this information could help to solve problems on an individual specific system when almost nobody can reproduce the issues.

@hmans at the moment I get the same type of output as you showed here. So it seems to be the expected output, but I'm not sure.

[akien-mga]

It used to be possible but it looks like we removed the feature/bug in #16005.

[akien-mga]

I've readded an option for it in #17666.

[hmans]

Thanks! I'll give it a spin as soon as possible.

[hmans]

A quick update: I've compiled today's master (with #17666 merged in) to do some testing.

While the editor is idle, it's reporting around 105 FPS.

When I interact with my project's Test.tscn -- eg. by dragging around the viewport in the editor -- the FPS drops dramatically, depending on the editor size:

• When the editor is running at the MBA's built-in screen's full resolution of 1440x900, it drops to around 30 FPS (while I pan/zoom the viewport around.)

• When it's running at a slightly larger size (after connecting it to an external x1440 monitor; the editor being around 1600x1000 maybe), it drops to around 20 FPS.

While I'm still not sure what kind of performance I _should_ be expecting, I'm definitely not seeing what @Foxcataria suggested in this comment.

I've tried the whole thing with some other projects as well, with the same results.

(I know this probably doesn't bring us close to an answer, but I still wanted to give an update. Thanks @akien-mga for adding --print-fps back in!)

[hmans]

I'd like to add one more thing: I don't even need to interact with my project's scene to reproduce this on my machine -- it's enough to open the About Godot box and scroll the credits. Same drops in FPS.

[hmans]

Allow me to bump this issue with a quick update:

I'm observing _exactly the same issue_ with the new Blender 2.8 as opposed the currently stable Blender 2.7. I know this isn't terribly scientific, but considering Blender 2.8 touts OpenGL 3.3 support... maybe this could be a hint? (A quick tour of Google didn't reveal any indicators about any sort of incompatibility between OpenGL 3.3 and the Macbook Air model I have, though.)

I know this isn't terribly scientific... I'm posting it on the slim chance that this will maybe connect some dots somewhere and help narrow it down.

[jesselawson]

I develop on both Windows and Mac and one oddity I have noticed about Macs is that sometimes you will see multiple "Godot" processes lurking in the background, taking up just as much processing power as your editor.

In my case, every time I Play the game from the editor and it launches a window, there's a zombie Godot process lurking around 30-50% CPU usage that wont go away--not even when I close the editor--unless I do pkill -f Godot.

When your editor starts to slow down, open a Terminal window and type in top then hit enter. See what's eating up all your CPU.

[aaronfranke]

Does this problem occur with 3.0.6 and/or 3.1-beta? Does using the GLES 2 renderer help?

[ignasKavaliauskas]

Not sure but may this issue relate to this one?

I'm having this issue in the mentioned link, my IDE feels low fps as well and only updates the screen by clicking and resizing the window. (I'm on Intel HD 620).

If this is not related to this issue, I can create a new issue for that, since i could not find it here.
PS: I'm aware that there is a way to solve this but maybe there is also a way by not downgrading the intel drivers :)

[Calinou]

@IgnasKavaliauskas This should be resolved by updating your driver to the latest version provided by Intel, see https://github.com/godotengine/godot/issues/23069#issuecomment-471168356.

That said, that issue doesn't seem to be related to the one reported by OP here.

[hmans]

Just in case people are still following this after all this time, I just tested this with the current 3.2.stable.official build for macOS, and it's exhibiting the same behaviour.

Since opening this issue, I've upgraded my machine to a MacBook Pro 13" 2018 with 2,3 GHz 4-core i5, 16 GB of RAM and an Intel Iris Plus Graphics 655.

Running Godot with --print-fps gives me around 60 FPS when it's just sitting there and idling, but once I start interacting with it (eg. dragging around the 2D editor viewport), FPS drop to a near-constant 9 (!) when the editor is running in full-screen. (The interaction I perform to debug this issue is simple: I just drag around the viewport using the middle mouse button.)

As observed earlier, when I make the editor window smaller, performance improves, but obviously this is not a desirable workaround.

I don't know much (well, anything) about the Godot code base, so I can only speculate, but it seems like the editor is falling back to some sort of software rendering (which would also explain why the performance gets worse with increased editor window sizes.)

Just with the Macbook Air I initially encountered this on, this new Macbook only has an integrated GPU. I will try to find someone with Mac that has a full GPU so I can see how Godot behaves there.

Some additional observations:

• This only appears to happen in the 2D viewport. The 3D viewport appears to be mostly fine. (There is still an FPS drop, but only to 40-50.)
• The Godot process continuously uses around 12% CPU, even when it's just idling.
• The problem does not seem to affect running games/scenes.
• Switching the project from GLES2 to GLES3 didn't make a difference.

If there is anything I can do to help, please let me know.

[hmans]

Okay, BIG update here: when I disable "Rulers" in the 2D editor's "View" dropdown menu, the performance becomes _pitch perfect_.

Some weird performance bug/regression in the code that draws the 2D rulers?

Edit: not just the Rulers. In fact, the more 2D UI I disable (Helpers, Guides, Origin, ...), the faster things become. Re-enabling eg. the Grid instantly kills performance.

[Calinou]

@hmans This is kind of expected (even if it's not obvious at first), as Godot doesn't use batching for 2D elements yet. Support for batching is planned for Godot 4.0 when using the GLES2 renderer. Draw calls are also significantly cheaper in Vulkan, so the issue should also be less noticeable when using Vulkan.

@lawnjelly is also working on 2D performance improvements in GLES2, see https://github.com/godotengine/godot/pull/35696.

[hmans]

Thanks for the swift response, @Calinou. When using Godot on my Windows PC (i5 with a proper GPU), everything is working fine. Is this also expected? This is the one thing that's bothering me -- I always use my Windows PC for working with Godot because the macOS version is so slow, but I would much rather work on my Mac.

[lawnjelly]

Okay, BIG update here: when I disable "Rulers" in the 2D editor's "View" dropdown menu, the performance becomes _pitch perfect_.

Some weird performance bug/regression in the code that draws the 2D rulers?

Edit: not just the Rulers. In fact, the more 2D UI I disable (Helpers, Guides, Origin, ...), the faster things become. Re-enabling eg. the Grid instantly kills performance.

This may be the problem. There are different OpenGL primitives (GL_POINTS, GL_POINTS, GL_LINES, GL_TRIANGLES, GL_TRIANGLE_FAN are used in the Godot code) and hardware / drivers are often only optimized for triangles. On some hardware I have vague memories that drawing lines / points may be very slow.

In fact you may find that lines are drawn under the hood on some systems by making them into pairs of triangles. Some hardware in the past I believe intentionally crippled performance for lines, in order to differentiate GPU lines sold to consumers and those sold to professionals (for use in CAD etc).

The ultimate solution to this problem (if this is indeed the cause of the slowdown) can be to draw lines ourself, by converting to triangles / using a special shader and not using the line primitive at all. And maybe the same for points. But if it occurring only on very rare hardware, maybe it won't be a high priority. We might find that for example, drawing lines on some mobile may be slow too, just depends how the driver / GPU is doing it. If this is a problem, the other alternative is to put pressure on Apple / Intel to do a sensible implementation. I doubt Blender users are happy either.

My latest changes to the 2d renderer will speed up 2d quads due to batching, but I'm not sure it will cure this issue, if it is indeed due to slow lines / point primitives implementation. On the other hand if it is simply due to lack of batching in the lines (which I would think less likely, but still possible), then I can speed up the lines by batching (just haven't done this yet, as it may not be important to optimize).

Incidentally, this could be a possible explanation why Blender is running slow too, you may find they are also using lines / points in 2.8. (but also it could be due to other changes in their renderer, I haven't tried 2.8 yet)

[hmans]

My latest changes to the 2d renderer will speed up 2d quads due to batching, but I'm not sure it will cure this issue, if it is indeed due to slow lines / point primitives implementation. On the other hand if it is simply due to lack of batching in the lines (which I would think less likely, but still possible), then I can speed up the lines by batching (just haven't done this yet, as it may not be important to optimize).

@lawnjelly If these changes are in the new 3.2.2 beta, then I can confirm that the situation has not improved. :'( Thanks for the update though!

[lawnjelly]

It is very probably just the mac having poor support / intentionally crippling GL_LINES. I'll try and put in a project setting / editor setting to draw the lines as quads, it might not look so good but will solve the problem (if the hypothesis is correct). It's on my todo list! :+1:

It might be using a software fallback method to render the GL_LINES on some hardware.

[hmans]

@lawnjelly Awesome! If there's anything I can do to help, let me know.

[lawnjelly]

Just to add I have another report on twitter of rulers helping with the issue:
https://twitter.com/gianmichele_m/status/1257941316534747136

It seems in this case to only be occurring on GLES2, which is notable (the initial report was for GLES3).

[hmans]

As stated on Twitter, GLES3 vs. 2 doesn't make a difference here.

(Is switching the editor project between these setups using the top-right dropdown enough, or would I need to do something else?)

[lawnjelly]

(Is switching the editor project between these setups using the top-right dropdown enough, or would I need to do something else?)

Just switching the top-right dropdown should do it.

By the way, anyone who can build from source can test out the PR above that we are hoping will fix this (the PR is mostly complete).

[hmans]

By the way, anyone who can build from source can test out the PR above that we are hoping will fix this (the PR is mostly complete).

I'll give it a whirl.

[hmans]

I've tried the PR and given feedback in the PR itself.

For anyone else following this issue here, here's a little video I made to document the choppiness:

https://youtu.be/yhC0xs_MjoI

[lawnjelly]

Well now it seems reducing GL_LINES didn't help we are somewhat back to square one. Still assuming it is rendering that is the problem, some ideas:

• Maybe some unsupport feature is causing it to drop back to software rasterizer (I have long distant memories of this being a thing, like decades ago...). If this was the case, then CPU would be sky high.
• Number of drawcalls as Calinou suggested. Now a contender. I'd be amazed that it would have such an effect on desktop but it is possible, maybe those gridlines are adding up.

I've also suspected something to do with the sleeping and power saving in the editor on Macs, but that doesn't tie in with switching off the ruler speeding it up. It would be nice to get it profiled too. That would show us if anything unexpected is appearing in CPU, and if it is drawcalls the driver typically shows up for a large percentage of time.

[hmans]

When doing the "grid drag test" from the video, the editor process seems to sit at around 7-8% CPU, and, according to Activity Monitor, at ~23% GPU, whatever this metric means in the context of macOS. Screenshot:

When I just let it idle, CPU goes down to 4%-ish, and GPU to 0%. So, yeah, drawcalls?

[hmans]

Me again, eep!

I just tried the web-based version of the editor (from this URL) on my Mac, and it's running beautifully (specifically, it doesn't exhibit the performance regression that this issue is about.)

Browser: Microsoft Edge 83.

Maybe this can help you pin things down further.

[lawnjelly]

I read something else yesterday (sorry, lost the link) which made me think again that we could be doing something causing it to fall back to a software rasterizer (despite the GL_LINES tests).

Perhaps the WebGL implementation is avoiding this. The number of drawcalls is the same on the web version, so that suggests number of drawcalls is unlikely to be the problem, unless there's some huge difference in that respect (usually drawcalls are more expensive on web, not less!).

That's assuming it is the rendering.

In the Native IDE (Not the browser)

_sorry my fault for the confusion_ :grinning:
You say in the OP, that the 'game itself runs smoothly' but not the editor. This suggests you may be able to work out what is causing a sudden dropoff in performance in the IDE by adding various features to a blank project.

• Try creating an empty project and gradually adding 2d(?) features until you get the slowdown. Not necessarily the NUMBER of features, but the type of node, e.g. sprite, polygon, line.
• It could also be related to something like the framebuffer choice (2d / 3d / 3d effects etc). If you try changing this in the IDE and you get a large difference in performance this could be a clue.

The rendering guys here would use a similar process of detective work to find if a particular feature was causing the slowdown (if we had the test device).

After all the editor is just a Godot project, so it is likely that something being added will dramatically slow the frame rate.

That news though is very encouraging it sounds like a simple change will be all that is needed to fix it. :+1:

[hmans]

You may be able to figure it out yourself by creating an empty project and gradually adding 2d(?) features until you get the slowdown. Or maybe it's the framebuffer choice (2d / 3d / 3d effects etc). The rendering guys here would probably do similar (if we had the test device).

I'm going to put the web version of the editor under some pressure to see if I can reproduce the issue there.

[lawnjelly]

You may be able to figure it out yourself by creating an empty project and gradually adding 2d(?) features until you get the slowdown. Or maybe it's the framebuffer choice (2d / 3d / 3d effects etc). The rendering guys here would probably do similar (if we had the test device).

I'm going to put the web version of the editor under some pressure to see if I can reproduce the issue there.

Me and @clayjohn discussed this yesterday, we weren't sure on what method Edge browser is using for WebGL on mac, whether it is translating WebGL to Metal or going to GLES2 etc. If it is going straight to Metal it might be avoiding driver issues in GLES2. Although WebGL is based on the GLES2 API, it often gets translated to another API (e.g. ANGLE on windows going to directx) rather than mapping 1:1 to GLES2 commands.

So you may not find much by playing with the browser version (although worth a try). Far more relevant is to try running different projects from the native IDE with different UI items, lines (of different thickness), polygons, frame buffer, effects etc, to try and work if one particular aspect is causing a dramatic slowdown (putting it into software rasterizer mode).

[hmans]

As a first test, I just kept adding 2D sprites to a scene to see how it would affect the editor's performance, and it did eventually drop down to 30 and later 15 frames per second (I didn't measure these scientifically -- is there a way to have the editor print FPS?)

Then I deleted the sprites again, and the whole thing went back to peak performance.

As a side note, this was still significantly better than the native Mac version, where even just opening an empty project would give me 8-15 FPS with the grid enabled.

Looking at the simplicity of the scene in the screenshot, I would naively assume that the editor would remain at 60 FPS, but I'm still not sure if I'm simply expecting the wrong thing. (I'm basing this expectation on the simple and very unscientific observation that I'm not seeing any of these performance issues in similar game making tools running on the same machine. I know, it's never that simple... :b)

[hmans]

I've now done the same test in Chrome 83 (Mac), and interestingly, the editor remained (mostly) smooth as butter, even with a much higher number of sprites added. Huh.

[hmans]

I couldn't test with Firefox since the editor wouldn't even start there, unfortunately (Firefox 76.0.1, Mac).

[hmans]

Just a quick update that this issue is still around in 3.2.2 Beta 4. (None of the changes made me expect any different, I just wanted to test it anyway.) MBP 13" 2018

[hmans]

Hey everyone, a quick update on this issue: I dug out an oooolllld Macbook Air from 2011 and started Godot on it, and lo and behold, it did not have the issue; the 2D editor -- with grid enabled -- was just as responsive as the 3D editor (even though overall performance wasn't _great_. I didn't use --print-fps, but would estimate things at around 45-ish. My own MBP drops down to 10 FPS in the 2D editor.)

Specs of that old machine:

Now, I don't know if this is because of the different graphics unit (Intel HD Graphics 3000), or because that Mac was still running High Sierra, but the latter sounds a lot more likely.

[lawnjelly]

We may have this cracked. Anyone else who can test my build in #39758 would be welcome. :+1:

[hmans]

@lawnjelly I am (extremely!) happy to report that this appears to have solved the issue, yes. 🎉

I created a new GLES3 project, and once the orphan_method setting was set to "Fresh Buffer" (and restarting), everything was buttery smooth. Is this also coming to the GLES2 renderer?

Good work & thank you!

[lawnjelly]

@lawnjelly I am (extremely!) happy to report that this appears to have solved the issue, yes.

I created a new GLES3 project, and once the orphan_method setting was set to "Fresh Buffer" (and restarting), everything was buttery smooth. Is this also coming to the GLES2 renderer?

Good work & thank you!

Great! :+1:

I'm just finishing up the PR now, I have it working for all the 2d stuff, I'm just checking whether the same modification might be beneficial anywhere else (3d, immediate geometry etc). It will be for GLES2 as well.

[akien-mga]

Fixed by #42734.