qml:: вердикт по опыту эксплуатации 6 мес.

[OKTA]

Создаю 32 картинки, ставлю таймер, который срабатывает каждую миллисекунду и меняет постоянно source у всех этих 32 картинок... Процессор плевать хотел.. вот 128 картинок уже заставили его нагрузиться, да и то на 20 процентов, судя по диспетчеру..

[ctin]

lighting: да всё ок, в релизе таких глупостей нету.
OKTA: FFFFFFFFUUUUUUUUUUUUU!!!!!!!!!!!!.........
придется проверять и дальше копать....

[OKTA]

Ты ничего с потоками не намудрил?)

[ctin]

мудрил. rx и tx - это свойства (properties), значение которым присваивается в отдельном потоке. В QML написано просто: opacity: (device.rx != 0)

[0x0001]

программа с такой частотой опрашивает железку. На RX и TX стоят картинки. Вот и получается 10мсек.

При всем уважении, с такой частотой опрашивать используя стандартный COM port API (или Virtual UART-USB) for Win7/XP на "среднестатистическом"  компьютере невозможно, надо делать свою PCI с hw буферизацией или USB full speed + свой driver.
например я использую около 150мс, почему "около" - просто стараюсь делать запросы в моменты "простоя" всех потоков и отсутствии в очереди  WIN32 сообщений, но проверяю таймером чтобы не более 200мс. "Железка" же естественно отвечает моментально.

У меня сейчас в принципе 1 идея, продолжать рисовать "за экраном" весь интерфейс(графика,картинки и пр), как уже делал с применением DirectX и далее выводить все это на экран вкупе. QML не подходит для выполнения в динамике >200мс (про инерцию глаза + осознание Человеком не забываем) более 80 элементов для средних PC, а для нетбуков особенно!

Значит я решил так, и так и будет, всю графику рисую "за экраном", далее вывожу раз в 200мс вкупе вне зависимости от того менялось что-то или нет(чтобы сократить свою работу). Да и применяю OpenGL, благо любой нетбук даже за 7000р уже поддерживает.

Элементы управления(кнопки, ползунки и пр) - оставляю QML рисованные, поверх. причем в отдельном потоке. Но тут плохо, что эффекты(лоск) типа теней и пр. придется отключать и не использовать управляющие "контроллы", отображение которых зависит от быстрых динамически меняющихся входных данных (медленные состояния типа ON/OFF можно оставить)

В  общем еще раз Вердикт - в Qt 8.4.3. - применение QML1.0 лишь дешевый рекламный "лоск", для серьезных программ не подходящий... Это Объективное суждение основанное на опыте и оно безоговорочное. Конечно кто-то может продолжать насиловать "моск" пытаясь доказать что кто-то что-то там делает "не оптимально", но мне надо зарабатывать $$$ и "завтра"

Ждем-с QML2.0 ))) !!!

[Igors]

В  общем еще раз Вердикт - в Qt 8.4.3. - применение QML1.0 лишь дешевый рекламный "лоск", для серьезных программ не подходящий... Это Объективное суждение основанное на опыте и оно безоговорочное.

[/offtop]
Если Вы хотите чтобы Вас слушали - говорите тише а не громче Не надо утверждать что Ваш вывод объективен и безоговорочен - это лишь вызовет реакцию "доказать обратное". Скромное "слово практика" имеет куда больший эффект   

[Bepec]

При всем уважении, с такой частотой опрашивать используя стандартный COM port API (или Virtual UART-USB) for Win7/XP на "среднестатистическом"  компьютере невозможно

Кхм. Видимо мы из другого измерения Мой "среднестатический" нормально тянет общение до 4 мс.

Другой вопрос, что тут нужна довольно умная реализация протокола

[ctin]

0x0001
У Вас цикл - открывание порта, обмен данными, закрывание.
У меня: открыл порт, очередь комманд (считывание температуры, состояния, отправка данных), закрыл порт. Естественно 3мс - это время обработки команды, с записи до приема. И то если команда маленькая а скорость высокая (115200). На 9600 уже 30мс.
И да, я прибавил к Quick 1.1 плагин Desctop components и все стало совсем хорошо.

[Bepec]

Расчёт времени на передачу байта при заданных скоростях рассчитывается по формуле
И 10-15 мс это нормально. Даже скорее медленно.

[xokc]

Слушайте, что-то я потерялся. Проблема всё-таки в малой производительности QML или недостаточной скорости опроса COM порта под Windows?
Я правильно понимаю, что топикстартер пришел к выводу, что даже простейший QML-элемент интерфейса не успевает изменять свое состояние за время, соизмеримое с реакцией человеческого зрения (1/25 сек = 40 мс)? И чем в таком случае тут поможет QML2?

[Bepec]

Видимо ничем.

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

PS трудно разобраться, гораздо проще пусть он перепишет

[OKTA]

Знаете, сегодня заметил, что у меня c++ тормозит - уж не знаю, может новую версию ждать? Или на Delphi перейти?

[Bepec]

Жди С++ тринадцатый стандарт. Там введут функцию сделать всё хорошо

[OKTA]

 

[Пантер]

Жди С++ тринадцатый стандарт. Там введут функцию сделать всё хорошо

Ага, Александреску ее на шаблонах пишет. Только для сборки нужно будет пару терабайт оперативы.