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
Queue refresh after drawing (required for wayland) #72
Conversation
This is the issue with OpenGL on Wayland: |
What happens without this patch, does the window just stay black? Does it stay on the first frame drawn? |
The wxGTK patch or my commit? Without calling refresh(), it just draws the
first frame and does not redraw unless the window is resized.
This wxgtk bug seems unrelated as I'm not getting a segfault, but it would
explain why trying to use OpenGL was crashing for me (opposed to simple or
cairo).
…On Sun, Feb 12, 2017 at 9:37 AM, Rafael Kitover ***@***.***> wrote:
@Mystro256 <https://github.com/Mystro256>
What happens without this patch, does the window just stay black? Does it
stay on the first frame drawn?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#72 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AATWuG9tdA4qAlln3vuDwH8RykDJvwXQks5rbxkqgaJpZM4L-Yo_>
.
|
I think the plan is going to replace wxglcanvas with something like egl. |
I have an idea I used in my useless mac Quartz2D renderer, I will make a branch and link it here. |
At the end of CairoDrawingPanel::DrawArea, draw a 4 pixel rectangle with a transparent brush and pen on the wx dc to hopefully make the frame appear. I used this trick with the Mac Quartz2D renderer.
@Mystro256 can you please try the cairo_wayland branch and see if it fixes the display issue for Cairo on Wayland? |
@Mystro256 BTW we are on |
@Mystro256 also wanted to ask, does the Simple renderer work on Wayland? How does the performance of the Simple and Cairo renderers compare? I'd look at some of this stuff myself, but I don't have a non-VM linux right now, and my VM software only supports xorg. |
Simple and Cairo seems to be the same, I'll give the branch a shot and let you know. As for IRC, I don't use it unfortunately. |
Looks like the fix does nothing. I take back what I said about cairo drawing being required for build time, but simple and cairo still gives similar performances, likely due to most wayland implementations using cairo to draw regardless. Opengl still crashes vba-m in wayland, which is due to the bug you described above. I've been meaning to bug a WX dev about it, but I'm betting it's not due to a WX bug, as I noticed wx tutorials using refresh() to force re-queuing redraws. I'm assuming this doesn't affect Xorg, as I'm told XOrg takes a more "active" approach to redrawing windows, opposed to wayland which is made to be more efficient. I have no idea how Windows or Quartz works. |
@Mystro256 that still leaves the question of why the Simple renderer works and Cairo does not. I'm going to turn Wayland back on in my Fedora VM and try it out. |
Sorry I may have been confusing on how I phrased it; both simple and Cairo have this issue. I thought it was just Cairo but it seems like it's both. While OpenGL does not work due to the wx bug described above. |
I tried to make a Fedora VM with Wayland, but Wayland seems to require kernel modesetting which is only supported by specific video drivers, so no luck. I'll try on my pc laptop. |
@Mystro256 I got wayland running on my arch VM with weston + fbdev-backend.so + uvesafb, so I should be able to test this now. |
At the end of CairoDrawingPanel::DrawArea, draw a 4 pixel rectangle with a transparent brush and pen on the wx dc to hopefully make the frame appear. I used this trick with the Mac Quartz2D renderer.
@Mystro256 I cannot reproduce the rendering bug in Weston, both the simple and cairo renderers work fine. Any chance you could try rawhide and see if it happens there too? If not, perhaps we should just revisit this when f26 comes out. |
@Mystro256 on second thought, it was explained to me in |
Understood; do you think this is a bug in mutter itself since it works in Weston? I've already found a few bugs already that I've reported to gnome in regards to Wayland. |
It's either mutter or some sort of interaction between GTK and mutter, I don't know enough about this to say, also I need to install something to take a look myself. |
@Mystro256 I managed to install rawhide in vmware fusion (which has a real drm driver) and run the gnome wayland, and reproduce the issue you are talking about. |
@Mystro256 I think I have a fix, please try the cairo_wayland branch again. You had the right idea about using Refresh(), just had to find the right place to put it. Basically what I did was, instead of having: core -> systemDrawScreen() -> panel::DrawArea(frame_buffer) -> panel::DrawArea(device_context) I changed it to: core -> systemDrawScreen() -> panel::DrawArea(frame_buffer) -> panel::Refresh() -> panel::PaintEv() -> panel::DrawArea(device_context) and this puts things into the right state so that the frame actually appears in the window. There is some other stuff I need to do for Wayland, I need to add some code to check for Wayland at runtime and disable opengl, otherwise you have the situation where the user has opengl in their config and the app segfaults on startup. And unify the OSD code (there are two sets of code right now to draw the OSD and sometimes you even see them both draw text on the frame....) |
Indeed, this seems to have a much cleaner implementation rather than my hacky workaround. Seems to work with Xorg and Wayland just fine. Providing it works with Msys and Mac, commit away. Thanks for your help, I made a tracker bug for the opengl issue: #76 |
Use a gdk call (part of gtk) to detect if the app is using Wayland, and if so disable OpenGL, because wxGLCanvas segfaults under Wayland. This requires linking to gtk libs, so add some cmake and installdeps code for that. If the user has opengl as the render method in their config, it will not be changed, but at runtime will be set to simple under Wayland. Call Refresh() to queue a PaintEv from DrawArea(data) instead of calling DrawArea(device_context) directly. This fixes frames not displaying under Wayland. Remove the DrawOSD() call from PaintEv, this was causing the OSD to sometimes show up twice in one frame, because DrawArea(data) draws the OSD directly on the buffer. Add new files wayland.cpp and wayland.h with a bool IsItWayland() global function. This is where the aforementioned gdk call is.
Use a gdk call (part of gtk) to detect if the app is using Wayland, and if so disable OpenGL, because wxGLCanvas segfaults under Wayland. This requires linking to gtk libs, so add some cmake and installdeps code for that. If the user has opengl as the render method in their config, it will not be changed, but at runtime will be set to simple under Wayland. Call Refresh() to queue a PaintEv from DrawArea(data) instead of calling DrawArea(device_context) directly. This fixes frames not displaying under Wayland. Remove the DrawOSD() call from PaintEv, this was causing the OSD to sometimes show up twice in one frame, because DrawArea(data) draws the OSD directly on the buffer. Add new files wayland.cpp and wayland.h with a bool IsItWayland() global function. This is where the aforementioned gdk call is.
@Mystro256 please review and try a98f4a1 from the cairo_wayland branch. It also addresses #76. If all looks good to you will merge to master. How close are we to a usable fedora package? What are the major blockers aside from this? |
@Mystro256 another thing I wanted to mention, when I was trying Weston on my arch VM, I didn't know that the arch wxWidgets is compiled with GTK2 not GTK3, so the app was actually running under XWayland and not Wayland and that's why I didn't see the bug. |
Ah yes, that would make a lot of sense. You would have to use "wxgtk-gtk3" from the AUR to test Wayland on Arch. Looks good, feel free to pull the change in. I think the only other issue is #51. |
Disable OpenGL support under Wayland because wxGLCanvas segfaults, and fix an issue with drawn frames not appearing. If the user has opengl as the render method in their config, it will not be changed, but at runtime will be set to simple under Wayland. To fix the issue with frames not being drawn, Call Refresh() to queue a PaintEv from DrawArea(data) instead of calling DrawArea(device_context) directly. Also remove the DrawOSD() call from PaintEv, this was causing the OSD to sometimes show up twice in one frame, because DrawArea(data) draws the OSD directly on the frame data. Add new files wayland.cpp and wayland.h with a bool IsItWayland() global function. This uses a GDK (part of GTK) call to detect Wayland. This unfortunately requires linking GTK libs separately. Add cmake code to detect the version of GTK used by the wx being linked and link it as well. Add gtk2 and gtk3 dev packages to the code for the supported linux dists in ./installdeps.
Merged to master, closing this. |
Allow enabling GBA RTC regardless of rom types
Recreation of Pull Request #68:
Original description:
Quote from last relevant comment:
@rkitover said: