Gtk causes lags in REPL on Windows

[sebastianpech]

The moment I do using Gtk in the REPL on Windows (Tested on 10 and 7 with julia 0.6) the REPL input lags (see screencapture). This doesn't happen (at least for me) on OSX and Linux.

[tknopp]

Task scheduler issue? ping @vtjnash

[vtjnash]

Win32 kernel bug

[tknopp]

is this specific to Gtk.jl or is the task machinery in general broken on Windows? Is there a dedicated issue in the julia issue list?

[hustf]

Very few people use win32 nowadays. Win64 is fast now. But we might try and see if processor optimizations has benefits on win64. I will try to compile the libraries when I get to it. There is also some workaround for julia itself, but last times I tried the gtk binaries still had issues.

[davidanthoff]

This is actually still very much an issue on Windows. I've been entirely confused why the REPL experience on Windows seems to degenerate completely in certain situations, and it does just seem to be enough to load Gtk.jl.

It would be great if this could be a high priority issue to fix. There are a fair number of packages that load Gtk.jl, so a lot of folks will probably end up with Gtk.jl loaded (as I did), and then the REPL is really, really crappy.

[SimonDanisch]

I can confirm! I had to remove Gtk from my project since it was unbearable...

[tknopp]

@vtjnash could you elaborate what you mean by "Win32 Kernel Bug" above? Gtk.jl once worked fine on windows and now it seems that people have issues.

[hustf]

GTK may have worked fine on windows at one time, but I have been trying it out now and then since mid 2015 and always gave up. Tests pass most of the time, but there is always some problem or other.

I give up easily. GTK didn't make all binaries available for Windows in the past, and GTK.jl didn't test for windows. I'm reluctant to use anything that can't ultimately be used in my line of work, i.e. the Windows world. And I'll never be able to compile anything at work.

JuliaGraphics has an Appveyor account, which is used here: That means that Simon or some other full member can add this project, if it's not already there.

I suggest some tests that try hard to find errors, including detecting tasks that don't actually exit fully and get garbage collected. And also put those tests in test/optional. Immerse.jl depends on GTK and tested with Appveyor, so this seems possible.

[hustf]

Are tasks broken in general on Windows? Here's from Windows 64 bit. Doesn't seem broken here.

  | | |_| | | | (_| |  |  Version 0.6.3 (2018-05-28 20:20 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/                   |  x86_64-w64-mingw32

julia> begin
       using BenchmarkTools
       coroutine(ch) = put!(ch, "Not broken on windows 64!")
       function callit()
           c = Channel(1)
           whatisitnow = @async coroutine(c)
           bind(c, whatisitnow)
           take!(c)
       end
       end
callit (generic function with 1 method)

julia> @btime callit()
  1.969 μs (23 allocations: 1.92 KiB)
"Not broken on windows 64!"

[lobingera]

I'm not the expert about multi-processing/multi-threading on Windows, so i might be completely off.

As far as we know, julia is using libuv for asynchonous I/O in general, so things like REPL is transported by libuv and abstracted by this from the operating system. libuv is/seems to be the basis for Task handling/multi-processing&threading.

Now. Gtk.jl registers the main event loop into a scheduled task on by a julia call to enable parallel work of REPL and event processing at Gtk. Note: most adaptations of GUI toolkits don't do this, they call the main loop and have a means to go back to the control flow - usually when main window is closed. So this way of Gtk.jl to do the main loop in parallel seems to work nicely on UNIX-like OS, but i guess the situation is not that nice on Windows that is based on complete different ideas about multitasking.

I have not managed to read the libgtk documentation about event processing and multithreading, but as there are more 'hooks' for event processing, i guess there is more to integration of the event loop then just global gtk_main_task = schedule(Task(gtk_main)).

P.S. debugging things like this is very, very complicated.

[hustf]

Lobingera, when you write parallel above, do you mean exactly that? Is gtk in a fully parallel loop? Could that be an alternative if not?

[vtjnash]

You could try reducing the delay at from 100 to 10: https://github.com/JuliaGraphics/Gtk.jl/blob/4e110ac111da3631c858886d097ef13aa0064c3d/src/GLib/signals.jl#L291

[lobingera]

@hustf Parallel is an abstract concept anyway... I mean: there is event processing at Gtk and event processing in REPL at the same time.

[paulmthompson]

I'm not sure if I'm on the correct track here, but I think when GTK.jl was first made, there were some fundamental differences with how libuv handled access to the backend file descriptors on Unix and Windows. Actually I think for windows it just didn't handle them at all. See here:

https://github.com/libuv/libuv/commit/2e9d86e105f4cc7c6d8d969ab2d58d9d353679aa#diff-0886ba7381a955af32f753d649ba2e29

libuv on Windows now returns an IOCP handle:

https://github.com/libuv/libuv/blob/12f18159cf2f40fe12c62eb7a0ae22b6dd5548d5/docs/src/design.rst

https://github.com/JuliaLang/libuv/blob/be317349252699670131395f125c3861d793ca86/src/win/core.c#L214

The current implementation of GTK.jl doesn't attempt to use any of the libuv framework to poll events from the main loop on Windows (I think), and just assigns an infinite timeout that is dealt with later as above with the hard-coded timeout.

https://github.com/JuliaGraphics/Gtk.jl/blob/6298bd465922289ab3f3586143b47e58eedd44c7/src/GLib/signals.jl#L352

Perhaps now we can poll the main event loop on windows as is done on Unix?

Alternatively, I think Gtk has a few methods that are older to get around this issue. As a comment in glib states:

• On POSIX systems, the file descriptors in fds can be any sort of
• file descriptor, but the situation is much more complicated on
• Windows. If you need to use g_poll() in code that has to run on
• Windows, the easiest solution is to construct all of your
• #GPollFDs with g_io_channel_win32_make_pollfd().

https://github.com/GNOME/glib/blob/master/glib/gpoll.c

There is pretty limited documentation of this function, but maybe it would accomplish the same goals?

Also important: I have absolutely no idea what I'm doing.

[rapus95]

Sorry for asking, but since there have only been mentions of this issue for half a year, is this still being solved? For me because image processing is pretty annoying w/o ImageView.

[timholy]

In large measure because of this issue I've been meaning to experiment with a browser-port of ImageView, but haven't had time to look into it. A PR (even if very incomplete) based on Observables.jl would be cherished!

[urs-of-the-backwoods]

Can confirm on windows 11, REPL slows down as soon as you "using Gtk". Interestingly it also slows down typing in this editbox on github, very strange. I used Visual Studio Code with language server for Julia. Reproducible also with powershell Julia being started and typing "using Gtk". It is about 2 chars per second during typing, so really slow.

I wonder a little bit, why this is open since a number of years now. Is it too difficult to fix, is it simply a native GTK/Windows mismatch? I mean I was impressed how the package manager get everything on my system in minutes, this is awesome! Since Windows is the dominating computing platform for desktop by numbers keeping this open for 4.5 years is not encouraging for desktop UI devs, is it?

Or is desktop UI app development dead in general?

[tfiers]

Suggested by @jwahlstrand in #629: having ENV["GTK_AUTO_IDLE"] = false before import fixes it for them and for me.

[bilderbuchi]

Suggested by @jwahlstrand in #629: having ENV["GTK_AUTO_IDLE"] = false before import fixes it for them and for me.

Is that something that Gtk can do internally upon loading, so that upstreams like ProfileView are relieved of this issue without user action? I guess not everyone can quickly transition their package to Gtk4.