-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zyn fusion exe files do not run GUI correctly #28
Comments
Video of this happening: https://youtu.be/oKf6xk7EpHI |
That sounds like an issue with pugl's handling of redrawing/expose events under your build configuration. Unfortunately I don't have a windows system to directly test this problem. |
@fluzz142857 In mruby-zest-build/test-libversion.c remove puglEnterContext & puglLeaveContext in function main. This should fix it. Let me know if it doesn't @fundamental This commit: mruby-zest/mruby-zest-build@ef8df03 caused the regression. Not sure what to do. Simply removing it makes it work on my end but could also break something that commit was trying to fix. |
Interesting. I wouldn't have suspected that chunk of code, but I could see how there could be an interaction there. I'm guessing the safest way of addressing the fix would be to disable those calls only on windows via a quick #ifdef. I'm pretty sure everything should also work fine (outside of the automated screenshot mode) on linux with those disabled, but well a) I do like that mode and b) I can't recall offhand if there were other interactions to be concerned with on linux/macos. |
How do you enter automated screenshot mode? Maybe it works in windows even without the extra puglLeave/Enter calls. If that's the case, using the ifdef won't even cause an issue and this becomes a no brainer. (Yes, I'm an optimist :) ) Background about this bug: When you call puglEnterContext it issues a BeginPaint call. The ms documentation says to never to call that function unless you're in an WM_PAINT event. WM_PAINT events gets translated by pugl to a PUGL_EXPOSE event. What I think happened is that you called puglEnterContext which called BeginPaint and then marked the window as "updated". This caused windows to not send a WM_PAINT event and therefor the PUGL_EXPOSE was never send to your code. Please bear in mind the above is just a guess, I was happy to get it working and played with zynaddsubfx instead of debugging the bowels of windows. |
Personally I'm fine if automated screenshot only works on Linux. If I had the extra development sprint after the main zyn-fusion one I would have pushed to have it run on CI, but some of that required figuring out some headless OpenGL library tricks. Doable, but I've heard tales of that arcane knowledge driving some people mad. Anyhow, take a look at the base directory of the mruby-zest-build repo. You should see user-manual-screenshots.rb . That file defines a sequence of events to run on the user interface along with delays between them. Personally I'm not entirely happy with the setup and had hoped for a better DSL, but you can feed that file into the GUI with the --script option. (e.g. zyn-fusion --script user-manual-screenshots.rb) at which point it will execute the script and return control to the user afterwards. Though in the case of the specifically mentioned screenshot script, the last command is The headache with the scripted mode of operation is that the GL context needed to be valid when the scripted commands ran in order to force updates and to have a valid context for capturing the pixel buffer for saving things to file. So there might be some extra commands in there to ensure that the context is valid for any time the script could run which are unnecessary for more typical operation. Even with the sharp jagged edges, I still love the scripted mode with builtin screen capture. For documentation purposes it seems like a feature which is sorely missing from typical frameworks. Who wants to go through an application regenerating screenshots every time some minor look-and-feel issues are resolved. |
I'm able to make screenshots in windows without the extra The only trouble I had running the script was when it tried to exit:
But to be honest, who really cares as long as the screenshots gets made. EDIT: Seeing that script run was awesome. :) I completely get why you want to keep that feature and its abilities to take screenshots. |
DLL files work correctly, but exe files on both demo and release versions do not open the interface correctly. Running an exe file opens a terminal and GUI window. The GUI window starts at a black screen. Dragging the GUI window off the screen refreshes the part of the GUI window that was hidden, displaying it correctly until dragged off again. Keyboard and mouse inputs work correctly. Sound works normally.
Terminal window debug information seems to be normal.
Sample release version terminal info:
Sample demo mode terminal info:
The text was updated successfully, but these errors were encountered: