- 主题:qt 可以在 framebuffer 跑起来
我一直在arm9上跑framebuffer上的Qt. 不过Qt启动实在是太慢了, linux启动可以控制
在1~2秒, Qt大概要10来秒, 因为这个问题, 搞得产品要加个电池做休眠用.
【 在 hgoldfish 的大作中提到: 】
: 拿来做超精简的 linux 很爽啊。一个 linux 内核加上一个 qt 程序，链接到 ulibc, 再加个 busybox-static！
: 另外再考虑一种场景，我是不是可以用这个东东来实现一个 xwindow，给其它应用跑，哈哈。
--
FROM 113.118.101.*
IO虽然是慢了点(随机读25us的SLC), 但是程序才1MB多, 主任务有做延时启动, 主要还
是Qt的动态链接库都挺大的, serialport, serialbus, bluetooth, network一大堆都用
到了.
【 在 hgoldfish 的大作中提到: 】
: 不应该这么慢啊。你们的存储 IO 速度很慢吗？
: 或者你们把太多的东西放到 Qt 的主线程里面加载了？
--
FROM 113.118.101.*
有点差别但不明显, 也慢. 不过ctrl+c关闭后再次启动会快不少
【 在 hgoldfish 的大作中提到: 】
: 你先写个 hello world 看看是不是也慢。
--
FROM 113.118.101.*
现在没环境, 没得试. 我的是300MHz的ARM926EJS, 不一定有你的三星手机好, 10几年前
的手机就是Cortex架构了
【 在 hgoldfish 的大作中提到: 】
: 我也用 qtcore 写 arm 程序，之前是跑在一台很古老的三星手机上面。性能只有普通台式机的 5% 非常烂。但也不至于启动十几秒啊。你删掉几个 qt 模块看看？是哪个模块加载慢呢？
--
FROM 113.118.101.*
就最简单的arial字体, 没中文的, 很小, 我估计不用字体应该也差不多
用到的libQtxxx.so加起来有20多MB, 可能是这个拖累了
【 在 roy 的大作中提到: 】
: 会不会和加载的字体文件有关
--
修改:jesce FROM 113.118.101.*
FROM 113.118.101.*
linuxfb的显示是基于RAM的, 只要你的RAM大于屏幕的宽*高*位深/8就行 (当然还得有保
证程序运行的那部分). 后两者应该都需要支持OpenGL之类的图像引擎, 但是个人感觉图
像引擎这东西没有技术支持很难搞得好.
【 在 zhaoxx 的大作中提到: 】
: 请教下 linuxfb /xcb/ wayland 对资源的需求差异有多大呢？
: #发自zSMTH@jet-shot
--
FROM 113.118.101.*
主要是RAM是片上集成的, 容量问题, preload没法用. 静态编译不能走LGPL. prelink其
实可以, 但是一开始测了下没搞通, 然后应用程序会OTA更新, 估计会行不通.
想问一下, 如果一个Qt程序首次启动很慢, 关闭后第二次启动就快多了, 这是生成什么
东西保存在系统里了吗 (linux环境), 如果可以的话, 可以固化这部分的东西来加快速
度.
【 在 cavendish 的大作中提到: 】
: 裁剪，preload，静态编译，等等
:
https://stackoverflow.com/questions/40901894/qt-embedded-how-to-load-a-library-before-running-the-program--
FROM 113.118.101.*
速度啊, 比如画一条斜线, 没有图形加速, 就要CPU计算n次画点的位置再移动到对应的
内存地址去赋值. 有图形加速你只要给起始坐标和终点坐标HW帮你完成了.
【 在 zhaoxx 的大作中提到: 】
: 好的，谢谢指教。
: 效率最差指的具体哪方面？比如另一个回帖写的内存使用？
: #发自zSMTH@jet-shot
: ...................
--
FROM 113.118.101.*