OberonCore https://forum.oberoncore.ru/ |
|
И снова о мерцании. https://forum.oberoncore.ru/viewtopic.php?f=24&t=3333 |
Страница 2 из 2 |
Автор: | Илья Ермаков [ Пятница, 18 Март, 2011 23:20 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
А эта пауза - она будет, если переключить форму в другой режим, в маску? |
Автор: | Иван Кузьмицкий [ Пятница, 18 Март, 2011 23:28 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Да, всё ровно так же. Сеточки только нет. P.S. Кстати, простейший эксперимент. Берём форму, растягиваем её поширше и размещаем на ней матрицу 7x15 стандартных кнопок "Cancel". Если теперь выделить форму как монолит и растягивать её, то контролы начнут мерцать. На видео видно, как этот массив контролов рисуется постепенно, в три или четыре приёма. Опять же, непонятно, как это согласуется с буферизацией. |
Автор: | Пётр Кушнир [ Суббота, 19 Март, 2011 00:31 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
а вот саморисованые кнопки в том же количестве не моргают вовсе. |
Автор: | Иван Кузьмицкий [ Суббота, 19 Март, 2011 11:15 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
По результатам, выработались некоторые способы избавления от мерцания GUI. 1) Отказ от виндовых контролов везде, где только можно. 2) Оптимизация работы с БД, т.к. уменьшение количества синхронных запросов облегчает отрисовку. 3) Вынос тяжёлых операций в отложенные действия (эффект сомнительный, так как однопоточность остаётся самым сильным фактором, влияющим на перерисовку). P.S. Пытаясь сформулировать проблему, мы с Петром пока что пришли к такому выводу: механизмы отображения в ББ хороши сами по себе, но GUI в целом имеет некоторые проблемы в виде однопоточной увязки и зависимостей от WinAPI. В результате, затяжные процессы в прикладной логике могут оказывать влияние на момент финального рендера виджетов. |
Автор: | Info21 [ Суббота, 19 Март, 2011 13:05 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Иван Кузьмицкий писал(а): затяжные процессы в прикладной логике могут оказывать влияние на момент финального рендера виджетов. Напрашивается выделение прикладной логики с затяжными процессами в отдельный экземпляр ББ -- и пусть общается с "фасадом" через какое-нибудь TCP/IP.Сам бог велел, no? (В длинных вычислялках эта проблема тоже есть, поэтому любопытно.) |
Автор: | Иван Кузьмицкий [ Пятница, 29 Апрель, 2011 21:59 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Небольшое замечание. Заключение операций изменения внедрённых отображений в модификационные скобки BeginModification, EndModification значительно повлияло на общую картину в целом. Эти операции с самого начала не должны были быть неотменяемыми, но как-то это всё откладывалось "на потом". Так вот, флики стали совсем малозаметны (хотя там, где много виндовых контролов, всё равно остались). А наткнулись на этот факт совершенно случайно, копая бесконтрольное отжирание памяти при каждой перерисовке внедрённых отображений. |
Автор: | GameHunter [ Понедельник, 04 Июль, 2022 00:28 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Скажите пожалуйста, мерцание виндовских контролов так и не побеждено? У меня такая ситуация: есть вьюшка, которая содержит две подвьюшки (сплиттер), соответственно, в Restore вызываются два InstallFrame'а для каждой из подвьюшек. Всё работало хорошо, пока я не стал использовать в качестве подвьюшек скроллеры - со скроллерами при изменении размера мерцает та подвьюшка, InstallFrame которой вызывается вторым (а первая - не мерцает). Причём мерцают и полосы прокруткаи, и содержимое скроллера. Поигравшись с кодом StdCFrames и HostCFrames, я выяснил, что дело в отрисовки виндовских скроллбаров, но дальше продвинуться не могу... |
Автор: | Иван Денисов [ Понедельник, 04 Июль, 2022 09:06 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Антон Дмитриев мне рассказывал, что этот вопрос изучил подробно и сами Microsoft эту проблему не смогли победить, поэтому просто ушли от использования собственных контролов. Все контролы Windows без вариантов отключают буферизацию вывода графики. Поэтому вариант только использовать кросс-платформенный скроллбар, который уже есть в HostCFrames для версии 1.8 и 2.0. Если для вас критично использовать именно MDI версию ББ, то можете аккуратно перенести код из этого файла в секцию, где реализованы скроллы HostCFrames в вашей версии. |
Автор: | GameHunter [ Понедельник, 04 Июль, 2022 15:46 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Я как раз и использую версию 1.8... (и кстати в Delphi 7 ничего не мерцает...) |
Автор: | GameHunter [ Понедельник, 04 Июль, 2022 17:12 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
Ваш файл, в принципе, помогает. Спасибо. |
Автор: | adimetrius [ Вторник, 25 Октябрь, 2022 01:10 ] |
Заголовок сообщения: | Re: И снова о мерцании. |
В ББ, чтобы не мерцало, используется двойная буферизация (как и везде в современных системах). Однако приборы 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, и вообще списками общего вида. |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |