Making all types of Textures managed, cache Pixmaps

Discussions for core devs and contributors. Read only for normal forum members to keep the noise low

Making all types of Textures managed, cache Pixmaps

Postby mzechner » Mon Feb 25, 2013 6:40 pm

So i was thinking about this for a long time. There are two issues/inconsistencies:

  • Textures get their pixels from TextureData instances.
  • The two most common TextureData implementations used are FileTextureData and PixmapTextureData
  • FileTextureData loads a Pixmap from a file, hands it to a Texture, then disposes it. If the context is lost, the file has to be reloaded, which is slow
  • Textures constructed from a FileTextureData instance can not be drawn to, not a big issue, but still not nice.
  • PixmapTextureData is not managed. If the context is lost, a Texture has to be recreated. If the Texture is disposed, the Pixmap stays allocated.

I want to potentially change this:

  • FileTextureData will cache the Pixmap in memory. On reload due to context loss, the Pixmap data is readily available and doesn't have to be fetched from disc. Downside: more RAM will be consumed by the app, each image has a copy in RAM and another one in VRAM. With this change, drawing to the texture would be supported as well.
  • PixmapTextureData should become managed by default. Constructing a Texture from a Pixmap would thus mean the Texture manages the life-cycle of the Pixmap. If the Texture gets disposed, so is the Pixmap. The Texture would also be restored automatically when the context is lost.

Both issues are really only relevant on Android, context loss does not happen on the other platforms (well, it could with WebGL, but we don't care about that in the real-world).

Thoughts? What i don't want is a switch. One can currently work around this issue by creating their own TextureData implementation. The drawback is that the it's a bit cumbersome to use with the AssetManager, e.g. you'd have to pass a TextureData to the TextureLoader as a parameter. For assets that have Textures as a dependency, there's no way to specify the TextureData manually, e.g. TextureAtlas.
mzechner
Site Admin
 
Posts: 4879
Joined: Sat Jul 10, 2010 3:50 pm

Re: Making all types of Textures managed, cache Pixmaps

Postby kalle_h » Mon Feb 25, 2013 9:41 pm

If this would cause more memory usage with ios backend too it would practically destroy any non trivial game with ipod 4 which only have 256Mb memory.
kalle_h
 
Posts: 666
Joined: Thu Dec 29, 2011 9:50 pm

Re: Making all types of Textures managed, cache Pixmaps

Postby mzechner » Mon Feb 25, 2013 10:20 pm

That's a very valid point, thanks for mentioning it. I think the limit for CPU side memory is way lower than 256 MB on iOS, no?
mzechner
Site Admin
 
Posts: 4879
Joined: Sat Jul 10, 2010 3:50 pm

Re: Making all types of Textures managed, cache Pixmaps

Postby kalle_h » Tue Feb 26, 2013 1:03 am

mzechner wrote:That's a very valid point, thanks for mentioning it. I think the limit for CPU side memory is way lower than 256 MB on iOS, no?


In theory there is 20Mb limit and after that operating system can shutdown you app. In reality you have lot more memory but amount of the memory vary based on device. Some listing found here. http://stackoverflow.com/questions/6044 ... iphone-sdk
Code: Select all
170-180mb of ram on devices with 512 Mb of ram total (iPhone 4, iPad 2, iPod touch 4g)
40-80mb of ram on devices that have 256 MB of ram (iPad, iPhone 3gs, iPod touch 3g)
25 MB on device with only 128MB of ram (IPhone 3g, iPhone 2g, iPod touch 1g-2g)

40-80Mb is really low and most new apps are constantly crashing with ipod4.
kalle_h
 
Posts: 666
Joined: Thu Dec 29, 2011 9:50 pm


Return to Libgdx Development

Who is online

Users browsing this forum: No registered users and 1 guest