Black screen with Godot logo and 100% CPU when trying to open an existing 3.5 project

[Poonaka]

Godot version

3.5.1 RC1

System information

Mac OS Monterey 12.5.1, AMD Radeon Pro 5000M 8GB, MacBook Pro 16" 2019

Issue description

Started a GLES3, 2d project using Godot 3.5. Upgraded to 3.5.1 RC1 and opening that project hangs the editor with the beach ball cursor/100% CPU.

After around 2-3 minutes, the project finally opens. If I create a new empty project, it opens quickly as expected.

I've attached the project.

Steps to reproduce

Try to open the attached project.

Minimal reproduction project

2D Platformer Udemy.zip

[Calinou]

Try removing the .import/ folder within the project folder while the editor is closed, then open the editor again. (It's a hidden folder, so you'll need to toggle hidden folders in Finder to see it.)

[Poonaka]

Try removing the .import/ folder within the project folder while the editor is closed, then open the editor again. (It's a hidden folder, so you'll need to toggle hidden folders in Finder to see it.)

Tried that, it opened the editor right away but then hung on re-importing assets for 2-3 mins at the 92% mark.

Edit: Then the project opened up. Also, closing the project and then re-opening it causes the initial problem.

[Zireael07]

Can you try removing assets one by one to see which one is the problematic one? (I'd start with FBX, I recall people having issues in the alpha/rc)

[Poonaka]

I only have .png files as assets in this project.

I tried removing them one by one with their .import version (including the icon.png). The problem persisted until they were all gone. I was able to open the project several times quickly with no .png files included.

I then tried adding them back in, using a different order than removed. The problem resumed on the first png asset.

While testing I noticed that the project opens fine about 1 out of 10 times. With a few instances where it opened fine a few times in a row.

I tried another test, where I added a .jpeg to my main scene. Then closed Godot, removed all the .png files and tried to open it again. It had the same problem... I then killed Godot, replaced the .png files and tried opening it again. This time the editor opened right away but it got stuck on re-importing assets for the .jpeg in the main scene 2 mins or so.

Here's the jpeg

I noticed as well that in this process, my .jpeg file got renamed with a time stamp postfix. An .import file was created for the original name and another for the new name. I'm new to Godot, so I don't know if that's normal or not...

[Zireael07]

Hmm. Can you check what are your project settings? Does it use ETC2? Based on your description, it looks like it's surprisingly slow when compressing textures into whatever format Godot textures use in your project

[Poonaka]

It looks like it has S3TC and ETC2 enabled.

[Zireael07]

Try fiddling with those, maybe you'll find which one is causing the stall.

[Poonaka]

I used a stop watch to test this.

With only S3TC checked, the editor restarted and took 3 mins 35 seconds to open. I closed it and re-opened it again and it took 3 mins 34 seconds to open.

With only ETC2 checked, the editor restarted and took 3 mins 36 seconds to open. I closed it and re-opened it again, this time it opened right away. Tried it again and it took 3 mins 37 seconds to open.

I also tried turning off all the options. The editor restarted right away. I then closed it and re-opened it and it took 3 mins and 37 seconds to open. So not sure what's going on there...

[Poonaka]

Some more tests. I created a new project and added the same assets to it. I dragged one of the png files into the scene and it hung for about 30 seconds. After I saved the scene and closed/re-opened that project a few times, which opened right away. I then tried reimporting them with the "2d pixel" presets and that was fine too.

[lawnjelly]

Just to note a possible bug in AnimatedSprite::_notification I noticed while looking at this.

I am not sure it should be a good idea for it to emit multiple signals on one update to NOTIFICATION_INTERNAL_PROCESS, and multiple update()s. This could possible cause stalls after a long frame.

Unsure whether this has anything to do with responsibility for this bug though.