Тормоза с перерисовкой контролов после апгрейда до 1.4

[PVOzerski]

ОК. выкладываю исходники + файл с параметрами модели (success2 без расширения). Параметры надо будет загрузить из проги через кнопку "Load All" (в верхней части формы). Тормоза будут видны уже в процессе загрузки параметров. Еще более сильные тормоза будут с, как его здесь назвали, "эквалайзером" по нажатии кнопки "Start".

Сейчас в исходниках, в файле m1d_u1.pas, у меня добавлена в самом верху директива компиляции {$define NOREFRESH} (и пара соответствующих {$IFNDEF} в коде ниже). В таком состоянии "тормозов" не будет. Если строчку {$define NOREFRESH} "отрубить", "тормоза" появятся во всей красе. Напоминаю: проблема актуальна для GTK2 на платформах linux (32- 64-разрядной), насчет актуальности для винды и прочих систем ничего сказать не могу.

[Vadim]

Скомпилил. Нажал кнопку "Load All". Загрузилось всё менее чем за секунду. Нажал кнопку "Start". Эквалайзер судорожно задёргался. Все движки уползли вниз, Остался только 14-ый слева, он продолжил судорожно дёргаться вверх-вниз, но с какой частотой - не скажу, глаз не может уследить.
Чем ишшо проверить это сооружение?

Добавлено спустя 12 минут 39 секунд:
Вот ссылка на видео:
https://yadi.sk/i/IaxZGGWegjedo

Добавлено спустя 24 минуты 23 секунды:
Только заметил, что Вы там NOREFRESH уже поставили.
Вот чисто по мне, так с тормозами куда как красивее, чем без них. Как-то выглядит всё благороднее, солиднее.

[PVOzerski]

Увы, это не тот случай, когда солидность и благородность ценится

[Vadim]

Исключительно в качестве гипотизы. Если вместо TSpeedButton использовать какой-либо более интеллектуальный компонент, который ведёт свою героическую родословнуюю от TWinControl, то можно будет использовать свойство DoubleBuffered.

Добавлено спустя 1 минуту 49 секунд:
Вопрос, а методом Refresh Вы чего именно добиваетесь?

[PVOzerski]

Дык два отрубленных Refresh применительно к данной проге и так проблему решают. Главная-то идея поста - проверить, нет ли бага в LCL (т.е. есть ли возникающим тормозам, которых не было в предыдущей версии Лазаря, какое-то рациональное оправдание).

[Vadim]

PVOzerski
И всё-таки, зачем Вы вручную вызываете Refresh?

[PVOzerski]

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

[Vadim]

Дело в том, что и без всякого Refresh контролы у Вас двигаются прекрасно. Refresh вызывает Repaint, а Repaint перерисовывает контрол. Однако и без этого контрол перерисовывается как только Вы ему присваиваете другие координаты. Получается двойная перерисовка компонента.
Смысл мучить несчастного Лазаря мартышкиным трудом, а потом ещё и упрёки ему предъявлять?

[pupsik]

А мне куда интереснее вопрос:
Что такое синхронизация. И как с ней работать???

п.с.
Мне, вот кажется, для взаимодействиями с визуальными котролами из потока её пользуют. Вот только чет я этого не заметил. Может плохо смотрел? Или она не нужна?

[PVOzerski]

Плохо смотрели
Вот здесь:
procedure TWorkThread.Execute;
begin
stopping := False;
Counter := 0;
repeat
NextGeneration;
Synchronize(@DoIndicator);
until stopping;
Synchronize(@Answer);
end;

А DoIndicator, в свою очередь, вызывает, в частности, Form1.ChangeMarkerPos - это перерисовка "эквалайзера".

[pupsik]

Плохо то плохо. Но неужели поток необходим лишь для того что бы "рисовать" форму? Хотя, возможно, и не важно это

[PVOzerski]

В данном случае - примерно так, для отрисовки и, еще в большей мере, для возможности остановить цикл вручную через стандартный интерфейс. Конечно, теоретически можно было бы воткнуть в главный цикл Application.ProcessMessages и обойтись одним потоком, но этот способ очень сильно подтормаживает цикл безо всяких Refresh . А писать свои обработчики событий клавы и мыши - увольте

Но вообще, по мне, это уже оффтоп пошел. Обсуждать, правильно или неправильно написана эта программа, конечно, не запретишь, но пост-то я делал ровно потому, что она продемонстрировала, что в LCL версии 1.4 метод Refresh стал существенно более медленным и хорошо бы разобраться, фича это или-таки баг LCL (а не моей проги, которая свою основную задачу выполняет, невзирая на то, насколько некрасиво или красиво она написана). Как-то так...

[zub]

PVOzerski
Багом LCL это станет тогда когда кнопка перестанет выполнять свои функции. Пока абсолютно точно это не баг.

>>метод Refresh стал существенно более медленным и хорошо бы разобраться
Не знаю, насколько критична скорость Refresh - по мне абсолютно не критична. возможно там возникают по вашей или по вине лцл паразитные "отрисовки" - но это следствие нецелевого использования

Чтоб разобраться необходимо найти момент (комит) после которого появились "тормоза"

[pupsik]

Хм лазарь 1.5, фпс 3.3.1, ну..у и жтк2 = 0 лагов. Т.е. ваш пример не лагает по отрисове. Скачет себе.
А вот по поводу потока и контролов уж больно все как то не так (т.е. реализовано, но это сугубо мое мнение). Сори что отвлек

[PVOzerski]

Поставил опыт. С Refresh и без Refresh у меня "побегали" TLabel и TStaticText. Без Refresh у меня процесс перемещения контролов вообще не виден. C Refresh "на глазок" контрол типа TLabel при равных условиях в несколько раз уступает в "скорости пробега" контролу типа TStaticText. Намекаю: TLabel, как и TSpeedButton, - наследник TGraphicControl, а TStaticText - наследник TWinControl. Можно предположить, что тормозит метод TGraphicControl.Refresh.