Russian Qt Forum

Добрый вечер коллеги! Давно я не обращался за помощью, но тут хз уже куда копать и что делать. Проблема следующего рода:
Имеет грид вью, на нем изначально загружено 20 элементов, остальные погружаются через fetchMore, так вот, в делегате по сути картинка и текст, он достаточно простой. Так вот, если я начинаю интенсивно подгружать элементы, т.е. двигаться по гридвью вниз так, что бы он дергал fetchMore у меня начинает расти память, за 2к элементов съедает примерно 25-30 мб памяти, для меня это существенно.  Делегаты создаются и прибиваются, примерно по 20 штук, именно те которые отображает гридвью
Проблема 1. Листвью и подобные им разве не хранят и удаляют делегат только в области видимости(во вью порте), кешбуфер не рассматриваем. Если так, то почему постоянно растет память во время fetchMore. Принудительный запуск сборщика мусора не помогает
Проблема 2. Если я выгружаю этот гридвью, с элементами, которые отожрали 20 мб, к примеру через лоадер, память не освобождается, собственно почему? Очистка кеша от энжина не помогает
Спасибо.

Очевидно, где-то утечка памяти. Сделайте минимальный пример, где воспроизводится проблема и покажите код. А так можно только тыкать пальцем в небо (например, при fetchMore данные у вас должны откуда-то загружаться и, вероятно, храниться в памяти, может у вас данных на 20Mb загрузилось)

Еще можно заюзать тулзы, определяющие утечки. (Например, если проект под Visual Studio, то можно Visual Leak Detector)

P.S. Qt-шные делегаты не создаются/уничтожаются постоянно, если вы их имели в виду

+1 к VLD, правда, для Qt приложения он выведет кучу бреда, смотрите в самом конце вывода - там может быть полезное.

А вообще да, странно, что у вас делегаты пересоздаются. По хорошему, их надо создать 1 раз и все.

ЗЫ. 2048-е сообщение  :D

Что странного то ? Эти элементы за счет чего и используются, что не создают разом элемент на каждую запись в модели, вы представляете как это было бы, если у меня в модели 5к элементов, по вашим словам он должен сразу 5к элементов создать и никогда их не удалят. Если моим словам не верите, проверьте сами, поставьте вывод в консоль на конструкторе объекта в qml и деструкторе объекта qml
С проблемой 2 совсем не понятно, как освободить потом память от листвью который ее сожрал

Так смысл делегатов в том, что создается 1 штука на столбец, или строку, или ячейку (зависит от задачи), и этот делегат тупо рисует данные (для всех ячеек по очереди), которые он берет из модели по индексу. Поэтому и странно, что они у вас создаются, а потом удаляются.

А давайте посморим... Код? :D

Да господи, простейший пример
Нажимаем на квадрат, создается грид вью с делегатами, нажимаем еще раз, ему производится дестрой, память осталось зарезервированной, нажимаем еще раз на квадрат, он опять создает объект, память не растет, но как прибить то, что остается после destroy не понятно.

ааа, QtQuick ...
тут дебаггер бессилен :(

ааа, qml. хз что там.

Граждане, вы угораете что ли ? Раздел как бы:
Russian Qt Forum > Forum > Qt > Qt Quick

Да я сразу как то не заметил, в этот раздел редко пишут... просто Qml очень сырой и глюкавый.
Точно знаю, что на виджетах проблем с делегатами нет.
Возможно, есть смысл решить вашу проблему попробовать с виджетами?

Просто QML это ммм... скорее какая то дизайнерская штука, а не программистская. :)

update: если дело на винде, оно может и не убираться сразу из распоряжения процесса. Чтобы оно убиралось сразу, нужен параллельно ресурсоёмкий процесс запустить, тогда менеджер памяти все ресурсы затребует.
Если оно при повторном запросе/очистке не жрёт память, то это нормально.

Подтверждаю, натыкался на утечку в ListView. Если правильно помню, связана она была именно с программными скроллингом листа, т.е. вызова positionViewAtEnd() и аналогичных методов.
Решение - Flickable + Repeater. По сути придется написать ListView самому с нуля, благо это делается за минут 40 и дает нехилый профит в плане контроля над поведением объектов.
Вот не нужно говорить глупостей. На qml/js можно писать серверную логику, например, и это будет крайне удобно.

