File extension for best performance

[lol123]

texture.loadFromFile("image.*")
Which file extension (*.png, *.bmp, etc.) should I use to achieve the best performance?

[G.]

Once it's loaded it doesn't matter.
If you're talking about loading time, I have no idea if there is a significant difference. You can try and tell us. :p

[lol123]

Thanks! That's what i needed

[wintertime]

BMP is a bloated format without compression making the files much larger, that also comes in about half a dozen different flavours that are sometimes incompatible.
A HDD is one of the slowest parts inside a computer and the larger the file the more it needs to do and the longer it takes usually.

[didii]

If you're talking about loading time, I have no idea if there is a significant difference. You can try and tell us. :p

A GPU needs some warm-up time, the very first texture loaded onto the GPU will almost always take longer than any following textures to load. That being said, I tested it with a 4000x4000 plain white image of all 3 supported file types. Each loaded up 20x times in a row and took the avarage time. I've warmed up the GPU by loading the image 3 times in a row. The results:

Code: [Select]

PNG time: 999.297ms
JPG time: 995.337ms
BMP time: 988.297ms
This is of course in the notion that a GPU has no memory and indeed loads the image again completely. I did not find an SFML-function to remove a texture from the GPU so I assumed that it got deleted automatically when the sf::Texture is destroyed. Also The results all seem to change every time I run it by about 10ms no matter how many tests I run. I assume it's due to the randomness of my GPU or due to the accuracy of <chrono>.

Here is the code I used. Feel free to test it on your own GPU.

[zsbzsb]

Sending textures to the GPU will always be the same no matter what format you use. Reason is because once an image is loaded it uses the same RGBA format to be loaded on the GPU.

What you should instead test is the loading of each format into a sf::Image. And do it more than 20 times, 20 times is no where close enough times to be accurate.

[didii]

Sending textures to the GPU will always be the same no matter what format you use. Reason is because once an image is loaded it uses the same RGBA format to be loaded on the GPU.

Aren't you contradicting yourself?
Sending textures to the GPU = when they are being loaded
once an image is loaded = when it has finished loading

What you should instead test is the loading of each format into a sf::Image. And do it more than 20 times, 20 times is no where close enough times to be accurate.

I included the code specifically for people who were not satisfied with my results Feel free to use/adapt it.
Read the tutorial about Sprites and textures for the difference between a sf::Texture and an sf::Image. Since the OP talks about loading textures I assumed it was about loading an image file onto the GPU thus I used sf::Texture.

[FRex]

1. Open file #this step is always same
2. Load + decode image into RAM as 32 RGBA #this step differs
3. Load image into GPU as 32 RGBA #this step is always same

Only part that changes along the file format is (in theory) the second one. So only it should be benchmarked in a file format benchmark, what is worse is  that disc and GPU are quirky and don't actually have deterministic, consistent times so the results might be wrong if you include loading the file and uploading to GPU.

This benchmark makes no sense in the first place, just use whatever you feel comfortable with(I suggest png, because they are lossless, easy to edit and open in other programs, portable and common, just don't use bmp - they are too big for anything over few images) , if it's too slow there is little chance other format will be faster enough to make a difference.

[Nexus]

Aren't you contradicting yourself?
Sending textures to the GPU = when they are being loaded
once an image is loaded = when it has finished loading

He means loading from files on the hard disk.

In SFML, there are two steps: sf::Image loads an image from a file (or memory location or stream), and sf::Texture loads the data from an sf::Image. sf::Texture always uses sf::Image. That implies that, in order to find performance differences in the image formats, it suffices to look at sf::Image.

Comparing the time to load data from RAM to video memory is pointless, as it will already be uncompressed at that time.

[wintertime]

What you should instead test is the loading of each format into a sf::Image. And do it more than 20 times, 20 times is no where close enough times to be accurate.

That wouldn't be a good benchmark either, because no game would redundantly load the same image 20 times and the 2nd to 20th time would be much faster than the 1st when the OS keeps it in its file cache.
You would need to reboot, time a program loading the image once, reboot again, time it once,...
Or make many copies of the image on the disk (and be sure its not just hardlinked), reboot once, hope the OS is not prefetching them for some reason like them having been used that day already and then time loading all those image files once.

[zsbzsb]

This whole discussion is pointless, because the difference is so small.

That wouldn't be a good benchmark either, because no game would redundantly load the same image 20 times and the 2nd to 20th time would be much faster than the 1st when the OS keeps it in its file cache.

I thought we were trying to compare the time that each image format takes to decompress into RBGA data. So why worry about the time it actually takes to load the actual files from the HDD (this totally depends on the file size).

The best way to benchmark decompression of different image formats is to load the entire compressed file into memory and then time how long it takes to load several hundred sf::Images from that compressed file. And that would be as close to measuring the decompress time as you can get 

[wintertime]

If it was true that only the decompression counts then everyone would still use bmp or other space wasting formats, but that wont help you if it slows down when it needs longer to load a much larger amount of the data from disk. Therefore only counting the full time with everything included and measured under the same circumstances as in actual use would give a useful result.
Though if it really matters people would directly load dxt/s3tc/bc/... and upload it into the gpu without decoding.

[didii]

Yup, I was wrong again... Thanks for correcting me, I think I'll never stop learning new stuff in C++