Comments 23
Можно вопрос по поводу корректности освобождения памяти в первоначальной реализации?
Если я правильно помню Qt, то там родительский QObject автоматически удаляет дочерние QObject-ы, поэтому если при создании QFormLayout в конструктор передать указатель на родителя, то об удалении QFormLayout можно не беспокоится. Но в показанном примере создание выглядит так:
_pLayout = new QFormLayout; // В конструктор ничего не передается.
А в методе очистки clear удаления _pLayout нет вообще. Т.е. происходит утечка памяти.
Если я понимаю правильно, то в clear нужно добавить `delete _pLayout`.
Или я чего-то не знаю и здесь все OK?
У графического приложения на Qt (5 версия) есть одна особенность: при изменении положения окна\его размеров обработка любых событий приостанавливается. Явного перехвата событий не делаю, работают только стандартные слоты.
По ощущениям, "зависание" происходит в цикле обработки событий, но как это обойти не совсем ясно. Форма создается стандартными средствами Qt. Может подскажите в какую сторону посмотреть? Тоже ведь своего рода задача оптимизации)
Разве обработка в не GUI потоке различных данных не решит проблему? Ну да, гуй будет все так же висеть, но различные процессы будут работать.
а Вы случайно картинку не через RDP смотрите?
Я собрал вашу игру, у меня картинка не расслаивается, как будто бы всё отрисовывается нормально. У меня правда макось и Qt 5.15, но не вижу, как бы это могло повлиять.
А можно было не изобретать велосипед, и сразу использовать QTableView с моделью, наверняка получилось бы ещё гораздо быстрее, возможно, что на порядок.
По-моему тоже проблема в том, что не надо отрисовывать слишком много виджетов одновременно. Стоит применить подход view-model
Так слишком много виджетов и не рисуется. Понятия "отрисовка" и "подготовка к отрисовке" - разные понятия. Отрисовка в Qt, в офисной графике, и в частности, в классе QTableWidget мгновенна (ну, пара миллисекунд). А вот подготовка - это да, это как раз про расчет координат и размеров всех ячеек. Без подготовки, например, скроллеры рисоваться не могут. И эта подготовка делается (должна делаться) при любом раскладе, что бы ни использовали - лайоут или таблицу в самых разных ее проявлениях (например, html внутри QLabel). А любой табличный виджет (QTableWidget, QTableView) - это и есть непосредственно MVC, модель там внутри. Просто в QTableWidget есть, само собой, свои небольшие обертки над базовыми классами, и вот на них потенциально можно сэкономить. Но маловероятно, что там получится что-то выжать, ибо очень уж простые там обертки, и все запросы к QTableWidget сразу идут в модель.
Или она только для внутреннего использования и в оперсорс не будет выкладываться?
Не будет выкладываться. По поводу мыслей - коллега в соседнем посте правильно подсказал то, что является самым началом этой библиотеки. А в ее развитии и в результате коммерческого использования родилось довольно много неочевидных на первый взгляд нюансов и особенностей. И довольно много кода было написано для достижения той самой оптимальности, да еще для того, чтобы подходить под разные сценарии использования.
Имхо, надо брать MVC паттерн, емнип рисуется только то что в области прокрутки.
выше все сказано. https://habr.com/ru/post/672962/#comment_24469878
Мне одному кажется, что с точки зрения UI иметь длиннющий список на Овер 100 позиций в области прокрутки - это убожество? Сделайте поле для фильтрации значений для этого списка, чтобы его крутить не приходилось, или разбейте длинный список на более мелкие категории, чтобы каждый список получился в разы более короткий и в разы более удобный юзеру
Оптимизация GUI на Qt