图片读到内存。
50张2000 * 1500的图 读到内存
每张图大概5M 左右
刚才猛然发现
读完图之后程勋 内存飙到 1G 多
太诡异了。
就是用了CGUI 的 ImagesetManager 装入图片 然后不知道被CEGUI 内部怎么处理成了 文件流
然后用dx 的D3DXCreateTextureFromFileInMemoryEx 装载纹理 。
这个ImagesetManager 也太郁闷了吧? 还是我的理解错误?
有熟悉CEGUI 的吗?
[解决办法]
1 关于50个图,占用1G内存的问题
2000*1500 在d3d当中转换成为2^N边长的texture内存
大小应该是: 2K × 1.5K =3M pixel * 4字节(RGBA)/ pixel = 12M
如果再做成Mipmap的话,占用的量就又多出了1/2了, 那就是12+6=18M了
你说的5M,是jpg之类的压缩图片吧
18M×50 = 900M
再加上不确定的原始50×5M=250M 总数》1G了
2 分批加载很有必要(今天50图,明天要是500图,5000图呢?)
你可以做个多线程管理,建立一个线程专门来在后台加载和释放, 这样可提高效率
ps. 其实directx自己也在管理这些资源, 无非效率不如你自己管理的高
[解决办法]
这么多大图片,按需分批加载很有必要……
[解决办法]
分批读取的基础上加上文件映射,速度更快。
不过我搞2D的没这样的问题
[解决办法]
你是可以预测出下几帧会读取哪个纹理阿,然后在后台线程里预加载。 长时间不用的纹理就释放了
[解决办法]
分批加载卡的原因是磁盘IO的问题,磁盘IO本来就是相对慢速的,而且一旦IO发生的时候,他会死锁当前线程时的当前线程无法进行其他操作
因此解决的办法是打破io的死锁,方法就是用多线程,单独建立一个线程在后台来管理加载进度
前台线程利用后台线程加载的图片顺序显示, 后台线程自动根据当前显示的图片的位置, 加载前后N个图片,释放前后N个图片之外的图片内存
由于加载在后台进行,虽然磁盘读取时间不变,但是线程独立会让你前台在后台读取的时候也能执行任务,使得前台看似流畅,用户体验会很好
前后台线程之间要进行通讯,确认是否加载成功,以确定是否能显示下一个或者上一组图片
如果翻到速度很快,那么也可能会因为后台加载跟不上会卡
5M不算大,一般是不会遇到这个问题的
另外从读取技巧上来说,加载磁盘文件别一个字节一个字节的读,那非常的慢
应该一次读取一定量的数据,比如2k到内存,在内存当中解析数据去,那速度相差至少十几倍呢