OS X Port Bugs
ripose-jp opened this issue · 3 comments
This is an issue intended to list all the problems with Memento on OS X so that they can easily be fixed at a later date or by someone who wants to fix them.
I was able to get Memento to compile in VM, but because the VM doesn't support video acceleration or audio, so there is really no feasible way for me to develop or test Memento on OS X.
Bugs
-
Fullscreen is broken
- The way Memento handles fullscreen is that it waits for the playerFullscreenChanged signal to be omitted and adjusts the window size of Memento accordingly. The window resizing is all handled in MainWindow.
-
The name of Memento in the OS X menu bar is lowercase
This can probably be fixed by changing the name of Memento in main.cpp. If this is changed, it should be in a preprocessor directive specific to OS X or it will break configurations on other OSes.Didn't work. The name in the menu bar is likely tied to the name of the executable file.
-
The startup message box points OS X users to the wrong location for adding dictionaries- OS X manages to move things in the menu bar around automatically to make their OS consistent. This message can be changed in MainWindow's showEvent method.
-
OS X will sleep on inactivity(Implemented not tested)
If anyone has any more bugs to contribute, post them below and I'll see if I can give any insight on how to fix them.
The biggest obstacle to porting Memento is macOS it how macOS handles fullscreening applications.
When Memento is fullscreened on macOS and video is playing, the whole system will hang for about 30 seconds before finally entering a functional fullscreen. This is completely unique to macOS and happens no other platform. After extensive messing around, I've discovered that MpvWidget is likely rendering frames on the UI thread. I came to this conclusion after I experienced the same behavior in libmpv's qt_opengl example, code which Memento uses with almost no modification. Interestingly, I did not experience this issue in libmpv's qml example, at least not with the same frequency. After reading Qt's documentation on QQuickFramebufferObject, I found that QQuickFramebufferObject renders everything off the UI thread, while QOpenGLWidget renders everything on the UI thread.
My first attempt to solve this problem was to try and hack together a way to have mpv render frames off the UI thread and then send them to MpvWidget when they were done. I have no knowledge of graphics programming or OpenGL, so I found trying to figure out multithreading OpenGL rendering next to impossible. I was able to get Memento to not outright crash after following this StackOverflow post, but was unable to get mpv to render any frames. Rather, it just kept spitting out mpv_render_context_render() not being called or stuck while returning 0 for every frame it was called.
Having given up on the widgets approach at that point, I changed the render to use QML/Quick instead, which was something I really didn't want to do. You can see the results of this on the qml branch. While this did show some improvement, it still did not work 100% of the time, which is something it needs to do if I want to be able to releases a macOS version.
Pausing mpv before entering fullscreen on macOS does seem to work, but since Qt events like window changes are asynchronous, it doesn't work 100% of the time, and works 0% of the time if the maximize button is used instead of keystrokes.
At this point, I'm at a loss for what to do. If there's anyone with good ideas or any motivation to fix this, please leave a comment. I'd like to figure it out as well.
I was able to solve the freezing problem by creating an Objective-C++ class that monitors the NSNotification for entering and exiting fullscreen and pausing mpv from there. It seems to have a 100% success rate. While it would be nice to have mutltithreaded rendering, it's no longer necessary.
There are no longer substantial bugs present in the macOS port.