Profiling Performance on Opera GX

c023-DeV

Member
My game gets a sudden framedrop in Opera GX and I'm not sure why and how to debug/profile it.

I searched the forum, I thought I saw something on the topic somewhere but can't find it. So if there is a topic on this, please point me there, thanks!

How can I profile my game's performance on the Opera GX target platform to find potential bottle necks?
 

O.Stogden

Member
I think the debugger is supposed to work, but for my game at least, the game never boots in Opera GX when in debug mode. Hoping the beta release soon will fix it.

Alternatively you could debug in Windows/Mac/Linux and find the most intensive parts of your game and try to optimize those, as it's likely the most intensive parts in Desktop OS's that will make Opera struggle.

Using show_debug_overlay(true) will help you see if its a step event or draw event issue as well, red bar being the step and yellow being the draw.
 

c023-DeV

Member
Same here, the game doesn't launch with debug. I get a "Debugger has not recieved a response..." message in the IDE.

I've profiled it with Windows and it runs at ~500+ Fps and in Opera it stutters down to like 5 or 6 fps after a minute or so...
 

O.Stogden

Member
If the debug overlay is showing a lot of yellow, it could be something like surfaces not freeing which your windows pc is handling much better than the browser can.
 

gnysek

Member
In my game, draw_sprite_pos seems to cause slowdown (on UWP, HTML5, and Opera GX for sure), as I'm using it to draw shadows. Also matrix functions for sure slows down on UWP, maybe here it's same ( I didn't tested yet).
 

c023-DeV

Member
I'm not using draw_sprite_pos but the surfaces may be a thing (using them for lighting).

I'll try some manual debugging...
 

gnysek

Member
Easiest way will be just to disable drawing them for while. Game will look wrong, but surfaces can have big impact.
 

c023-DeV

Member
Yes, I've done that and it is the Surface drawing...
I wanted to look into a "pure shader way" of doing my lighting but my knowledge of shaders is still super limited. I might open a different thread in the hope to find some clarification.
 

c023-DeV

Member
This is SUPER frustrating. Even if I rip out most of the stuff going on in my game it still slows down. FPS show above 900 and the game slows down to stop motion...

I'm lost. Profiling on windows shows me no hints as the game runs in lightning speed...

Is there anything that I should be aware of that might change this?

I'm using a Wacom Cintiq Companion v1 ... and I'm still stepping in the dark.
 

InvaderKazz

Member
Hi!
Got here for the same kind of issue. The game works fine in YYC and VM for Windows (CPU and RAM are stable within certain range), but on Opera GX i have a slowdown at some point in my game. It does go away when something in the game happens, so i have a very rough idea of where to start looking, thing is, i am at total loss on how to debug. Debugger does not work with Opera GX VM and the console on the browser doesn't show anything.

I am basically disabling sounds and very basic lights effects with gpu blend to see if it is the issue with no luck.

I will try the suggested show_debug_overlay(true) to see if i can find something.

Just leaving a comment here to see if someone else knows something and i i can find what my problem is i'll let you know.

The only error i see in the inspector of opera is "runner.html:250 Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread" which i have no idea what it means. I am assuming is something internal as i have not tried modifying the threads (not even sure it can be modified in GM).

Back to hit my head to the wall...
 

c023-DeV

Member
Hi!
Got here for the same kind of issue. The game works fine in YYC and VM for Windows (CPU and RAM are stable within certain range), but on Opera GX i have a slowdown at some point in my game. It does go away when something in the game happens, so i have a very rough idea of where to start looking, thing is, i am at total loss on how to debug. Debugger does not work with Opera GX VM and the console on the browser doesn't show anything.

I am basically disabling sounds and very basic lights effects with gpu blend to see if it is the issue with no luck.

I will try the suggested show_debug_overlay(true) to see if i can find something.

Just leaving a comment here to see if someone else knows something and i i can find what my problem is i'll let you know.

The only error i see in the inspector of opera is "runner.html:250 Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread" which i have no idea what it means. I am assuming is something internal as i have not tried modifying the threads (not even sure it can be modified in GM).

Back to hit my head to the wall...

Glad to hear there are more with this issue, I've filed a ticket with Yoyo's help center today, since I've also tried it with the recent Beta. I've deactivated all firewalls (while offline) updated all my system components and followed all guides that yoyo offers with no success. Sometimes the the opera console says the debugger is connected but the game doesn't launch... sometimes it doesn't connect at all.

Regarding the performance, I've cut out most parts of my game with no success... so I can only guess that it's something within either opera or the GM runtime.
I'm (freely) guessing that it may have to do with the sleep margin (v-synch) as it reminds me of old issues I had with this. But that is just a wild guess.

Are you also using a notebook with intel processor?

Also Yoyo just replied to my ticket that they are working on something but I'm not sure if it's the debugger or performance issue yet. So be aware of that before you tear apart your game like I did...
 

O.Stogden

Member
Not had issues with TRF, on either a Desktop with a Ryzen CPU or my Laptop with an Intel APU.

The debugger has indeed never worked though, and still doesn't.
 

InvaderKazz

Member
Update here:
Managed to fix the issue with the help of show_debug_overlay(true) which is a little cryptic in the descriptions but it let me know the issue was related to the steps as it kept growing, hence the performance issues.
In this case the mistake was from my part, as i had an instance create in a switch while not checking if it already existed before, OOPS!. Funny thing that made it to the original game (OOPSx2) but it seems that windows had a lot more overhead to deal with it. Game seems fine now performance wise (it is a very small game after all), but of course every time i say that something else appears...

Running Ryzen CPU here.

Now, i sent the public link of the game on Opera GX to some friends for testing and they can't open the game as it crashes (even if they are logued in). It is opening fine in my browser. Have not tried going live as i still have some final polish to do. Send them the VM version for now i guess.
 

gnysek

Member
while not checking if it already existed before, OOPS!
I once made a game, in GMS 1.x, where there was copy of player instance on position x = -3000, so it wasn't visible in room editor (without scrolling a lot). It was discovered few months after release, when one of players came to some wall on right side of level, and kept "right" button pressed for some time, and that second player finally entered into stage :D So I'm not surprised you didn't noticed your bug, it's hard to find out duplicates sometimes. Windows runner generally seems to be one of fastest, what's surprising, in my case it achieves much better scores than any other while it runs on integrated Intel GPU instead of better GeForce. There are some functions in which Xbox One and Xbox Series are faster when using UWP export, but there's also few functions which are 10x worse on that runner (especially matrix changes, drawing text in loop, few more). In my opinion Opera GX is similar - some functions are working really, really fast, while few causes hickups. Without working debugger it will be hard to point out which ones, but I hope we gonna find them all and YYG will optimize things, as OperaGX thanks to WASM seems to be a promising exporter.
 

c023-DeV

Member
Update here:
Managed to fix the issue with the help of show_debug_overlay(true) which is a little cryptic in the descriptions but it let me know the issue was related to the steps as it kept growing, hence the performance issues.
In this case the mistake was from my part, as i had an instance create in a switch while not checking if it already existed before, OOPS!. Funny thing that made it to the original game (OOPSx2) but it seems that windows had a lot more overhead to deal with it. Game seems fine now performance wise (it is a very small game after all), but of course every time i say that something else appears...

Running Ryzen CPU here.

Now, i sent the public link of the game on Opera GX to some friends for testing and they can't open the game as it crashes (even if they are logued in). It is opening fine in my browser. Have not tried going live as i still have some final polish to do. Send them the VM version for now i guess.
Glad you could fix it. Nothing works here. I've reduced the project to just an image with some text and streaming audio and it stutters like crazy. Also, I have the crashing thing when testing on the GMX site too, since yesterday.

Yoyo Help confirmed a performance issue with my game but say it must be on my side. I've sent them a sample to check because there isn't much code from my side to get it to stutter. Like I said, just an Image, text and audio, oh, and a mouse cursor.

If I don't stream the audio I can only noticwe it on the mouse cursor lagging...
 

c023-DeV

Member
Ok, I think I might have found something... after deactivating audio_listener_position() things seem to work much better... even though I still 'feel' a,n overall lag.
(But I'm an old quake player so I know how 120 fps 'feel')
 
Last edited:
Top