Вы не будете спорить, что для разработки программы на QML необходимо иметь задатки дизайнера? :D

Для разработки любого гуя нужны задатки дизайнера. Но это никак не делает сам язык дизайнерским) Например, тот же LUA.

Зачем ? Я вот вообще цвета не различаю, нормально на работе делаю интерфейсы на qml, конечно же по макетам

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

PS  И если Qt идёт как библиотека С++ с простой логикой и низким порогом вхождения, то QML предназначен исключительно для разработки интерфейса :)

Это все древние бородатые времена. В наши дни qml/js уже давно позиционируется как центральная платформа  для написания приложений, а С++ идет чисто для его расширения (и да, пусть меня за это закидают помидорами, но это так).
И да, в qml вам никто не запрещает разделить логику и сам интерфейс. Собственно, я так и делал, там есть для этого невизуальные компоненты.

Спасибо, поржал :D

Не за что) Подумай потом на досуге, почему виджеты так безнадежно забросили)

Видимо потому, что [быдлокодеры|недокодеры|недо программисты] не осилили.
Web дизайнеров развелось куча а потом думаем, что ж так-то простенький интерфейс тормозит-то.
> Спасибо, поржал :D // поддерживаю

Он и в другой теме веселит подобными репликами...

"Москва - нью Васюки"  :)

Думается что ответа ТС не получит - вот на "устаревших" плюсах можно разобраться куда же делась память, а тут взяли цацку - попали в зависимость от нее.   

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

QML - это типа чтобы снизить порог вхождения и ускорить разработку. Если знаешь С++/QtWidgets, то смысла в QML я виже не много. Например, мне кажется, проще делать анимации интерфейса (если они нужны). QtQuick Controls 2.0 сделали реально быстрыми.

Сам пишу на виджетах и не вижу для себя смысла в QML вообще.

Я хочу qml, но не могу :D Ибо если классы/структуры/потоки это мне понятно, но вот "берём прямоугольник, а мб квадрат и суём туда логику и получается кнопка" - этого я не могу усвоить :)

Ты просто не ковырялся с ним, я раньше тоже не понимал, стоит только начать и попробовать

[offtop]Можешь скинуть что нить вроде для примера?
Потому что кнопки, комбобоксы, фигню всякую делать то я могу, а вот что посложнее с логикой и анимацией буксую :)[/offtop]

Яваскрипт то? Не осилили, да, потому до сих пор сидят мучают свои cpp, в котором на каждый чих нужно написать тонну кода, а самые тривиальные действия обильно сопровождаются граблями и стульями)
Кстати да, еще ни разу не видел лагающего интерфейса на qml)
Вариант выше полностью решает проблему) А проблема как раз в том, полагаю, что ListView написан на плюсах, потому что использование Column + Repeater + Flickable не дает никаких утечек)

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

Смысл qml не в QtQuick Controls 2.0, это лишь малая часть. Сама QQmlEngine вообще абстрагирована от интерфейса. Ну а смысл, естественно, в том, чтобы писать на явасрипте и иметь некоторые бонусы, связанные с типизацией, наследованием, биндингом/сигналами и прочими плюшками.

Создавая компонент ты по сути создаешь класс. Компоненты соблюдают наследование. Можно передавать ссылки, писать методы, вытаскивать сигналы и свойства. Описав объект ты создал объект данного класса. Что тут вообще может быть непонятно?

Последняя моя попытка достучаться до сознания Komorebi:
В QML понятия класс/view/model/worker как таковые не существуют. Есть нечто среднее и оно ограничено тем функционалом, что решили разработчики. Всё. Дальше этой границы никто не уйдет. По сути это конструктор.

C++ и прочие полные языки разделяют эти понятия и дают возможность создать своё. Границы возможностей как таковой нет, она зависит исключительно от возможностей и знаний программиста. Всё что нельзя создать одним способом, можно создать десятком других и так далее.

