Как реализуется динамическая графика в ББ, можно посмотреть на примере того же ObxCubes и StdClocks.
В модуле заводится Action, который при каждом своем исполнении шлет широковещательное своё сообщение через Views.Omnicast. Omnicast доставляет его вообще всем-всем вьюшкам, которые в данный момент видны на экране.
(Т.е. всего в документе открытом может быть хоть миллион вьюшек - реально сообщения пойдут десятку тех, которые видны).

Наша вьюшка реагирует на это сообщение своего модуля и объявляет себя на перерисовку (Views.Update(self, ..)).
Ну, плюс, она взводит флажок в record-е сообщения, чтобы рассылающий Action знал, есть на экране хоть одна на него реагирующая вьюшка (и тогда выполнялся без промедления) или нет (и тогда можно поспать секунды-пол или сколько там).

После вышеназваннных правок Action-ы работают - т.е. вьюшки сообщения получают.
Но они вызывают для себя отложенное обновление. А это обновление выполняется в главном цикле приложения.
А пока мы сидим в каком-нибудь цикле блокирующем (Input и т.п.), до этого обновления дело не доходит.

Можно ли обновляться не отложенно, а принудительно?
Да. Так делает, допустим, StdLog. Если вы печатаете из любого цикла, то он обновляется.
Если мы в него залезем, то увидим, что вызывается Views.RestoreDomain - это инициирует принудительную перерисовку всех вьюшек, видимых на экране, имеющих указанный Store.Domain (т.е. относящихся к одному документу).
Рядом во Views мы видим Views.RestoreRoot, которая требует корневого фрейма (корневой фрейм - фрейм окна) - и тоже инициирует принудительную перерисовку.

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

Другой вариант: всё же обновляемся не принудительно, а через Views.Update, просто Action после широковещания инициирует фазу общей отложенной перерисовки.
Windows.dir.Update. Я так понимаю, что тупо Windows.dir.Update не стали ставить в эти жадные циклы потому, что нужно было бы городить какую-то временную синхронизацию, чтобы вызывать не каждый раз, а пореже. Никаких принципиальных проблем типа "нельзя вызывать, находясь внутри обработчика сообщения" там не должно быть, т.к. Windows.dir.Update тупо вызывает Views.ValidateRoot для root-фрейма, ну а мы вызываем RestoreRoot, что отличается только оптимальностью (Validate перерисовывает измененённые прямоугольники, Restore - всё). В любом случае, это я не пробовал, попробую, когда допишу этот пост.

В итоге, целесообразно завести отдельный модуль (KrlDynRestore), в котором будет один такой Action, Omnicast-ящий сообщение регулярно, все вьюшки, хотящие быть динамическими, его ловят - и требуют своей перерисовки, вызывая процедуру из KrlDynRestore. А в ней уже можно экпериментировать с разными методами.
В вьюшках ББ используется ModelMsg. Оно передаётся каждой вьюшке по одному разу. Для Views.RestoreDomain это подошло бы, для RestoreRoot - уже нужно знать все кадры, в которых отображается вьюшка.
Поэтому используем ViewMsg. Он будет передан каждой видимой вьюшке один или несколько раз, с каждым кадром, в котором она видна. Что нам и требуется.

## Код:
```
PROCEDURE (v: View) HandleViewMsg (f: Views.Frame; VAR msg: Views.Message);
BEGIN
  WITH msg: KrlDynRestore.Msg DO
    msg.consume := TRUE;
    IF ... если нам пора перерисовываться, по нашей там частоте и проч. ... THEN
      KrlDynRestore.Update(v, f)
    END
  ELSE
  END
END HandleViewMsg;
```
