添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

各位高手 不知道各位有没有在cocos2dx下开发游戏有过这样的一个内存问题
在加载纹理时会用到opengl es 里 glTexImage2D 然后释放纹理时会调用 glDeleteTextures
但是在调用释放函数时内存并没有立即释放!本人查询各大资料后 得出的原因是调用glDeleteTextures
函数后 是由opengl es来决定是否释放该内存的 实际验证过后的确如此!但是问题就来了 由于由opengl
来决定是否释放内存 那么当程序里的确不想用该纹理时 却占用了大量内存,显得非常不智能!所以求高手
指导,有没有调用glDeleteTextures 后内存能立即释放出来!! 在线等!!!

The problem is that “later” is usually defined as some form of glDraw* command, glEnd, glFlush/Finish, or a swap buffer command. Or something of that nature. If all you do is sit in a loop and create/delete textures, the driver may not get the chance to actually delete anything.

Try making your test less artificial. Add a glFinish after each glDeleteTextures. If that doesn’t work, draw stuff between deletions.

在最后调用glFinish或者glFulsh试试

这个问题我前天也遇到了,不过很幸运,我解决了.网上说的那些什么加glFlush()或者glFinish()都不管用.天空盒的纹理一直释放不掉,释放纹理的函数也不会返回任何错误信息,纹理序列号也回收了.既然在场景结束时释放内存释放不掉,那我就试试创建纹理后就释放看行不行,结果创建后立即释放是能够释放掉的,然后我就试试10秒以后再释放看看,结果还是能释放,再放到场景结束时统一释放资源处就无法释放了.好了,问题到现在就很明了了.然后我就想着能不能在下一个场景中释放上一个场景的天空盒,结果是可以释放的.然后觉得这样虽然能够释放,但是好像不太合逻辑,于是将这个功能整合到纹理管理器中.由于天空盒的贴图比较大,每张都是1MB的,.6张就是6MB,还是占了比较大的内存的.所以我在纹理管理器的释放纹理中作了判断,如果要释放的纹理大于等于1MB,则不会立即释放,而是放到另外一个延迟释放的列表中,然后在场景的循环中一直调用纹理管理器的释放延迟列表中的纹理.只要有延迟释放的纹理就立即释放掉,并且每调一次函数最多只能释放3张,避免内存操作过多.
以下是我猜想的释放不掉的原因.opengl会有一套自己的内存管理,当内存操作非常频繁时,opengl遇到大块的内存操作就会推迟下去,在一个合适的时间来对内存进行释放.比如纹理,当在释放内存次数过多时,如果要让opengl释放大于等于1MB(只是猜测)的纹理时,并不会立即对内存进行释放,而是要推迟到后面来进行.但是不知道为什么,原本应该推迟释放的内存一直没有被释放,并且没有返回任何的错误信息,纹理的序列号也被回收了,就造成了内存的泄漏,而且泄漏非常严重.所以在使用opengl的时候最好能够自己判断一下纹理应该在什么时候释放.

貌似碰到同样的问题, 每次纹理清理内存也有大幅度的降低,未使用纹理正常清理。但是总是有部分增长
gfxAllocateTextureLevel 和 glsmLoadTextureLevelBuffer,大部分都是这两种相关的。 有人已经确定原因了么

以上都非真机测试, 后来在真机release情况下查看内存变化正常,over。