OberonCore

А эта пауза - она будет, если переключить форму в другой режим, в маску?

Да, всё ровно так же. Сеточки только нет.

P.S. Кстати, простейший эксперимент.

Берём форму, растягиваем её поширше и размещаем на ней матрицу 7x15 стандартных кнопок "Cancel". Если теперь выделить форму как монолит и растягивать её, то контролы начнут мерцать.

На видео видно, как этот массив контролов рисуется постепенно, в три или четыре приёма.

Опять же, непонятно, как это согласуется с буферизацией.

а вот саморисованые кнопки в том же количестве не моргают вовсе.

По результатам, выработались некоторые способы избавления от мерцания GUI.

1) Отказ от виндовых контролов везде, где только можно.
2) Оптимизация работы с БД, т.к. уменьшение количества синхронных запросов облегчает отрисовку.
3) Вынос тяжёлых операций в отложенные действия (эффект сомнительный, так как однопоточность остаётся самым сильным фактором, влияющим на перерисовку).

P.S. Пытаясь сформулировать проблему, мы с Петром пока что пришли к такому выводу: механизмы отображения в ББ хороши сами по себе, но GUI в целом имеет некоторые проблемы в виде однопоточной увязки и зависимостей от WinAPI. В результате, затяжные процессы в прикладной логике могут оказывать влияние на момент финального рендера виджетов.

Напрашивается выделение прикладной логики с затяжными процессами в отдельный экземпляр ББ -- и пусть общается с "фасадом" через какое-нибудь TCP/IP.

Сам бог велел, no?

(В длинных вычислялках эта проблема тоже есть, поэтому любопытно.)

Небольшое замечание.

Заключение операций изменения внедрённых отображений в модификационные скобки BeginModification, EndModification значительно повлияло на общую картину в целом. Эти операции с самого начала не должны были быть неотменяемыми, но как-то это всё откладывалось "на потом".
Так вот, флики стали совсем малозаметны (хотя там, где много виндовых контролов, всё равно остались).

А наткнулись на этот факт совершенно случайно, копая бесконтрольное отжирание памяти при каждой перерисовке внедрённых отображений.