Changed the way uitask is dispatched on GTK+ to make event handling not a CPU hog.

1 files changed, 1 insertions, 1 deletions

diff --git a/implementation.md b/implementation.md
index 83888ca..895fa19 100644
--- a/implementation.md
+++ b/implementation.md
@@ -45,7 +45,7 @@ GTK+ is strange: there are constructor functions that return `GtkWidget *`, but
 
 `uitask` is a channel that takes `func()` literals. These are closures generated by the `sysData` functions that contain the GTK+ calls and a channel send for return values (like with Windows above). If no return value is needed, the channel send just sends a `struct{}`. The UI goroutine merely calls these functions.
 
-As the GTK+ main loop system does not quite run in a sane way (it allows recursion, and the `gtk_main_loop_iteration_do` function only onperates on the innermost call), we cannot use the `for`/`select` template for `ui()`. Fortunately, we can hook into the GDK main loop (that the GTK+ main loop uses) to run our `uitask` dispatches whenever the GDK main loop is idle. The only catch is that the `uitask` receives have to be non-blocking for this to work properly, so we wrap them in a `select` with a null `default`.
+As the GTK+ main loop system does not quite run in a sane way (it allows recursion, and the `gtk_main_loop_iteration_do` function only onperates on the innermost call), we cannot use the `for`/`select` template for `ui()`. Fortunately, GDK provides gdk_threads_add_idle(), which allows us to run, and optionally (and importantly) run only once, a function on the `gtk_main()` thread when not processing events. We use this, combined with a goroutine for dispatching, to handle `uitask` requests. See `our_idle_callback` in callbacks_unix.go for details.
 
 GTK+ layout managers are not used since the UI library's layout managers are coded in a portable way. (`GtkFixed` is used instead.) This isn't ideal, but it works for now.