Long loading times on large PNG file using C++, OpenGL & SOIL

Question

I'm currently optimising a C++ OpenGL game, and I've noticed something slightly odd about texture loading.

I've got a number of PNG files I load as textures and use as spritesheets; these are generally 512px or 1024px, with one 2048px. I use SOIL (www.lonesock.net/soil.html) to load the PNGs then bind them to a custom OpenGL texture class.

I've put some primitive code in to measure how long it takes to load these PNG files as textures measured in ticks. Generally speaking the load times are:

512px PNG: 100 - 150 ticks 1024px PNG: 400 - 500 ticks 2048px PNG: 1800 - 2000 ticks

Now I recognise that not all image files are created equally, but these don't quite seem to add up with what I understand in terms of texture files. There's not much to be gained by using fewer larger textures compared to more smaller textures, and often there's no gain for that 2048px PNG compared to four 1024px.

My question is, are these (relative) load times normal? Is there something I'm missing when it comes to loading textures with SOIL?

Note that my question isn't 'how can I generically speed up image loading times' (I may at a later date convert these to more OpenGL friendly file formats like DDS), but more is there a pattern I should / shouldn't be using to optimise this?

Thanks

Nathan

Answer 1

A 2048x2048 image is 4 times as large as a 1024x1024 image which in turn is 4 times as large as a 512x512 image. You're getting a loading time that increases linearly with image size, which is the behaviour you should expect.

PNG, however, is not the best format for storing game graphics which must be sent to an API like OpenGL. While PNG files are small and can be read off disk quickly enough, they are slow to decompress in memory, and because no graphics hardware has native support for PNGs, they must be decompressed before the graphics hardware can use them.

Despite this there are possibly areas where you can optimise further. For example, if you're using GL_RGB/GL_UNSIGNED_BYTE or GL_RGBA/GL_UNSIGNED_BYTE for your format/type parameters to glTexImage, you should consider switching to GL_BGRA instead (and one some hardware use GL_UNSIGNED_INT_8_8_8_8_REV instead of GL_UNSIGNED_BYTE): using these you'll be telling OpenGL that your data is already in the format and layout that the GPU prefers, and so your driver will probably load the data directly rather than doing it's own intermediate format conversion.

As an alternative to PNG, DDS files with DXT compression (patent expires 2nd October 2017, but is not normally a problem since GPU vendors have licensed it anyway) require between one-quarter and one-eighth the storage of an uncompressed image and are natively supported by most GPUs. Loading can be as fast as memory-mapping a file, reading some header data, then sending some pointers directly through glTexImage. No format conversions, no intermediate buffers, no heavy computation: what's on disk is the same as what's used by the GPU. DXT compression is lossy, however.

Finally, you appear to be misunderstanding the purpose of "using fewer larger textures compared to more smaller textures" - it's absolutely nothing to do with load times, but instead is to allow for better draw call batching and fewer state changes at runtime.

Answer 2

SOIL is a little bit buggy and some things don't load at all or will take an inordinate amount of time to load. Especially large png files. SOIL is a little old and just doesn't seem to like some of the newer formats and encodings all that much.

If I get a photo from a third party I always resave it as a lossless jpeg or similar file with no thumbnails or comments in it. Your results don't seem too terrible but doing this will probably save you some headache down the road.

Probably tiff files are the easiest for it to deal with, but I don't like them too much because windows doesn't know how to deal with them ie it won't give me a preview through windows explorer.

Answer 3

Bit of an old question but I've actually discovered what the problem here was. My instinct that basic loading of 2D textures was taking a long time was correct for the following reason:

When using the SOIL library I used the flags "SOIL_FLAG_MIPMAPS" and "SOIL_FLAG_COMPRESS_TO_DXT". Removing the "SOIL_FLAG_MIPMAPS" (no real need in a fixed camera 2D game) reduced loading time by a third, and removing "SOIL_FLAG_COMPRESS_TO_DXT" reduced this by a factor of about 50 (i.e. 1000 game ticks down to 20 game ticks), whether using PNG or DDS source file format. I'm yet to fully determine the benefits of the compress to dxt flag, there doesn't appear to be any change in memory, but I'll continue to experiment.