QML ущербен как ЯП, т.к. он предназначен для быстрого прототипирования интерфейса и заточен исключительно на это. Многие вещи в нём реализовать невозможно, от слова вообще.
Собственно тролли это знают и именно поэтому в QML есть возможность проброса C++ классов и прочее.
Возможно в будущем, в версии 3/4/5/6/7 они дополнят язык. Но пока это язык для интерфейса :)

PS если проще - QML с С++ - это превосходно. QML без С++ - это инвалид.

У вас какое-то обострение? То Windows vs Linux, теперь C++ vs QML. Глупо говорить, что что-то не нужно, только потому что ты не смог разобраться или, что еще хуже, кто-то там сказал что оно плохое. Чаще всего эти споры зависят от конкретных задач.

Не для кого, надеюсь, не секрет что QML делает упор на интерфейс. И, надо сказать, этот инструмент очень удобный для всяких мобильных платформ, терминалов и прочего. Для сложных приложений лучше конечно не отказываться от C++ в связке с QML. Разделять логику и интерфейс в QML тоже можно без проблем. А вот виждеты я предпочитаю для десктопных платформ, там они смотрятся хорошо и привычно.

carrygun WTF?
Откройте глаза, не я начинаю эти темы :) Так что спрашивайте зачинщиков. Но то, что я говорю верно на 85% :)

На 85% тут только бред.

Например:

Это как примерно сказать "Ну SQL ущербен, так как он предназначен для написания запросов и заточен исключительно для этого."

Я просто хотел вам сказать что нельзя брать один инструмент и подходить с ним к любой задаче. QML в конце концов часть SDK и если бы они позиционировали его как отдельный продукт, то так бы и сделали. Вам дали хороший, годный инструмент. Бесплатно. Остается брать и применять его с умом. Не надо на нем писать комбайны, конверторы видео или работу с памятью. В официальном "букваре" написано что такое QML и как его правильно готовить.

Или вот:

Очень хотелось бы чтобы вы действительно подумали, особенно прежде чем писать такие вещи. Если их не используете вы, то это не значит, что все их не используют.

P.S. я никого не хотел обидеть (но вы держитесь там), но зачастую в таких спорах (не только в этой теме) только и видно аргументы "Это круто, потому что все говорят круто и потому что я этим пользуюсь, а все остальное фигня без задач."

Значит ты мало еще в этой жизни повидал, давно работаю с ним и поверь, оно тормозит. Хотя конечно на и7 с 16гб оперативной памятью этого не видно

carrygun
Моё - Ваше - И это два одинаковых изречения, с одинаковым смыслом. Он ущербен как полноценный ЯП, но в составке C++ + Qt + QML он хорошо выполняет свою задачу.

- эт вообще не моя реплика, обращайтесь к разводителю аля "Komorebi".

PS и не разводите оффтоп в теме. Создавайте уж тогда лучше новую тему и я вам предметно докажу что вы неправы :)

Я так и не увидел в чем ущербность того или иного ЯП, кроме того что вы ничего не поняли и не разобрались. С тем же успехом можно открыть Хаскель, Эрланг, Лисп, итд и сказать "ну, блин, ничего не понятно, ущербные языки". Возводить одни кресты в абсолют - глупо, лучше развивайтесь.

Ущербность чаще всего видно по конечному продукту.
Понятно, что и на С++ можно написать жутко тормознутый код.
Но если принять, что, допустим, код написан "правильно" - можно ли средствами Хаскель, Эрланг, Лисп, итд добиться таких же качественных (во всех отношениях) продуктов, как на "древних плюсах"?

Насколько я понял (мельком глянув Qt доку), QML позволяет легко и быстро создавать разнообразные эффекты прямо "ис каропки". Мне это не нужно (или нужно редко), поэтому QML не пользуюсь.

Все же, пользуясь случаем, хотелось бы поинтересоваться у тех кто на нем работает - а насколько велики его мощности/возможности? Если мне (ну вот вдруг) понадобятся те эффекты что в доке - я их и на плюсах напишу (пусть и затратив куда больше времени). Из-за такого нет смысла "изучать систему".

