【问题标题】:in opengl es 2 how do I free up a texture (ios hard crash)在opengl es 2中我如何释放纹理(ios硬崩溃)
【发布时间】:2013-08-20 05:16:04
【问题描述】:

我有一个需要使用大量大纹理的 iOS opengl es 2.0 应用程序。理想情况下为 4096x4096。我有一个结构数组,其中包含有关纹理的所有信息,并且由于我需要使用每一个,我 glGenTextures 一个新的纹理 id 并在那里加载图像,释放 uiimage 等。一切都很好。

我的应用为 UI、图像处理等使用了一堆纹理。我使用的 15 个纹理中大约有 4-5 个是 4k x 4k。休息更小。然后这些按需加载的纹理也是 4k。

在加载大约 4 到 5 天时,应用会严重崩溃。没有控制台或调试。只是在尝试加载下一个纹理的过程中退出跳板。

我没有内存泄漏 - 我运行了仪器。我正在使用ARC。我可以从组织者那里发布崩溃报告,但它没有太多信息。只是我应用的 rpages 是 170504。

我可以发布图像加载代码,但它与我多年来在所有应用中使用的代码相同。新事物是大力推动系统并尝试加载那么多大纹理。

Q1:谁有使用大量大型纹理的经验?

所以我决定我必须在 1024x1024 上预览 res 的东西,然后在 4096 上做最终的 res 的东西。现在 1k 图像正在根据需要加载并保持加载状态。 4k 图像将一次全部加载到要使用的同一纹理中,然后继续使用下一个。

我在我的图像加载器中写入了一个预览参数,当设置它时,它会在加载过程中缩小图像以适应 1024。现在,我可以“整天”添加纹理,而不是在 4 日或 5 日崩溃。我的猜测是我可以做 16 倍的工作。但我一次只需要20-30个。 (仅限!)到目前为止,我已经尝试了 20 次,没有出现内存警告或崩溃。

但是.. 如果应用程序继续运行,因为我的纹理以唯一的纹理 id 加载,在某些时候我会遇到需要卸载一个不再需要加载下一个的地方。这可能很简单,但是....

Q2:当我不再需要某个纹理 id 的纹理时,如何释放它?

Q3:内存警告会告诉我我需要释放 open gl 纹理吗?

Q4:PVR芯片上没有加载纹理吗?它们是否或如何占用手机的内存?

谢谢!

【问题讨论】:

    标签: ios opengl-es crash textures


    【解决方案1】:

    去除纹理: 您必须在主线程中使用此 GL 调用。

    glDeleteTextures(1, &_texture);

    内存警告是对应用程序的一般调用。它不会给你具体的信息。如果不再需要它们,最好从内存中删除不需要的纹理。例如:当用户移动到游戏内屏幕时,我们通常会删除菜单中使用的纹理,当用户导航回来时,它们会再次重新加载。这比等待系统调用内存警告要容易得多。

    当您加载 PNG 图像时,数据会被解压缩并以每像素颜色数组的形式存储为原始数据。尽管图像中的内容/颜色如何,1K 纹理将使用 4 mb。 PVR是一个硬件解压芯片,当图像被GPU使用时会实时解压,你看到的图像文件大小就是它使用的内存。

    【讨论】:

    • 谢谢。这就是我一直在寻找的。我知道这会很简单。当你自学 opengl 时,很容易错过一些小东西。
    • 我能问一下吗.. 你说当你加载 PNG 时,数据是“解压缩并存储原始数据”.. 但是你说 PVR 是一个硬件解压芯片,它可以实时解压图像..那么它是将其存储在压缩或解压缩的芯片中吗?在不使用 pvr 格式的情况下,有没有办法将其压缩存储在芯片上以提供更多空间?或者这是唯一的方法?苹果声称可能并不总是支持 pvr 格式,所以我避免了它。你会用吗?
    • 我们通常不使用 PVR,但计划从 PNG 迁移到 PVR。 PVR文件被加载并存储在内存中,直接发送到GPU,GPU在使用时解压文件。所以使用的内存只是文件大小。解压缩发生在 GPU 本身中。我知道,PNG 和 PVR 是两种很好的格式。 Apple 的设备使用 PVR 压缩文件,据我所知不支持其他压缩格式。
    • 但是当我们加载 png 或 jpg.. 是否在内部将其转换为 PVR?将 PVR 用作文件类型会获得任何内存优势吗?
    • 使用 PVR,是的,您将获得内存收益。 Png 不会转换为 pvr。 Pvr 转换非常耗时。当您加载 png 时,它会存储为未压缩的像素信息
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-08-10
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多