Mac M1 - Route Viewer is unresponsive on start with high CPU usage

[alex-wenzel]

I'm running Route Viewer on a Sonoma M1 Mac using the terminal command from #1023, mono /Applications/OpenBVE.app/Contents/Resources/RouteViewer.exe. I see a new window with the instructions in the top left to use F7 to open a route or F8 to access options. At this point, neither F7, F8, nor any other key appears to have any effect. In addition, the corresponding mono process uses around 100% CPU consistently until I quit the application. This behavior is also the same if I start Route Viewer from within the Tools menu in OpenBVE.

I've tried to find logging for Route Viewer, if any, but I can only find the log files for OpenBVE itself in ~/.config/openBVE/Settings. If Route Viewer outputs logs somewhere, I'd be happy to share those.

Versions MacOS: Sonoma 14.3.1, M1 chip OpenBVE: 1.11.0.6 Mono: 6.12.0.206

[leezer3]

Try ESC to pop up the menu. This was an oversight for the case when no route was loaded (it shouldn't be showing the F7 / F8) I've fixed this, but I can't explain the 100% CPU though.

Both F7 and F8 should be no-ops on 64-bit apple. https://github.com/leezer3/OpenBVE/blob/master/source/RouteViewer/ProgramR.cs#L465

Let me do some testing over the next few days on the Hackintosh and see if that manages to reproduce anything, but that's only High Sierra.

[alex-wenzel]

ESC works, I was able to load a route and use the viewer!

The CPU usage issue is still present on the blank pre-loading screen. It also remains high even if I close just the window itself but don't quit Mono. Every instance of Route Viewer seems to create a new Mono process that persists and uses the CPU at 80-100%, whether or not the Route Viewer window still exists, until Mono itself is terminated. Unless there's some kind of cleanup that Route Viewer is supposed to handle with Mono when a window is closed, this might be more of a Mono bug.

A couple more potentially OSX- and/or M1-specific issues that I found once I was able to load a route:

• ~It doesn't appear to be possible to change the y-axis position on a MacBook (unless you've have an external numpad accessory) based on this code:~ https://github.com/leezer3/OpenBVE/blob/3494e06ab7719fec53afdb7b344364237b0aad17/source/RouteViewer/ProgramR.cs#L594 ~I've been re-binding most OpenBVE numpad controls that I run into issues with, but I assume I'd have to build from source to change the Route Viewer ones.~ EDIT: I've solved the numpad problem by installing Karabiner and importing this rule that creates a keypad with Fn+[789uiojkl]. It would still be helpful to have key bindings for Mac that don't require third party software, but this issue is no longer preventing me from using Route Viewer.

• The ESC menu doesn't capture the keyboard, only mouse clicks work for selecting options.

[leezer3]

Added keyboard navigation to the menu for Route Viewer, oversight....

Mono not cleaning up after itself and leaving a hanging process is a perpetual problem I'm afraid (although I've only really run across it on Linux to date, but I don't use a Mac day to day) There's various hacks stuffed throughout the code to combat this, and you seem to have found another instance.

It normally occurs when another window is pushed from an existing process. If you launch Route Viewer directly from the terminal, as opposed to the tools menu, does this kill itself correctly on exit?

With regards to the massive CPU usage, I've made a small change to attempt to limit the initial screen to 5fps until the menu is triggered. If that works OK, possibly we might want to implement an overall limit to the viewer's FPS on OS-X (I'd guess possibly V-Sync limiting) to try and keep the CPU usage under better control. It doesn't do this on Windows or the Debian box I've got though, CPU usage is ~4%

[alex-wenzel]

I suppose it would make sense that OS-X has similar Mono bugs as on Linux, especially for functionality as fundamental as process management. When I use Route Viewer from the terminal, I can close with window (with red 'X'), but the command will still be running in the terminal and the process will still use close to 100% of a CPU. The only way to stop it is to stop Mono entirely from the top menu (Mono -> Quit) or CTRL+C in the terminal, or by manually killing the processes in Activity Monitor.

An FPS limit would make sense. It has the appearance of something that's looping excessively with relatively little to do inside the loops, which it appears to be doing even when it doesn't have a window to draw. Btw, "it" in my last sentence could refer to Mono or Route Viewer, I don't know enough about this framework to say which. In my very basic 50-line route file, Route Viewer looks like its routinely getting over 200 fps, but I can't actually tell for sure because it redraws the FPS number too fast for it to legible.