Page 1 of 1
Posted: 09-11-21 8:45 pm
by adiantek
Watch this with audio: You will hear when I'm clicking the touchpad. I must wait when I press escape or when I change a directory in Synthesia or when I click "Play a song" in the main menu. With F6 (FPS counter) I see a temporary fall to 52/55 FPS from a constant 60 FPS.

Device: Surface Pro X (arm64-based) with the charger connected.
OS: Windows 11 Edu (10.0.22000 Build 22000)
Game version: Synthesia-r5621
Keyboard: Yamaha DGX-670

It would be nice to see logs when a task took too long (for example: "Parsing scores.xml took too long: 123456ms"). My scores.xml has 384 KB, metadata_store.xml 190 KB.

PS. - there is low performance when scrolling the song list. When I scrolling settings (very fast!) there is no problem.

Posted: 09-13-21 1:47 pm
by Nicholas
Hmm, I'm not able to reproduce either the long wait after clicking or the poor scrolling performance. I wonder if they've got something to do with the x86 emulation on your Surface Pro X? Clicking into any of the song list groups is usually "instant" (say, on the very next frame or before your finger has left the mouse button, etc.).

And I can scroll wildly through the big list (using the "All Songs (one big list)" group) when it has nearly 1000 songs, all without the meter dropping to 58 or so FPS.

That said, I don't usually test on a machine with lots of score data. Even though I wouldn't expect that to make a difference, I would be remiss not to double-check.

If you could send along your scores.xml and songProgressCache.xml files (either attached like you did with log.txt last time or emailed to ) that would be helpful for replicating your environment on my side. Thanks!

Posted: 09-15-21 11:11 am
by Nicholas
Thanks for sending along those files. I still wasn't able to see any difference when navigating between groups, but I did spot a small performance hiccup when scrolling quickly in a list that has many different score numbers on the left. I'm guessing the Surface Pro X's x86 emulation is magnifying the effect of that hiccup. Scrolling as wildly as I could in a debug build, I was able to get it to drop to around 30fps.

I was able to tame it by making two small changes for a combined ~10x speed-up in the relevant code. Now wild scrolling (even in a debug build) doesn't appreciably drop the frame rate at all. It had to do with the speed of rendering all the text on the screen, so I'm wondering if the two situations aren't related and navigating into/out of groups (where all of the text has to change at once) won't also improve?

When the next preview goes out (with all the recent MusicXML work), these performance improvements will be included.

Posted: 09-17-21 8:33 pm
by adiantek
Ok, thanks for fixing it! I will wait for the next dev update.

Posted: 09-30-21 6:15 pm
by adiantek
Switching GUI is faster, but scrolling has still low FPS:

Posted: 10-02-21 8:32 am
by Nicholas
Hmm, I was hoping it would be a little better than that. I suppose the x86 emulation tax is now the biggest contributing factor.

Have you noticed any other apps on that same machine with similar slow-downs in odd places vs. running them natively on an x86 processor?

Posted: 10-04-21 9:10 am
by JimNYC
Isn't Windows 11 supposed to improve emulation?

Posted: 10-05-21 7:29 pm
by adiantek
It depends on the app, but in general emulating x86 is slower than emulating amd64. There are a lot of tools in arm64: vscode, Java, Chromium, 7-zip, Minecraft Java Edition, Teams. Osu! is the biggest exception for me if we're talking about performance - it's C# and x86 only, and I've 180-230 FPS with emulation during play and it's very stable + osu has a lot of visual effects. Emulated Minecraft doesn't have the sense to run (max 2 FPS), but Java x86 + emulation is not sth good, that's why there is arm64 version (about 30/40 FPS).

IMO profiler could help us to look what causes this trouble. Minecraft has shift+f3 and it displays a pie chart:
I can use key numbers (1-9) to select a category or 0 to go up. In the code it looks like this:


start/end section should do nothing if the pie chart is not enabled. Or maybe if you have already this, could you tell me how to use it? Settings work very quickly, so the font renderer is not the source of the problem.

@JimNYC windows 11 added only support to Windows 64-bit emulation (amd64 -> arm64) and they added a new ABI: ARM64EC - it allows mixing arm64 with amd64 (eg. arm64 .exe and amd64 .dll).

Posted: 10-07-21 1:24 pm
by Nicholas
There is definitely room for improvement inside Synthesia as far as efficiency goes. It's one of the embarrassments.

I do use profiling tools and I know where the worst of the bottlenecks are today (especially during song playback). It's just been a matter of balancing time spent on new features with time spent cleaning up old messes.

If it does a better job with x64 emulation, it might finally be time to make a 64-bit build for Windows. I'd only been holding off to have one fewer build to test, but these days it's almost hard to find a 32-bit Windows machine.