High GPU usage in editor with active AnimatedSprites

[SimoB]

Godot version: v3.1.1.stable.official

OS/device including version: Windows 10 Pro 1903 Intel HD Graphics 530 (21.20.16.4550) Nvidia GeForce GTX 960M (430.86)

Issue description: Running Godot on the integrated Intel GPU

1. I have a simple 2D Scene with some Sprite and one AnimatedSprite (3 frames looping at 5fps), every time I switch to that scene tab my GPU usage goes to 90%, if I disable the "Playing" checkbox of the AnimatedSprite, usage goes to 0%. Also, if I go from the 2D mode to the Script mode GPU usage on that tab is still at 85%.

2. In Script mode, GPU usage is always between 15% and 25%.

Is that normal for an AnimatedSprite to use 90% of the GPU? Is it not possible to disable rendering when in Script mode?

[mnn]

This bug is annoying. Why the hell is Godot editor wasting 14% of my 2080ti when on script tab, not having focus and minimized?

Note to myself: Always kill Godot before turning on VR, otherwise Godot will be causing nauseating (literally) frequent FPS drops.

[Calinou]

@mnn If you enable Interface > Editor > Show Update Spinner in the Editor Settings, is the spinner moving continously while in the Script tab? (Without minimizing the editor, of course.)

Also, do you have particles, shaders or active animations in the scene you're currently editing?

[mnn]

@Calinou Yes, it is constantly spinning (even if I focus other window, so cursor in Godot script editor is not blinking). I was under the assumption that being in a Script mode would stop rendering of an opened scene, it seems that is not the case. Yes, the scene I am editing has few AnimatedSprites running, so I guess they still run on the background, even though user cannot see them.

I think all drawing should be paused if it is made not visible - either by selecting different mode (e.g. Script) or if the Godot editor window is not visible (e.g. minimized or outside of any monitor).

PS: By the way, isn't 14% load of a high-end GPU a bit too much for few AnimatedSprites?

[akien-mga]

PS: By the way, isn't 14% load of a high-end GPU a bit too much for few AnimatedSprites?

Not if it runs at 4000 FPS :)

[Calinou]

PS: By the way, isn't 14% load of a high-end GPU a bit too much for few AnimatedSprites?

Depending on your display refresh rate (and whether V-Sync is enabled in the Project Settings), the editor will have to refresh up to 144 times a second. Therefore, it doesn't sound unreasonably high considering the editor draws a lot of 2D elements (which aren't batched).

I noticed that Particles2D and CPUParticles2D don't cause the editor to refresh continuously after switching to the Script tab, but this isn't the case with AnimatedSprite. We should look at fixing this.

[mnn]

I noticed that Particles2D and CPUParticles2D don't cause the editor to refresh continuously after switching to the Script tab, but this isn't the case with AnimatedSprite. We should look at fixing this.

Not if it runs at 4000 FPS :)

I checked to be extra sure :slightly_smiling_face:. So I have 3x AnimatedSprites running at 24FPS and 1x CPUParticles2D (I omitted them initially, because they are not visible [the closed eye icon]).

Depending on your display refresh rate (and whether V-Sync is enabled in the Project Settings), the editor will have to refresh up to 144 times a second. Therefore, it doesn't sound unreasonably high considering the editor draws a lot of 2D elements (which aren't batched).

Only 60Hz, but a 4k resolution and the sprites in AnimatedSprites are rather large (approx. 800x800), so maybe the load is not overblown as it would seem on a first look. V-sync is on. Using Godot at version 3.1.1.stable.official.

I probably should start stopping animated sprites in editor anyway, because it then causes changes in scene file = more potential merge conflicts.

[lawnjelly]

Highly related to this, I was looking at starting a new issue, and I don't know if there is one existing, but any 3d animated skinned objects cause constant updates of the editor, even if that tab isn't opened (e.g. you are in a script tab).

[akien-mga]

Do you still have the same issue with 3.2.alpha3 or later? This issue #33136 seems to indicate that a similar issue is now fixed.

[lawnjelly]

Just tried 3.2 alpha3.

With the animated skinned object open in a tab, if I switch to a different 3d scene tab (without animation) the editor stops the updates (good! from memory I don't think this happened a while ago).

However if the animated skinned object is open in a tab and I switch to script editing, it is still doing the continuous updating, so the issue still exists.

I'll try and make a min reproduction project.

[lawnjelly]

Min reproduction project. IDEUpdateBug.zip

Open in the IDE, then open up 3d tabs with Spatial.tscn, Monster.tscn and Monster2.tscn, and open the .gd script.

If you select the spatial 3d tab (nothing animated) then the script, there are no continuous screen updates. If you select either the Monster.tscn or Monster2.tscn then switch to script you get continuous updates. You can select to show editor updates spinner in editor settings to see this, or use a task manager to see CPU.

Monster.tscn uses AnimationTreePlayer (which is deprecated) and Monster2.tscn uses AnimationTree.

Could _process and _physics_process still be being called on the node even when the tab is not in focus? If so, is this necessary?

[KoBeWi]

Still valid in 3.2.3

[lawnjelly]

I had a little go at trying to fix the 3d skeletons updating even when the script tab is showing (and no 3d window is visible). I maintained a state enum of the current EditorTable (2d, 3d, script etc) value in the EditorNode, and tried checking this before pushing the notification to update the dirty skeleton.

Was getting somewhere, but there turned out to be multiple places that were calling redraw_request, from the MessageQueue, even if I prevented the skeleton update notification. I really am not familiar with the editor or how it works so kind of gave up at that point.

Either there is one update that needs to be prevented, or there are now multiple sources of updates as a result of ignoring this problem for so long. It probably needs someone who is familiar with the editor to fix.