How is the Snes9X UI so snappy?

The start-up time for snes9x is unreal, it's practically instantaneous. bsnes spins its wheels for like 1 second before showing the window, then another second before showing the status bar. All the menu accesses feel laggy and flicker. Mesen spins its wheels for a half second before showing the window, then another half before showing the menu. I'm on an SSD too. I'm pretty sure this isn't UPX related? I don't understand what snes9x, the oldest of them all, is doing here to feel so snappy. Is it just ultranative with its windows port and everyone else is using wrappers and stuff?

I really think this is the next area of improvement for bsnes. Enough features, make the windows stop feeling like I'm on a mechanical drive. I don't even really care if you have to take away fancy features like the cheat editor and state manager and quad mappings.

It is not UPX related. The startup time is not "unreal" -- instead, it is actually how software should be; it's that the other softwares are fooling/screwing around, likely compounded by things like .NET Framework (Mesen/Mesen-S) and Qt (bsnes) (though in the case of bsnes, I expect it's less of that and more of "stuff" going on in native code, but this is speculative on my part. Could also be things like XML parsers and other whatnots). Menu interaction/oddities/speed are often due to said frameworks. For extra enjoyment, check out how many times programs using said frameworks end up doing things like paint/redraw/refresh calls on all sorts of things without good reason. But there are other possibilities like reading databases or indexes off disk (see: Mesen-S "game selection screen" etc.).

In summary, profiling startup time does not rank highly on developers' lists -- profiling emulation runtime is substantially more important. Likewise, UX (that is: user experience) tends to get ranked very low as well. Let us count the number of emulators that do stuff like when clicking a menu item cause the audio to start looping, have audio crackling (often difficult to solve for a myriad of reasons), and a multitude of other "why does it have to be this way" nuances... :P

I could show the bsnes main window instantaneously too, but then the UI would be unresponsive while I go through setting everything else up.

But yes, Snes9X-Windows is native, raw Win32 API calls. bsnes uses the hiro abstraction layer and Mesen-S uses C#.

Fully native is the way to go, but your GUI will behave differently on every OS, and you will need to maintain multiple entire frontends, which is *way* too much of a burden for one-man teams like me and Sour. If we had an OV2 for Windows, a BearOso for Linux, and a zones for macOS, we could manage.

I guess we have a difference in priorities. The main window taking a second to open doesn't really bother me when I'm intending to play a game for 20+ minutes. I will say that the new list-view panel switching is dreadful, but I'll fix it.

Menus were slow on Windows because I was trying to run the emulation loop while they were open, and Windows is not designed with that in mind, unlike GTK+, Qt, and Cocoa/macOS. I went back to pausing during menus, so they should be just as fast as your average Windows program now.

Anyway, I'd really like some help, and I'd be happy to pay real money for it. I'm just one guy, maintaining 24+ emulation cores, a hardware abstraction layer for video/audio/input across every major OS, four entire GUI abstraction layer toolkit wrappers, and then on top of all of that ... bsnes is just a side project. Oh and I have a day job here, and several hours of Japanese language tutoring per week.

Startup lag really matters when developing. That is why I use some less accurate emulators normally and the more accurate only rarely for testing. Also why I use a lightweight terminal and nano, if a terminal/editor/program takes longer than 100ms to start, it's too slow.

For bsnes you probably say to use the "reload rom" option and keep it open. Probably works for some, I don't like that kind of workflow, I want a clean slate when switching things (like debugging option X you have these things open and these breakpoints set, then doing something else you'd have to click click clean them all up).

Do you feel like the bsnes ui layout is practically finalized, though? It seems feature complete and then some, you even got DRC working now. How much future maintenance do we really need to worry about by going fully native?



You're right, but then again it's not like I gave it much thought when there were bigger problems to fix. It finally stood out when I ran snes9x 1.60 for the first time in a while. I also can't remember the status bar delay happening in v108, but it happens in the 108.7 nightly I just compiled. Any recent changes that could've caused that?



I kind of want to find hex_usr and see if he's interested in a "winhigan" fork with a native ui, global mappings, and my system switching method. I miss being able to quickly test your cores, it's like a hobby of mine just vanished. The new ui doesn't work on Windows yet and even if it did, I fear it'll be too slow for the library testing I used to pull off. You made fixes to the M68K and GB cores, but I can't get it working to see if they fixed any other games on my lists.