效率。。。OverlayElement。。。

本文探讨了OEGUI渲染效率低下问题,分析了其与组件数量增加导致的渲染批次增加之间的关系,并对比了MyGUI的高效渲染方式。提出了改进OEGUI效率的计划,并分享了RenderBox的代码。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

      这段时间我继续在OEGUI现有基础上实现了一个RenderBox,这个RenderBox实现了渲染到纹理的效果,可以用来显示模型、画中画等一些特殊效果。但是很遗憾的是,我同时也发现,OEGUI的渲染效率实在是太低了。。这个是在我做了一个显示FPS的辅助窗口后发现的。随着组件的增加,渲染的batch也随着增加,直接导致渲染的效率低下。

      按照一般来说,ogre应该把所有的renderable按照pass归类,然后一次性渲染,也就是说假如有不同的物体使用相同的材质,渲染的批次不应该增加。但是对OverlayElement来说,不是这样。事实上,一个TextAreaOverlayElement等于一个batch,一个PanelOverlayElement等于一个batch,一个BorderPanelOverlayElement等于2个batch!这个真的是个很夸张的数字。。。因为这意味这GUI用的越多,效率越低。。。关于这个问题大家也可以运行Ogre的sample看看效果。尤其是那些下拉菜单,跳出下拉单的时候,你会发现fps会有个明显下降并且batch会有个很大提升。我一直很奇怪为什么1.7的sample运行fps明显没1.6高,现在看来找到原因了。。。

       说到效率,不得不提下mygui。这个gui的源代码真的很难看,不过貌似他渲染使用的是ogre比较底层的接口,没有使用Ogre的一般流程。他的效率很让人不可思议,在前几个比较简单的demo中,他GUI的渲染batch居然是0。。不明白他是怎么实现的。。

       今后我打算抽点时间出来提高下OEGUI的效率问题,不过不一定有时间了。

       RenderBox的代码抽空会放上来的。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值