基于Hi3516AV200/Hi3519V101的Qt绘图优化

最新推荐文章于 2026-05-25 10:09:20 发布

原创

最新推荐文章于 2026-05-25 10:09:20 发布 · 3.1k 阅读

开发板推荐：天空星STM32F407VET6开发板

超高性价比 STM32主控 | 超高主频 | 一板兼容百芯 | 比赛神器 | 沉金彩色丝印

点击查看

首先,Qt5.X移植到海思平台以及linuxfb插件的修改可以参考https://www.cnblogs.com/chay/p/10431403.html一文，本文介绍的优化过程与之相似，只是结合了具体的项目进行了分析和改进，本文思路应广泛适用于海思平台。

本文包含了大量的个人见解，如果有理解错误或者片面的地方，还请大家不吝惜时间和精力给予指正。

概述

Qt的源码中通过 Q<pluginType>Factory、Q<pluginType>Plugin 和 Q<pluginType> 这三个类实现了Qt的插件加载机制，

这个机制可用于加载特定种类的插件。Arm上Qt绘图一般会使用linuxfb来进行画图，由于Hi3519V101/Hi3516AV200的cpu主频较低和Qt绘图效率的问题，在需要绘制全屏UI或者UI刷新率较高时，会有明显地切屏和撕裂现象，在四核的Hi3559AV100平台上，切屏现象是非常不明显的。

优化点

将linux frambuffer替换成Hisilicon Framebuffer，并使用TDE进行快速位图搬移/缩放

从qt源码可以看出，linuxfb只map出了一片绘图缓存区并没有特别的buffer管理机制，这意味着你的画图过程将会全程展现在使用者面前，在高性能的cpu下这个过程可能并不明显，但是在Hi3519V101/Hi3516AV200平台下就会出现很明显的切屏（理论上大核主频也有1G了，这里我不是很理解，难道是Qt本身的绘图机制效率低了？）。

    uchar *data = (unsigned char *)mmap(0, mMmap.size, PROT_READ | PROT_WRITE, MAP_SHARED, mFbFd, 0);
    if ((long)data == -1) {
        qErrnoWarning(errno, "Failed to mmap framebuffer");
        return false;
    }

    mMmap.offset = geometry.y() * mBytesPerLine + geometry.x() * mDepth / 8;
    mMmap.data = data + mMmap.offset;

    QFbScreen::initializeCompositor();
    mFbScreenImage = QImage(mMmap.data, geometry.width(), geometry.height(), mBytesPerLine, mFormat);

下面贴下使用hifb的特性，摘自海思的《HIFB开发指南》

HiFB 支持以下的 Linux Framebuffer 标准功能：
将物理显存映射（或解除映射）到虚拟内存空间。
像操作普通文件一样操作物理显存。
设置硬件显示分辨率和象素格式，每个叠加图形层的支持的最大分辨率和象素格
式可以通过支持能力接口获取。
从物理显存的任何位置进行读、写、显示等操作。
在叠加图形层支持索引格式的情况下，支持设置和获取 256 色的调色板。
HiFB 增加以下的扩展功能：
设置和获取叠加图形层的 Alpha 值。
设置和获取叠加图形层的 colorke