add option for "simple" main loop iteration #628
Conversation
main loop in a non-blocking way
Codecov Report
@@ Coverage Diff @@
## master #628 +/- ##
==========================================
- Coverage 65.69% 62.57% -3.13%
==========================================
Files 32 32
Lines 2720 2739 +19
==========================================
- Hits 1787 1714 -73
- Misses 933 1025 +92
Continue to review full report at Codecov.
|
|
So instead of running the gtk main loop on its own long-running task this just runs one iteration of the main loop in a dedicated task. I did not know that GLib offers that functionality and it seems to make more sense for Gtk.jl since it offers more fine-grained control. |
|
Yes, this would also let us suspend the loop momentarily without quitting it. But critically this doesn't seem to disturb multithreading at all. My concern is that this skips >100 lines of code in signals.jl. Is that really not needed? It would be good for others to test this. |
|
Two of the three failures in the previous CI run were caused by a canvas widget not being realized in time on macos for a call to getgc(). Modiying a test to force an iteration of the loop solves that. The third was a segfault and that makes me nervous... I will continue to putter around with this idea. |
|
I am not 100% sure but probably the while loop should move into |
|
Yeah, maybe one could iterate the loop if the widget isn't realized in Skipping the call to When I have time I'll refine this PR. We'll see if that random segfault reappears. |
|
Did you still see segfaults? |
|
And yes after JuliaLang/julia#13099 was merged I was able to remove all the |
|
No, that's 4 or 5 in a row with no segfaults. But I just noticed that I broke autoidle. Once that is fixed I think this is ready to go -- I don't have time to work on it now. Do you think this should be an option for now or the new default main loop behavior? |
|
If it works better, I would make it the default. |
|
Whether to remove the old code, I am not entire sure. Probably it would be better to make the cleanup in the Gtk4.jl project? |
|
I tried this out on Windows this evening and, despite all tests passing, it's a disaster. Resizing windows and interacting with the GUI is very sluggish. It works fine on Linux... |
|
The windows issue is of course very unfortunate. Is this completely solved by disabling the client side decorations? Probably the best would be to keep both possibilities (as you do now) and still cleanup the old path ( |
|
Disabling client side decorations on Windows largely solves the responsivity issues. The only visible effect I've noticed is windows look more like Windows windows than GTK windows. From what I've read, there might be problems if someone tries to use GtkHeaderBar, but that widget isn't supported currently anyway. Redrawing in response to GUI adjustments is still a little slower than before, which might be related to this: https://gitlab.gnome.org/GNOME/gtk/-/issues/801 . I think it's acceptable. I did some basic "human testing" on a Mac just now and it seems to work well. I'd say redraw performance is a bit worse than before, so there might be a general performance hit from iterating the main loop in a non-blocking way. But then on Linux I don't notice any difference. OK, do you think we should clean up the |
|
Any performance degradation worries me. The experience on OSX is not so great. But as long as we have the switch, its fine I think. IMHO we should look forward to the upcoming Gtk4 experience and put most energy there.
I don't care if you still remove it here or at the Gtk4 repository. My comment was more targeting the later: I.e. that the Gtk4 code base can clean this up. So probably the best is to leave it here as is, so that we can merge the PR and then you can carry over a cleaned up version to Gtk4. |
|
With this last commit, the performance issues on Mac and Windows are fixed. Disabling client side decorations was still necessary on Windows because without that there is a constant spew of |
|
what should we do with this? Keep the infrastructure for the future to remain flexible? |
|
Nah, this is sort of a mess. |
I hesitated to post this because it seems too good to be true. This PR creates a "simple" main loop option (disabled by default) that replaces the call to
gtk_main()with a Timer that iterates the GLib main loop every 5 ms in a non-blocking way. It also skips the call to__init__gmainloop__(), completely omitting the creation of a GSource for libuv. This is enabled using GTK_SIMPLE_LOOP = true.When I run Julia 1.7 with
GTK_SIMPLE_LOOP=true GTK_AUTO_IDLE=false JULIA_NUM_THREADS=4, I don't see a slowdown in the multithread tests posted at the beginning of #503. All Gtk.jl tests pass for me locally on Linux and Windows. ProfileView, ImageView and Winston seem to work just fine.Am I missing something? It's very possible I just haven't managed to create the situations that led to the tight integration of the libuv loop with the GLib loop. On the other hand, that code is ~8 years old and maybe isn't needed in recent versions of Julia?