OberonCore

Помогите плиз сделать отрисовку без мерцания стандартными средствами Blackbox

Пусть, есть некий контрол. Например, манометр со стрелочкой.
У клнтрола есть PROCEDURE (c: Control) Paint-(f: Views.Frame)
Попробовал вот так:
PROCEDURE Paint(c: Control; f: Views.Frame);
VAR w, h, u: INTEGER;
p: Ports.Port;
BEGIN
u := f.unit;
c.context.GetSize(w, h);
p := f.rider.Base();
p.OpenBuffer(f.gx DIV u, f.gy DIV u, (f.gx + w) DIV u, (f.gy + h) DIV u);
c.Paint(f);
p.CloseBuffer();
END Paint;
Все отрисовывается без мерцания по Action (примерно раз в секунду).
Но документ, содержащий Control отрисовывается некорректно.
проблемы получаются и при прокрутке и просто когда документ свернуть и развернуть.
Остальная часть документа рисуется частично.

Как стандартным способом перенаправить отрисовку controla на Bitmap?
А потом корректно отобразить

А зачем "самопальные" Paint? Я не до конца понимаю логику... Подозреваю, что по Action Вы вызываете свой Paint(c, f)? Этого делать нельзя. Хотя бы потому, что Вы не можете делать никаких предположений о кадре за пределами Restore и HandleCtrlMsg, куда он передаётся; он может меняться в любой момент.

Обычно делается так: рисование описывается в yourControl.Restore, а из Action периодически вызывается Views.Update(yourControl, Views.keepFrames). Вы пробовали эту схему? Если да, то чем она не подошла?

А для чего p.OpenBuffer?

В документации Ports:
"Используется внутри системы, для восстановления окна без мерцания фона. Не используется в других целях."
А Вы используете внутри отображения - и "дерётесь" с корневым отображением...

Пардон, что не до конца объяснил. Paint как раз в Restore и вызывается:

PROCEDURE (c: Control) Restore* (f: Views.Frame; l, t, r, b: INTEGER);
BEGIN
Paint(c, f)
END Restore;

В Action вызывается value := value + 1; Dialog.UpdateReal(value), где value связана с контролом.
Почему p.OpenBuffer, потому что тогда вся последующая отрисовка(как я понял идет в Bitmap)
p.CloseBuffer затем выводит на экран Bitmap. p.OpenBuffer и p.CloseBuffer - это я потом добавил.
Было просто c.Paint(). Отрисовка контрола мерцает.

Да, я собственно это уже понял.
Но как тогда стандартными средствами Blackbox перенаправить вывод контрола в Bitmap,
а затем вывести его?

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

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

Вот пожалуйста

Скачал, а какой контрол проблемный и как его потестить?

Посмотрите GaugeDemo и AGauge

CtlsxSliders - можно убрать или скачать с http://www.zinnamturm.eu

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

Переделал Ваш код таким образом, контрол не мерцает. (ну, зазубренная стрелка "змеится" - это уже проблемы рисования линии).
Я склепал весьма на скорую руку, к тому же пришлось проломить Вашу иерархию - переопределить Update на уровне AGauge, пометив его в ViControls как EXTENSIBLE.


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

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

Илья, спасибо за помощь.
Я не пытаюсь построить VCL.
Просто есть идея собрать всякие Open Source
"красивые" контрольчики под Blackbox.
Собственно вся иерархия была введена из-за класса Border
чтобы можно было декорировать любой контрол.
Ну, и конечно, недостаточно документации + недопонимание идеологии Blackbox + инерция "старого" мышления.
Теперь мне много чего прояснилось, реализуем все по-другому

Успехов, спрашивайте, если какие вопросы/проблемы будут

Ну, это слишком категорично.

Ну да, но для конкретного кода, который обсуждали - так и есть

Зато дисциплинирует...