OGRE frameRenderingQueued方法分析
来源:互联网 发布:飞鸽网络打印机 编辑:程序博客网 时间:2024/06/05 17:47
11
1.
2.
3.
这个过程很清晰,不再多说,并没有发现frameRenderingQueued调用。接着进入_updateAllRenderTargets,这个方法也做三件事。
1.
2.
3.
由此可见,frameRenderingQueued的调用时机是在frameStarted的后面,frameEnded的前面,而且在frameStarted和frameRenderingQueued还有一个更新所有渲染目标(不翻转),经过这样分析,调用关系就清楚了,简单归纳为下列五步:
1.
2.
3.
4.
5.
通过分析后已经可以看明白调用过程了,接下来进一步说说,为什么要加入frameRenderingQueued呢,一个方法的加入总归是有原因的,大家都很忙,Ogre团队不会浪费时间加一个没用的东西。首先看原来用的frameStarted,可以看到frameStarted的调用时机是最靠前的,接下来是更新所有渲染目标(不翻转),然后是frameRenderingQueued。可以看到,frameStarted和frameRenderingQueued的主要区别就在于更新所有渲染目标前调用还是后调用。如果把逻辑放在frameStarted中,那么更新所有渲染目标这个操作必然在其之后;反之把逻辑放在frameRenderingQueued中,则逻辑执行在更新所有渲染目标之后,那为什么要放在后面,而不是放在前面呢?原因在于渲染是由GPU来完成的,更新所有渲染目标这个操作返回时,GPU需要一定的时间来完成当前的渲染,这样当执行frameRenderingQueued时,相当于逻辑和GPU在并行计算,CPU也没有闲着,这样就提高了效率,效率很重要,不是么,^_^。
这里还需要指出的一点是,由于frameRenderingQueued执行时,GPU已经在渲染上一帧内容了,因此写在frameRenderingQueued里的逻辑将在下一帧才能够在渲染中体现出来,一般来说,这个问题是无关紧要的。
- OGRE frameRenderingQueued方法分析
- Ogre新加FrameListener.frameRenderingQueued分析
- Ogre新加FrameListener.frameRenderingQueued分析
- Ogre源码剖析 -FrameListener.frameRenderingQueued
- Ogre源码剖析 -FrameListener.frameRenderingQueued
- Ogre源码剖析 -FrameListener.frameRenderingQueued
- Ogre 节点、属性方法 案例分析
- Ogre中SceneManager分析
- ogre中MaterialSystem分析
- Ogre的MaterialSystem分析
- Ogre的SceneManager分析
- OGRE全面分析三
- ogre源码分析 链接
- OGRE资源相关分析
- Ogre中SceneManager分析
- Ogre场景组织分析
- Ogre数据文件结构分析
- Ogre数据文件结构分析
- Mtk Ft6306 touch 驱动
- Windows C++ 导出和导入纯DLL函数(非COM)总结
- 【Java反射机制】_认识Class类笔记
- Linux设备驱动之HID驱动
- MVC2工程安装部署
- OGRE frameRenderingQueued方法分析
- Jmeter作为监控工具
- UML中的交互图
- rt3070 wifi arm+linux移植
- 在hadoop中利用GenericWritable来减少中间数据,加速join
- Navigation to Open/Close INV/GL/AR/AP/PO Period
- 售前工程师的成长-一个老员工的经验之谈
- ubuntu 下解压.tar.bz2文件
- 超实用的8个Linux命令行性能监测工具