6
\$\begingroup\$

I am creating an Android game using libGDX. When I load my nine images it takes 200 MB of RAM. But the images are 10 to 17 KB each. Why the discrepancy? Here is where I create textures from those images:

public static HashMap<String, Texture> ground = new HashMap<String, Texture>();
for (int i = 1; i < 10; i++) {
  ground.put(
  "ground" + i,
    new Texture(Gdx.files.internal("groundImages/ground" + i + ".png"))
  );
}
\$\endgroup\$
  • \$\begingroup\$ How compressed are your PNG files? I might be wrong but I was under the impression that loaded textures would be uncompressed. \$\endgroup\$ – Kurley Nov 6 '14 at 14:23
  • \$\begingroup\$ png8 , when I dispose textures everything is good with ram but the sprites from that textures shows black squares . \$\endgroup\$ – Vahe Muradyan Nov 6 '14 at 14:39
  • \$\begingroup\$ If you dispose of your textures it's probably not unexpected that you can't use them anymore. Do you know what the uncompressed size of your images are? They may be small files when compressed as PNG, but when uncompressed in memory they probably take up more space. \$\endgroup\$ – Kurley Nov 6 '14 at 15:34
  • 3
    \$\begingroup\$ If your images are RGBA8888 then the uncompressed size is usually width x height x 4 = size in bytes. \$\endgroup\$ – Kurley Nov 6 '14 at 15:41
  • 1
    \$\begingroup\$ Are you generating mipmaps ? If so be sure to consider the memory taken by the complete mipmap chains for 2500x1500 textures. \$\endgroup\$ – LJᛃ Nov 6 '14 at 22:56
10
\$\begingroup\$

The PNG files are small because they are compressed. When the images are loaded into memory they are uncompressed and therefore take up more space.

\$\endgroup\$
  • \$\begingroup\$ There has to be more to it than that. 17 * 9 = 153. There's no image compression algorithm I've ever heard of that gives a > 1000:1 compression ratio! \$\endgroup\$ – Mason Wheeler Nov 6 '14 at 19:35
  • 3
    \$\begingroup\$ @MasonWheeler It's certainly possible to have a compression algorithm like that. The OP previously mentioned a 2500x1500 image at 8bpp, and the files were 10-17KB each. If we uncompressed into an 8bpp Texture, the Texture would be ~3.5MB giving us a compression ratio between 1:215 and 1:366. The fact that a 32-bit texture is used is irrelevant in that regard. \$\endgroup\$ – user39686 Nov 6 '14 at 19:53
  • 4
    \$\begingroup\$ I regularly compress 8TB to <3GB using LZW. It is driven by the data not just the algorithm. \$\endgroup\$ – If you do not know- just GIS Nov 6 '14 at 23:21
  • \$\begingroup\$ @MasonWheeler: You can trivially construct an image compression algorithm that can reduce certain four-channel inputs to four bytes (plus, say, another eight bytes for storing the original dimensions), regardless of their original size. These optimal inputs, of course, are single-colour filled images. \$\endgroup\$ – Lightness Races with Monica Nov 6 '14 at 23:29
  • \$\begingroup\$ @MasonWheeler: The best way I've found to think about compression is that a compression function maps each element in the space of strings to some other element in the space of strings. Functions usually map the "redundant-looking" ones to shorter strings (at the cost of making "less-redundant-looking" ones map to longer strings). There's no reason a particular string with 10 billion characters can't map to a string with a single byte. \$\endgroup\$ – imallett Nov 7 '14 at 5:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.