Причина мерцания - контрол слишком много перерисовывает каждый раз.
В ББ эта проблема решается не ручной буферизацией, а разбиением сложного отображения на несколько комбинируемых простых. Т.е. вводится отдельное отображение ArrowView, которое делается вложенным отображением для контрола. В Restore основного отображения выполняется Views.InstallFrame для ArrowView.
А при Update выполняется не перерисовка всего контрола, а всего лишь запрос на обновление ArrowView:
Views.Update(v.arrow, Views.keepFrames).
Обеспечить буферизацию - уже дело самой среды. Дело программиста - разбить на мелкие отображения и внятно говорить, когда какое перерисовывать.

Переделал Ваш код таким образом, контрол не мерцает. (ну, зазубренная стрелка "змеится" - это уже проблемы рисования линии).
Я склепал весьма на скорую руку, к тому же пришлось проломить Вашу иерархию - переопределить Update на уровне AGauge, пометив его в ViControls как EXTENSIBLE.
Вложение:AGauge.odc[91.77 КБ]
Скачиваний: 835
Вложение:Controls.odc[29.96 КБ]
Скачиваний: 828


И, если позволите, общие замечания. Мне кажется, что Вы пытаетесь поверх ББ строить VCLЗдесь другая идеология, и из этого ничего хорошего не получится. Например, тягостно выглядят глубокие иерархии наследования, особенно реализации. Попробуйте избежать наследования реализации, использовать только композицию, в сочетании с определением своих типов сообщений. Например, Вы ввели Paint, Update и "прошили" в базовом ViControls.Control некую жёсткую схему поведения - и тут же выяснилось, что для того, чтобы реализовать вложенные отображения, её нужно переломать... Всегда стоит подумать, а для чего и в каком месте наследование? По умолчанию приемлемо расширение сообщений, расширение абстрактных интерфейсов, расширение конкретного финального типа от абстрактного интерфейса. Любое иное расширение требует обоснования. Например, какие такие общие черты планируются у элементов Vi, чтобы вводить для них базовый тип ViControl? Наличие дополнительных методов в интерфейсе? Их вроде бы нет. А если бы и были, то для отображений лучше было бы описать дополнительные сообщения, а не доп. процедуры. Какие-то общие примитивы поведения? Так может быть, лучше эти примитивы поведения реализовать обособленными типами и задействовать через композицию?

И ещё мелкое, но важное... Вы объявляется TYPE SomeControl = ABSTRACT RECORD .. и объявляете read-only поля - это бессмысленно. Ведь схема "открытый абстрактный интерфейс" сделана для того, чтобы кто-то мог подменить реализацию. Так ведь реализация в другом модуле не сможет менять read-only поля своего базового типа! Абстрактный интерфейс должен содержать только абстрактные процедуры, а для стандартных свойств - абстрактные функции их получения (не обязательно, если есть Prop-сообщение для их получения, то можно и не описывать). Поля описываются как раз в конкретном типе-расширении.