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\$
9
  • \$\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
    Commented Nov 6, 2014 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
    Commented Nov 6, 2014 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
    Commented Nov 6, 2014 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
    Commented Nov 6, 2014 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ᛃ
    Commented Nov 6, 2014 at 22:56

1 Answer 1

Reset to default
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\$
6
  • \$\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
    Commented Nov 6, 2014 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
    Commented Nov 6, 2014 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
    Commented Nov 6, 2014 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 in Orbit
    Commented Nov 6, 2014 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\$
    – geometrian
    Commented Nov 7, 2014 at 5:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .