Оптимизация GUI на Qt

[eao197]

Можно вопрос по поводу корректности освобождения памяти в первоначальной реализации?

Если я правильно помню Qt, то там родительский QObject автоматически удаляет дочерние QObject-ы, поэтому если при создании QFormLayout в конструктор передать указатель на родителя, то об удалении QFormLayout можно не беспокоится. Но в показанном примере создание выглядит так:

	_pLayout = new QFormLayout; // В конструктор ничего не передается.

А в методе очистки clear удаления _pLayout нет вообще. Т.е. происходит утечка памяти.

Если я понимаю правильно, то в clear нужно добавить `delete _pLayout`.

Или я чего-то не знаю и здесь все OK?

[BeardedBeaver]

Там ниже по коду этот лейаут присваивается в виджет, если я правильно помню, именно в этот момент виджет становится родителем лейаута

[eao197]

Да, спасибо!

Так оно и есть.

[mctMaks]

У графического приложения на Qt (5 версия) есть одна особенность: при изменении положения окна\его размеров обработка любых событий приостанавливается. Явного перехвата событий не делаю, работают только стандартные слоты.

По ощущениям, "зависание" происходит в цикле обработки событий, но как это обойти не совсем ясно. Форма создается стандартными средствами Qt. Может подскажите в какую сторону посмотреть? Тоже ведь своего рода задача оптимизации)

[Hvorovk]

Разве обработка в не GUI потоке различных данных не решит проблему? Ну да, гуй будет все так же висеть, но различные процессы будут работать.

[mctMaks]

скорее всего решит, но тогда меняется сложившаяся система сигналов-слотов. не критично.

с другой стороны, те примеры что я видел в интернетах\гитхбах не используют раздельные потоки для GUI и остального, но и описанной проблемы нет. явно что я делаю что-то не так.

[unC0Rr]

Не лучше ли было бы переделать отображение на использование единственного QLabel с использованием RichText?

[kalirgum]

У Вас правильное направление мыслей. Этот шаг оптимизации вполне может быть следующим. Но мы пробовали вгонять в QLabel html-таблицу, и это было медленно.

[da-nie]

Не по этой теме, но всё-таки связано с GUI. Есть ли в Qt возможность отрисовки виджета (QPainter через drawPixmap) с синхронизацией с кадровой развёрткой? А то при частом рисовании получается расслоение экрана, когда вывод не попадает в развёртку, а картинка изменилась.

[remova]

а Вы случайно картинку не через RDP смотрите?

[da-nie]

Нет, я смотрю прямо на ЖК-мониторе на компьютере, где запускаю. И я вижу как картинка расслаивается. Если я использую для вывода картинки Direct Draw, то при включённой в нём синхронизации картинка выводится чётко. Но вот если я использую Qt ( не Open GL в Qt, а через drawPixmap), то виден рассинхрон частей экрана. Причём, что в Linux, что в Windows. Речь идёт про самопальную игру. Вот для Windows под Qt, а вот для Linux под Qt. А вот для Windows под Direct Draw. Во время движения у меня, как я уже сказал, в версиях для Qt экран расслаивается. И решения этой проблемы я не нахожу.

[sgusev]

Я собрал вашу игру, у меня картинка не расслаивается, как будто бы всё отрисовывается нормально. У меня правда макось и Qt 5.15, но не вижу, как бы это могло повлиять.

[da-nie]

А вы во весь экран сделали? Там надо внимательно смотреть когда идёт скроллинг фона (просто непрерывно идите). Тогда проскакивает расслоение — видно, что отрисовка не попадает в развёртку кадра.

[Zifix]

А можно было не изобретать велосипед, и сразу использовать QTableView с моделью, наверняка получилось бы ещё гораздо быстрее, возможно, что на порядок.

[zhekaal]

По-моему тоже проблема в том, что не надо отрисовывать слишком много виджетов одновременно. Стоит применить подход view-model

[remova]

Так слишком много виджетов и не рисуется. Понятия "отрисовка" и "подготовка к отрисовке" - разные понятия. Отрисовка в Qt, в офисной графике, и в частности, в классе QTableWidget мгновенна (ну, пара миллисекунд). А вот подготовка - это да, это как раз про расчет координат и размеров всех ячеек. Без подготовки, например, скроллеры рисоваться не могут. И эта подготовка делается (должна делаться) при любом раскладе, что бы ни использовали - лайоут или таблицу в самых разных ее проявлениях (например, html внутри QLabel). А любой табличный виджет (QTableWidget, QTableView) - это и есть непосредственно MVC, модель там внутри. Просто в QTableWidget есть, само собой, свои небольшие обертки над базовыми классами, и вот на них потенциально можно сэкономить. Но маловероятно, что там получится что-то выжать, ибо очень уж простые там обертки, и все запросы к QTableWidget сразу идут в модель.

[Zifix]

Я не уверен, в чем именно проблема, но по моему опыту, переход с *Widget на *View дает очень существенный прирост производительности.

[DiegoRA]

А можно поподробнее про библиотеку для отрисовки «графика из миллиарда точек»?
Или она только для внутреннего использования и в оперсорс не будет выкладываться?

[da-nie]

А что там такого сложного? У меня мой компонент (он не для Qt, но и для Qt я его адаптировал) такое умеет. Но после каждого масштабирования будет задержка на пересчёт и объединение точек. В дальнейшем отрисовка идёт уже этих объединённых точек в данном разрешении. А можно заранее просчитать наборы с разной плотностью точек на пиксель (построить пирамиду, например, удваивая плотность каждый раз) и просто переключаться между ними — в этом случае задержка будет только в первую отрисовку.

[kalirgum]

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

[ulrich87]

Имхо, надо брать MVC паттерн, емнип рисуется только то что в области прокрутки.

[remova]

выше все сказано. https://habr.com/ru/post/672962/#comment_24469878

[kompilainenn2]

Мне одному кажется, что с точки зрения UI иметь длиннющий список на Овер 100 позиций в области прокрутки - это убожество? Сделайте поле для фильтрации значений для этого списка, чтобы его крутить не приходилось, или разбейте длинный список на более мелкие категории, чтобы каждый список получился в разы более короткий и в разы более удобный юзеру