Но вот напр такой случай (http://www.prog.org.ru/index.php?topic=29172.msg213870#msg213870). Тут уже все не так просто. Насколько здесь поможет QML? Напрашивающийся ответ "да, конечно, там же есть мощные/развитые партиклы" я уже получил.  Только вот думаю здесь партиклы не очень подойдут. А иначе - как?

Спасибо

QML + js - это полноценное ООП. Нет ничего такого, что нельзя сделать на QML и js, что при этом можно сделать на C++, исключая всякие низкоуровневые вещи, для расширения QML окружения которыми и используется C++.
На ноде системные утилиты порой пишут. Тут то же самое. Принципиальных архитектурных отличий нет.

У меня почему-то на офисных компах из 2007го с 255 мб оперативки не тормозит, а у вас - тормозит. Любопытно. Может, это не мне чего-то там повидать стоит?)

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

GLSL - весьма низкоуровневое, специфическое и трудоемкое программирование. Если, по Вашему мнению, его использование неизбежно - это плохая реклама QML

Приложение hello world конечно не тормозит, что-то более весомое и ты удивишься. Наше приложение как минимум занимает 200 мб памяти, так что у вас оно бы колом совсем стало

Что за глупость?
GLSL может быть плохой рекламой исключительно OpenGL, но никак не QML, где его использование вовсе не обязательно.

Есть готовый набор эффектов. Их много, и их хватает. Но даже если нужного эффекта нет - написать с использованием QMLных шейдерэффектов его будет куда проще и эффективнее. Фича в том, что в качестве текстур можно использовать QMLлные объекты. То есть если тебе хочется применить свой кастомный шейдерэффект к фоточке - тебе нужно написать только конкретный GLSL, не заморачиваясь о других деталях, и по мне так это отличная реклама для данной технологии, учитывая, что готовых шейдеров под абсолютно все жизненные ситуации нет ни в одном фреймворке, а стандартные имеющиеся готовы реализовать большинство среднестатистических потребностей, и их база постоянно растет.
Если все правильно завязать на event loop - тормозов попросту не будет. Я написал не одно приложение используя данную технологию в качестве основы, и все было супер. Анимации на 60 фпс без каких-либо проседаний. При этом я не экономил на вышеупомянутых шейдерэффектах и прочих вещах, а помимо самого интерфейса в qml так же вертелась куча бизнеслогики, в т.ч. работа с SQL.
Если что-то и будет тормозить - так это сишный код, при условии того, что он написан так, чтобы давать фризы и создавать iowait.
Потребление памяти - вопрос совершенно другого плана. 200 мб в 2016м году это вполне приемлемо. Оперативная память - дешевый ресурс, гораздо дешевле тактовой частоты проца, потому пусть лучше жрет память, чем нагружает проц под потолок. И, пожалуйста, не говорите, что между потреблением этих ресурсов нет никакой зависимости.

Ага, скажите об этом эмбедщикам или автомотивщикам, они, я уверен, оценят шутку :D

Вот вы серьезно утверждаете, что между приложением на C++ и на QML абсолютно не будет разницы в производительности?
Чем докажете?

За свою жизнь я написал пока один GLSL шейдер  :) Правда большой. Отладка длилась полгода (разнообразные карты юзеров). Сейчас мой шейдер пора апдейтить, но мы с удовольствием наймем человека, мои способности слабоваты. Так что если GLSL "такой хароший" - см раздел "объявления" здесь.

Что касается "подкрашивания пикселей" (именно такие шейдеры я видел для QML), то куда проще сделать это в QImage, навязывание GLSL не есть достижение.

Вот я привел пример кастомного эффекта - и как-то не увидел "дизайнерской жилки" у "ребят QML 120+" :) Ну ладно, в коробке нет(?), дальше что? Да ничего, ни одной мысли не прозвучало.

Применяя "крутой" стандартный эффект, не возникает мысли/беспокойства типа

Да конечно будет, и в разы (если не на порядки). Просто тут упор на то что (якобы) "на QML это делается одним движением" (а на плюсах пахать и пахать). Ну типа "скорость разработки". Вот я и поинтересовался что будет когда готовые цацки закончатся  :)

/facepalm
http://i.imgur.com/iWKad22.jpg (http://i.imgur.com/iWKad22.jpg)
Завязывай ты с этим бредом, как бы мне не нравился Qml, поддержать я тебя не могу и судя из твоих слов, совсем мало ты работал с ним в серьезных проектах