完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
|
|
相关推荐
4个回答
|
|
1.依赖TCON中断,TCON终端频率就是通常我们玩游戏的时候理解的刷新率。
2.这是由软件决定的,软件控制的叫帧率,也就是产生图像的频率,图像来源可以是GPU绘制合成的,也可以是来自于VPU解码送过来的,总之,这个帧率是方案决定的。 上层不知道一帧何时开始,何时结束的,上层只需要送帧.由TCON负责同步。你送的帧不一定马上显示出来,要等TCON中断过来,才会真正显示到屏幕上的。 所以你要结合刷新率考虑帧率,帧率上去了,刷新率越大越好,帧率不能超过刷新率,图不变,同样的图刷新多少次,效果是一样的,用户感知不到,自己要有一个帧率的预估,帧率一般由片源决定的,比如30FPS,60FPS等等,帧率要小于刷新率,大于刷新率的帧率是没有意义的。 3.搞清楚这两个”率",帧率和刷新率要配合,而这个配合,是你要觉察的。 |
|
|
|
不会的,驱动内部对显示图层分配了两个buffer,你可以认为是一个pingpong buffer机制,当前写的不是正在显示的那片buffer,两个buffer依赖TCON中断进行同步。
虽然不存在花屏的问题,但是可能存在覆盖的问题,如果你送帧的帧率和TCON刷新率不匹配(太快),可能会覆盖上次还没显示出来的帧。 比如你的帧率要控制在30fps,你就需要通过某种机制保证在这个范围内送帧,误差不要太大, 这方面RTOS做的要比linux 好很多。 |
|
|
|
buffer是零拷贝,驱动内部记录是乒乓指针,buffer由应用去分配。
所以,站在这个层面看显示驱动,你不能只分配一个静态framebuffer,而是至少分配两个,然后传指针进去。 |
|
|
|
有可能的。
buffer的指针在用户手里,用户如果不加考虑随便写,可能会导致写入正在显示的画面,导致撕裂。 以播放视频的场景为例,一般video framebuffer会有很多个,比如说10个吧,所以显示那边会有一个显示帧队列,比如有三个帧,一帧是刚刚获取的,一帧是正在显示的,还有一帧是刚刚显示完的,通过软件控制时序,是可以保证常态化如此的,你可以理解它有点类似于网络中的滑动窗口,队列中永远都有一个待显示帧,当前帧和已显示帧。并且已显示帧需要回帧后,解锁才能再次写入数据,这样就可以避免撕裂的情况。 如果是UI framebuffer,也可以参考类似的做法,多创建几个帧,并且创建回帧机制。 严谨的做法可能要用到fence机制了,如果你们有 tina sdk,在disp2驱动下有个composoer_init函数,里面的逻辑就是实现fence的,安卓上用的就是这套机制。 所以,你说的情况是存在的,但是如果你隔足够安全的时间去送帧,自然每次都是成功的,这也是melis上的做法。 |
|
|
|
只有小组成员才能发言,加入小组>>
983 浏览 0 评论
709 浏览 0 评论
832 浏览 0 评论
全志T113双核异构处理器的使用基于Tina Linux5.0——RTOS系统定制开发
1519 浏览 0 评论
全志T113双核异构处理器的使用基于Tina Linux5.0——RTOS编译开发说明
938 浏览 0 评论
全志V85x硬件设计大赛作品精选第二期,快来Pick你心目中的最佳方案
95676浏览 3评论
2883浏览 1评论
Yuzuki Lizard 全志V851S开发板 –移植 QT5.12.9教程
16456浏览 1评论
关于全志T113开发板接7寸LCD屏幕显示异常问题的解决方案
1176浏览 1评论
泰酷辣!基于全志R818的开源超迷你安卓手持终端CyberPad,芒果派惊喜之作
3301浏览 1评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-1-22 14:59 , Processed in 0.502755 second(s), Total 47, Slave 42 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号