回复: 关于嵌入式板上QT的update耗费
#11 回 九重水 的帖子 [ghldh94 06-26 17:13]
九重水:这种需求也可以理解的（不过说句实话，人眼的反应时间20ms不需要这么短时间，25帧40ms是可以的）。
我前面也说过方法，你需要精确计算刷新区域（就一个圆，相信很快可以计算出来），这样情况下，你将需要刷新的区域大为缩小，CPU处理起来就简单得多！ (2019-06-26 17:09)
若果是和绘制区域大小有关我也就不纠结了，实际是我不做绘制也一样的delay。
#12 [ghldh94 06-26 17:20]
只要调用到update,不管paintEvent中有无绘图工作，都一样delay的。 嗯，40ms勉强也能接受吧。可是T7都没能做到，目前看最少是100多。对了，我还尝试了把timer 放到子线程中执行。这样qDebug打出来的时间是精确了，没有delay，意味着update也是按照我的20ms 调用。但实际跑起来，它是把7~8个update 合并执行一次paintEvent (QT是这样的机制)。 所以这种方式也是不行。归结起来，是一个奇怪的现象：只要CPU占用达到10%多，就上不去，到不了20%。 同时时钟就delay执行任务。
#13 回 ghldh94 的帖子 [九重水 06-26 21:51]
ghldh94:只要调用到update , 不管paintEvent中有无绘图工作，都一样delay的。 嗯，40ms勉强也能接受吧。可是T7都没能做到，目前看最少是100多。对了，我还尝试了把timer 放到子线程中执行。这样qDebug打出来的时间是精确了，没有delay，意味着update也是按照我的20m .. (2019-06-26 17:20)
就一个仪表盘而已，100MS刷新频率根本就不碍事。
如果非得跟游戏一样刷新，全职H7应该有GPU吧，直接弄个窗口用GPU给仪表盘得了。
不过，老刘说他做过很多，你问一下他怎么用一个CPU干所有活，包括10ms刷新这么变态的事，哈哈。
#14 回 九重水 的帖子 [ghldh94 06-27 09:39]
九重水:就一个仪表盘而已，100MS刷新频率根本就不碍事。
如果非得跟游戏一样刷新，全职H7应该有GPU吧，直接弄个窗口用GPU给仪表盘得了。
不过，老刘说他做过很多，你问一下他怎么用一个CPU干所有活，包括10ms刷新这么变态的事，哈哈。
....... (2019-06-26 21:51)
嗯嗯，还是感谢你多次帮忙回复。权当个讨论。
昨天我有回头继续去尝试。 其实问题的关键不是100ms或10ms（这个是测试，实际会慢一些） ，要知道，这个数据是在test中做的，实际做项目，那肯定要绘图的，跑得会慢更多，非常多。我是指这样的CPU效率肯定不对，实际贴图出来成秒表了快。用top命令去分析，CPU最多也只占用18%，都上不去20%，明明还有很大余地，就是没用到。用GPU绘图我也想到了。但要去研究下，麻烦多了，有些动画我担心做不了。
#15 [ghldh94 09-02 15:37]
回来结题了，希望给遇到同类问题的朋友参考：
1、用QOpenGlWidget 取代QWidget， 速度快了N倍。 这是本质上的改变。
2、速度慢的根源是CPU 读取图片文件慢，改成大图片预先加载进内存，速度快一截，这是第二关键；
3、接着第2点，发现scaled 函数、SmoothTransformation 变换大小，很耗时，所以同样 预先处理好。另外drawpie 画扇形，速度简直龟爬，这个函数只能在电脑用用了，嵌入式板子改用其它方式吧。
4、IO流~。 我发现即使qDebug 打印都是有影响的， 更别说操作文件之类的了。所以要么在多线程中操作，主线程打印我都删掉了。
以上，基本解决了我遇到的问题。 不过缺点也有，占用内存变大了~还有启动速度慢了一丢丢~