Will Winston plotting package be further maintained 
?
Not have the windows slowdown issue?
But since Iām not doing any of the work, this is very speculative suggestion. Iām only half serious.
No, none of this has happened, or is likely to happen very soon, or at all.
I would prefer fixing the bug instead of going back from where we came. The switch from Tk to Gtk was actually a move not only of a single package but of multiple, think of ImageView, which was completely rewritten by @tim.holy to exploit the advantages that Gtk gives us. I know this does not solve the slowdown problem but I want to make clear that quite some thoughts went into the decision of switching to Gtk.
I tried to run Gtkās main loop in a thread instead of a task the other day, but that led to a swift segfault.
For me the question is more why we need all stuff here: Gtk.jl/signals.jl at master Ā· JuliaGraphics/Gtk.jl Ā· GitHub
Why canāt we just use the regular main loop of Gtk. It has some downsides because one would loose the REPL but this it is regularly done (see 2. Getting Started ā Python GTK+ 3 Tutorial 3.4 documentation)
Several people in my group have this problem on Microsoft Windows [Version 10.0.19044.1466].
Whenever julia is executing code keyboard response is incredibly slow in all other applications. The computer is unusable until Julia finishes.
Has this been fixed? Is there a workaround?
2 Likes
I am seeing this on 1.7.1, in VSCode (Win11), but only after exit() in the REPL and restarting. Typing lag is very bad, but the UI is still responsive ā I can move the cursor with the mouse, and the buffered keypresses continue very slowly to appear in the new cursor location. Itās weird, but it only lasts a few seconds so I have just gotten used to waiting for it to finish. Resource Monitor doesnāt show anything suspicious while itās happening.
1 Like
Hallo, what plotting software are you using or GUI you are using ?
I also frequently encounter very slow keyboard response when Julia is running on Windows 10 and 11, and not just when running GUI applications.
It happens when compiling packages, running multithreaded code, anything that keeps the Julia system busy. For some reason this interferes with keyboard processing on Windows. Itās been this way for years, which is why I much prefer running Julia on Linux.
Surprisingly, this does not happen when running Julia in Windows Subsystem for Linux rather than directly in Windows. Keyboard response is snappy even though it is doing at least as much processing as running directly under Windows.
This is a slightly awkward way to work but at least the computer is usable when Julia is running.
2 Likes
Interesting. Iām not on Windows, so canāt compare, but it seems like youāre just using to many threads or process. Does Linux for sure use as many (or WSL)? FYI: For compiling packages, i.e. precompiling many, there is an ENV variable to limit how many. I forget the name, but it seems like the default should be lower (at least on Windows). How many cores do you have, and is this the experience of most Windows users?!
1 Like
Same problem on Windows/VScode/Julia (latest stable versions at the time of writing). Finally, in my case I could trace it back to the package āProfileViewā. As soon as I type āusing ProfileViewā I get a huge keyboard lag which renders VScode completly useless. The lag is present even outside VScode (everywhere, seems to be on system level). When I close the REPL, the lag disappears. TaskManager isnāt showing any busy processes. Maybe it has something to do with the whole graphic stack, I get some warnings about āXorg_*_jll not stored on discā - no idea if this is responsible for the lagā¦
I do see that too. For a long time.
1 Like
March 2024 Report:
On Windows 10 with Julia 1.10.0 and also experiencing extremely sluggish Windows keyboard after typing using MyPackage (which happens to use Gtk).
However, when I run a function in MyPackage that uses terminal input, all keyboard typing starts working at normal speed (inside Julia program and in all other Windows applications).