AddTimeout или AddIdle для обновлений пользовательского интерфейса в основной теме GTK?

Question

При создании обновлений пользовательского интерфейса с помощью GTK # (GDK2), например, смены текста ярлыка, видимости кнопок и т. Д., Следует ли, как правило, использовать Gdk.Threads.AddTimeout или Gdk.Threads.AddIdle?

The GDK2 documentation утверждает, что AddIdle

Добавляет функцию, которая будет вызвана, когда нет более высокого приоритета событий в ожидании.

Похоже, что AddTimeout обеспечит более отзывчивое обновление. Однако в документации указано:

Обратите внимание, что функции тайм-аута могут задерживаться из-за обработки других источников событий. Таким образом, на них не следует полагаться для точного определения времени .

Который приводит меня к мысли, что Idle и Timeout являются столь же отзывчивыми, как и каждый другой (что они кажутся при запуске кода).

Комментарий в некотором коде, на котором я работаю, предполагает, что Timeout приводит к более быстрому обновлению, но ударяет по пользовательскому интерфейсу сложнее, но я не могу найти никаких источников для резервного копирования.

Как правило, какой из этих методов я должен использовать для выполнения обновлений GTK в основном потоке?

Threads.AddTimeout(0, 0,() => 
    { 
     // do something; 
     return false; 
    }); 

против

Threads.AddIdle(0,() => 
    { 
     // do something; 
     return false; 
    }); 

Answer 1

Тайм-аут обратного вызова подходит, если вам нужно что-то произойдет по истечении определенного периода времени. Примером этого может быть мигание курсора в текстовом поле (не то, что вы должны реализовать это самостоятельно).

Idle timeout получает название, как только основной цикл завершает выполнение всего остального, что готово. Разница, если вы просто вызываете ее один раз, является приоритетом. Если у вас есть какое-то другое событие, которое обрабатывается основным циклом, выполняющим его в обработчике простоя, это гарантирует, что другое происходит первым.

Разница становится более очевидной при возврате истины и повторении обратного вызова. Если вы делаете это в режиме обратного вызова, вы в конечном итоге используете столько же CPU, сколько ОС позволит вам, но ваш пользовательский интерфейс остается отзывчивым, если каждый обратный вызов выполняется быстро. Если вы сделаете это с тайм-аутом, вы получите гораздо более предсказуемое поведение.

Единственная причина, по которой я думаю, что это поражает пользовательский интерфейс, заключается в том, что он по умолчанию имеет более высокий приоритет и может потенциально задерживать события ничьей. Приоритет DEFAULT_IDLE < HIGH_IDLE (ничья) < ПО УМОЛЧАНИЮ.