Bug Report: Lag Spike Caused & Manipulatable by Sustains

[MistrDJ]

Issue Checklist

• [x] I have read the Contributing Guide
• [x] I have checked the Issues/Discussions pages to see if my issue has already been reported
• [x] I have properly titled my issue

Platform

Itch.io (Downloadable Build) - Windows

Browser

None

Version

0.6.2

Description (include any images, videos, errors, or crash logs)

ive heard of people reporting a very specific lag spike in Cocoa Erect that happens at a certain point in the song, around a minute or so in during the verse with the long BF hold notes. so technically this issue has been reported. but i want to bring up a more in depth version of this bug, because it is not exclusive to Cocoa Erect, has nothin to do with the background as some have theorized. I've been encountering this bug since Destination 2 (specifically 0.5.1), the sustains are the culprit (read more in the images attached to the Steps To Reproduce section)

https://github.com/user-attachments/assets/7c9ec61d-860e-4007-9d06-a6276f219990

https://github.com/user-attachments/assets/984f3093-7caf-4dcf-9f0d-50f41d8526a4

https://github.com/user-attachments/assets/25ac3a9e-77a6-4589-b9b1-f48a5e6af7ae

https://github.com/user-attachments/assets/c40b9d36-d503-4016-9471-6eb1ff4650bb

Steps to Reproduce

1. Play a song that features a notable amount of sustains (i.e. most BF songs, not Pico songs)
2. That's it

as you'll read in these images, I can manipulate the lag spike to occur later in the song by purposefully dropping sustains earlier in the song. That's what leads me to believe the sustains are the culprit, I've been toying around with this since September.

[trayfellow]

Oh My God It Was This The Whole Time

[ThatGreenBlur]

thank you for finding the root cause of this issue all along!

[Prod-42]

Great job finding the issue!! I'm glad we finally know the reason

[AbnormalPoof]

[Lasercar]

[Lasercar]

I don't see anything here that'd hint to why this happens: https://github.com/FunkinCrew/Funkin/compare/v0.5.0...v0.5.1

So either it happens in an earlier version, or it's a library issue.

(or, it could be yet another bug caused by changes to the conductor...........)

[Average-FNF-Modder]

I have also been experiencing this infuriating bug since 5.0 and I am so glad to see someone finally crack it.

[EliteMasterEric]

For those looking to diagnose and resolve performance issues (without relying on speculation), checkout the new docs on the Tracy profiler: https://github.com/FunkinCrew/Funkin/blob/main/docs/TRACY.md

[DemiSans]

Omg this whole time I thought it was just problem on my side, and I didnt even try to report it bc its was too random, I wasnt able to stably reproduce it or even describe, but seems like others actually experience it too. I cant get P rank bc of this😞 Still happens in 0.6.4 btw

[NotHyper-474]

I did some profiling using Tracy on Senpai Erect where I managed to experience stutters using V-Sync at 60 FPS, since I couldn't get them otherwise. Anyways, two things grabbed my attention:

Cairo.showGlyphs taking 100 ms

Garbage Collection in function in Strumline

Stutters caused by the Cairo function seemed very prevalent throughout the session. The one for the strumline only occurred once. Annoyingly, no signs of anything related to sustains causing stutters anywhere so this might require some thorough testing. I have the saved trace here in case anyone wants to look through it.

[EliteMasterEric]

Cairo.showGlyphs taking 100 ms

Wait, your device is using the Cairo renderer? Why isn't it using the OpenGL renderer?

[AbnormalPoof]

Cairo.showGlyphs taking 100 ms

Wait, your device is using the Cairo renderer? Why isn't it using the OpenGL renderer?

If it wasn't using OpenGL, the game wouldn't be playable at all. (https://github.com/FunkinCrew/Funkin/pull/3770)

[NotHyper-474]

Cairo.showGlyphs taking 100 ms

Wait, your device is using the Cairo renderer? Why isn't it using the OpenGL renderer?

It definitely is using the OpenGL renderer, in fact, it seems to use both.

Details

I suppose that texts (or more specifically BitmapData) use the Cairo renderer for some reason.

[MAZ12211]

Huge claps if this bug doesn't come back in V0.7

[DemiSans]

its either related to something else or this didnt actually fixed bc I still experience this massive but rare (1-3) lagspikes on certain BF songs (Thorns Erect (Nightmare) and DadBattle Erect (Nigtmare)). On 0.7.3

[ThatGreenBlur]

its either related to something else or this didnt actually fixed bc I still experience this massive but rare (1-3) lagspikes on certain BF songs (Thorns Erect (Nightmare) and DadBattle Erect (Nigtmare)). On 0.7.3

@DemiSans thats because the root of this issue still exists https://github.com/FunkinCrew/Funkin/issues/4760

[Hundrec]

It’s looking like this bug was never fixed in 0.7.0, and more investigation is needed.

[Hundrec]

Don't occur with debug display enabled. May be caused by FlxText.

[ACrazyTown]

I suppose that texts (or more specifically BitmapData) use the Cairo renderer for some reason.

OpenFL doesn't support hardware accelerated text rendering. Text is drawn by Cairo (software renderer) onto a bitmap and then that bitmap is uploaded to the GPU and drawn by OpenGL. OpenGL is just drawing the text's bitmap, the actual heavy part of rendering the text is handled by Cairo.

[DemiSans]

not even in the 0.7.5 milestone😔