Qt графична производителност на soft-float ARM?

Бих искал да създам подобен на автомобилно табло Qt интерфейс (габарити, циферблати, копчета и т.н.). Устройството ми има 800x480 LCD, захранван от imx287 ARM SoC (armv5te без хардуерно плаване или GPU).

Проблемът, който имам, е, че е много бавен. Единичен индикатор (фоново PNG изображение, с въртящо се PNG изображение на циферблат), начертан с 20 кадъра в секунда, използва ~20% процесорно време. Добавянето на един изобразен текстов низ увеличава до 40% използването на процесора.

Използвам QGraphicsScene, който използва много изчисления с плаваща запетая... проблем, тъй като моята SoC няма хардуерна способност за плаване.

Има ли алтернативи на QGraphicsScene, които биха работили добре за мен?

Ето какво правя в момента:

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);

bg.load("rpm.png");
needle.load("needle.png");

scene = new QGraphicsScene(this);
scene->setSceneRect(0,0, 800,480);

scene->addPixmap(bg);

needleItem = scene->addPixmap(needle);
needleItem->setPos(400-4,17);

textItem = scene->addText(tr(""), QFont("utsaah", 50, QFont::Bold, true));
textItem->setDefaultTextColor(QColor(255,255,255));
textItem->setPos(430, 360);

ui->graphicsView->setScene(scene);

thread = new UpdateDialsThread(this);
connect(thread, SIGNAL(updateDials()), this, SLOT(updateDials()));
thread->start();
}

void MainWindow::updateDials(void)
{
static int deg = 180;

deg += 1;
if (deg > 180+270)
    deg = 180;

QTransform trans;
trans.translate(needleItem->boundingRect().width()/2, needleItem->boundingRect().height());
trans.rotate(deg, Qt::ZAxis);
trans.translate(-needleItem->boundingRect().width()/2, -needleItem->boundingRect().height());
needleItem->setTransform(trans);

textItem->setPlainText(tr("%1").arg(deg*10, 4, 'f', 0));
}

Благодаря предварително!


person thecoder    schedule 24.04.2014    source източник
comment
Използвам Qt 4.8.5 на персонализирана дистрибуция (с помощта на buildroot). Опитах се да премахна дълбочината на битовете с това, но изглежда няма ефект. Не съм сигурен как да тествам битовата дълбочина в приложението, за да проверя дали опциите наистина работят. QWS_DISPLAY=LinuxFb:/dev/fb0:depth=16 QWS_DEPTH=16 ./test3 -qws   -  person thecoder    schedule 25.04.2014
comment
Създавах цялата ОС с -O3, но сега ще опитам -Os, за да видя каква е разликата. Вече компилирах всичко с -march=armv5te -mtune=arm926ej-s. Qt имаше активирани дълбочини 1,16,24,32, но ще опитам да активирам само 1 и 16. Това е платката, която използвам: crystalfontz.com/product/CFA921TS . Благодаря за помощта.   -  person thecoder    schedule 26.04.2014
comment
blit_setup(): Дълбочина на екрана 32 не се поддържа! Устройството linuxfb поддържа само 32 бита.   -  person thecoder    schedule 27.04.2014
comment
Добре, актуализация. Опитах се да създам всичко с -Os, тестовото приложение (код както по-горе) използва около 4% повече използване на процесора от -O3. Добавянето на -no-armfpa изглежда не е направило никаква разлика. Сега преминах към използване на GCC 4.8.1 вместо 4.6.x, което намали използването на процесора с около 8%. Освен ако нямате повече предложения, изглежда, че това е толкова добро, колкото може да стане.   -  person thecoder    schedule 28.04.2014
comment
Със сигурност можете да накарате драйвера да поддържа 16-битови кадрови буфери (или дори по-малко); IMX просто задава ниската/неизползвана линия на нули. Това ще увеличи 1/2 честотната лента на паметта, което е основният проблем с блитера. Имате ли източника на Linux? Коя версия е? Ако не можете да промените Linux, тогава това е най-доброто, на което можете да се надявате.   -  person artless noise    schedule 28.04.2014
comment
Добре, благодаря за предложението. Ще започна да хаквам кода на драйвера на linuxfb на ядрото. Ще бъде интересно да видим колко голяма е разликата. Малко съм изненадан, че Qt няма опция за изобразяване на вътрешен 16-битов буфер, след което запис в 32-битовия буфер на linuxfb. Благодаря отново! Ще актуализирам, когато направя промените и направя някои тестове.   -  person thecoder    schedule 29.04.2014
comment
Трябва да е толкова лесно, колкото актуализирането на .bpp и .pcr. Променете .bpp = 32 и .pcr = 0xF0D00080|END_SEL на .bpp = 16 и .pcr = 0xF0D00080 (добре за iMx25, използващ платформено устройство). Т.е. драйверът го поддържа, просто трябва да изпратите някои конфигурационни данни. Може да се наложи да погледнете листа с данни на iMx28 за стойността .pcr.   -  person artless noise    schedule 29.04.2014
comment
Изглежда беше по-лесно от това. Просто трябваше да променя битовата дълбочина в изходния файл на дървото на драйвера. Това помогна, намалявайки използването на процесора с още 8%. Така че изпълнението на кода в OP сега използва ~22% процесорно време. Това ще свърши работа засега, мисля... ще завърша създаването на моето Qt приложение и ще се върна към това, ако има проблем по-късно. Благодаря отново!   -  person thecoder    schedule 01.05.2014


Отговори (2)


Препоръчвам да използвате QML вместо QGraphicsView. Можете да създавате персонализирани измервателни уреди с привличащи вниманието анимации с добра производителност. Можете също да имате пружинен и амортизиращ ефект. Можете да разгледате Пример за управление на набиране .

person Nejat    schedule 24.04.2014
comment
Примерът за управление на набиране използва ~60% използване на процесора при преместване на плъзгача. Не е опция. - person thecoder; 24.04.2014

В крайна сметка се преместих на Allegro 4.

Той е много по-подходящ за тази задача. Много по-лек и поддържа математика с фиксирана точка.

person thecoder    schedule 14.07.2014