OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 29 Ноябрь, 2022 18:02

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Пятница, 18 Март, 2011 23:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9458
Откуда: Россия, Орёл
А эта пауза - она будет, если переключить форму в другой режим, в маску?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Пятница, 18 Март, 2011 23:28 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Да, всё ровно так же. Сеточки только нет.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Суббота, 19 Март, 2011 00:31 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
а вот саморисованые кнопки в том же количестве не моргают вовсе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Суббота, 19 Март, 2011 11:15 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
По результатам, выработались некоторые способы избавления от мерцания GUI.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Суббота, 19 Март, 2011 13:05 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Иван Кузьмицкий писал(а):
затяжные процессы в прикладной логике могут оказывать влияние на момент финального рендера виджетов.
Напрашивается выделение прикладной логики с затяжными процессами в отдельный экземпляр ББ -- и пусть общается с "фасадом" через какое-нибудь TCP/IP.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Пятница, 29 Апрель, 2011 21:59 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Небольшое замечание.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Понедельник, 04 Июль, 2022 00:28 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 216
Откуда: Питер
Скажите пожалуйста, мерцание виндовских контролов так и не побеждено?

У меня такая ситуация: есть вьюшка, которая содержит две подвьюшки (сплиттер), соответственно, в Restore вызываются два InstallFrame'а для каждой из подвьюшек. Всё работало хорошо, пока я не стал использовать в качестве подвьюшек скроллеры - со скроллерами при изменении размера мерцает та подвьюшка, InstallFrame которой вызывается вторым (а первая - не мерцает). Причём мерцают и полосы прокруткаи, и содержимое скроллера. Поигравшись с кодом StdCFrames и HostCFrames, я выяснил, что дело в отрисовки виндовских скроллбаров, но дальше продвинуться не могу...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Понедельник, 04 Июль, 2022 09:06 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3271
Антон Дмитриев мне рассказывал, что этот вопрос изучил подробно и сами Microsoft эту проблему не смогли победить, поэтому просто ушли от использования собственных контролов. Все контролы Windows без вариантов отключают буферизацию вывода графики. Поэтому вариант только использовать кросс-платформенный скроллбар, который уже есть в HostCFrames для версии 1.8 и 2.0. Если для вас критично использовать именно MDI версию ББ, то можете аккуратно перенести код из этого файла в секцию, где реализованы скроллы HostCFrames в вашей версии.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Понедельник, 04 Июль, 2022 15:46 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 216
Откуда: Питер
Я как раз и использую версию 1.8...

(и кстати в Delphi 7 ничего не мерцает...)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Понедельник, 04 Июль, 2022 17:12 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 216
Откуда: Питер
Ваш файл, в принципе, помогает. Спасибо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И снова о мерцании.
СообщениеДобавлено: Вторник, 25 Октябрь, 2022 01:10 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 545
В ББ, чтобы не мерцало, используется двойная буферизация (как и везде в современных системах). Однако приборы WinApi, "прикрученные" к ББ с помощью модулей StdCFrames и HostCFrames, намертво вырубают эту буферизацию. Это прямо в их Restore прописано: ВыключитьДвойнуюБуферизацию. Получается так: начинается отрисовка области в окне, при этом включается двойная буферизация; пока рисуются нормальные виды ББ - все идет по плану; как только рисуется любой прибор WinApi - двойная буферизация выключается, т.е. то, что уже попало в буфер, переводится на экран, и дальше всё остальное тоже рисуется прямо на экран - т.е. мерцает. Независимо от того, приборы на форме или в тексте.

В разных источниках я нашел сведения (точнее, вопль и стон), что эти древние, почти доисторические приборы WiApi сами по себе, т.е. без всякого ББ, не совместимы с двойной буферизацией. (Если кто-то опроверг бы - было бы здорово). Сильнее всего это мерцание проявляется на приборах-блокнотах (tabulators, кажется), которые даже в дельфи мерцали (по некоторым сведениям).

Путей решения - несколько:
1) найти в недрах WinApi другой набор флажков или вызовов, обеспечивающих такие же по функциональности приборы. Задача для мужественных. Авторы ББ пошли на недюжинные выверты, чтобы завернуть эти приборы в ББ-шную обертку и обеспечить ими интерфейс Controls.Control. Отжирание памяти, о котором в 11 году выше писали - связано с тем, что там то и дело приходится пересоздавать winapi handles и Frames. Ну и платформозависимо оно будет...
2) прекратить поддержку StdCFrames и HostCFrames как неактульного ныне подхода. В 90е было модно, чтобы приложение "сливалось" по внешнему виду с операционкой, и авторы ББ успешно справились: на Вин оно выглядело как Вин, на Маке - как на Маке (но это не точно). Ныне такой моды нет - у всех фреймворков свои приборы, да еще кастомизация сплошная. Поэтому подход StdCFrames дорогостоящ и неактуален.
При этом на замену нужно реализовать все стандартные приборы внутри ББ. Огромную работу Иван Андреевич Денисов уже проделал, написал платформонезависимый HostCFrames, который в 2.0 мы переименовали в StdStdCFrames. Несмотря на ущербность, интерфейса, который налагает StdCFrames.Frame на StdStdCFrames, большая часть функциональности уже есть.

Но я предлагаю выкинуть StdCFrames вообще и реализовать приборы как полноценные виды ББ, т.е. прямые расширения Controls.Control, а не StdCFrames.Frame. У себя я уже сделал и испытываю Edit Field (на базе TextViews), а сейчас работаю над ListBox и их стыковкой в ComboBox, и вообще списками общего вида.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2022, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB