Slow adding textures to a vector

[starkhorn]

Hey Folks,

So I have around 45 png files that I need to load in when the game first starts and I want to store in a vector.

During the initial process of the game I load in the textures using the below. I only call this once during the init phase of the game.

sf::Time time = gameClock.getElapsedTime();
sf::Texture texture;
vector<sf::Texture> regionTextureList;
cout << "Start time SFML2.2:- " << time.asMilliseconds() << endl;

        for (int i = 0; i < regionListPtr->size(); i++)
        {
                texture.loadFromFile(regionListPtr->at(i).getRegionImageFileName());
                texture.setSmooth(true);
                regionTextureList.push_back(texture);
        }

 

Strangely the loadFromFile is not the slowest part. I've found that the push_back onto the vector as the slowest part.

The PNG files are 5760 x 3240 so obviously quite large. However the content isn't large in size 99kb.  See below an example.



So when I say slow, I meaning minutes. My graphics card isn't the greatest AM Radeon HD8490 4818MB (when I going into advanced setting of my screen resolution page in windows7). My PC has tons of RAM though 32GB.

Whilst I can obviously scale down the png, load them in and scale up, I do find the png a bit sharper/nicer (especially scaling up) when I load them as 5760 X 3240, as opposed to loading them in as 1920 x 1080 and scaling up by 3.

I am wondering if there is a more efficient way to store very large textures? I thought a vector was the way to go in c++ but wondering if there is a better method? Or am I just limited by my rubbish graphics card?

[Laurent]

The initial set of textures is already 3.35 GB to upload on the graphics card, which is huge. Then you're making at least one copy of each texture, doubling (temporarily) this amount. Then the vector itself will reallocate its internal memory many times while it grows. In the end, you upload approximately 10 GB of texture data to your graphics card. Not counting the texture destructions, which I assume are not significant compared to the data upload.

What you do will always be "slow", but you can at least remove all the unnecessary copies:
- call loadFromFile on the texture that is stored in the container, not on the one that will get copied into it
- pre-allocate all the elements sothat the vector never has to grow; or use another container such as std::list

vector<sf::Texture> regionTextureList;
regionTextureList.resize(regionListPtr->size());

    for (int i = 0; i < regionListPtr->size(); i++)
    {
        regionTextureList[i].loadFromFile(regionListPtr->at(i).getRegionImageFileName());
        regionTextureList[i].setSmooth(true);
    }

[starkhorn]

Hi Laurent,

Thanks for the swift reply and suggestion. I will try them out.

I am confused as to where the 3.35GB figure came from? There are 45 png with each of them being 99kb in size. (98.5 KB (100,958 bytes))

Obviously 45 * 98.5kb is nowhere near 3.35GB, so I am confused as to how I am uploading so much data to the graphics card. Clearly I thought I was only uploading 45 * 98.5kb to it.

[Laurent]

99 kB is the size of the image file, encoded as PNG (with RLE compression). This is totally unrelated to what the image will take after it is loaded in memory. SFML decodes this file to RAM as a RGBA array, and uploads this array to the graphics card through a texture. So the size in VRAM is 5760 x 3240 x 4.

[starkhorn]

99 kB is the size of the image file, encoded as PNG (with RLE compression). This is totally unrelated to what the image will take after it is loaded in memory. SFML decodes this file to RAM as a RGBA array, and uploads this array to the graphics card through a texture. So the size in VRAM is 5760 x 3240 x 4.

Oh.....wow....obviously I had no idea, so thank you so much for explaining. I obviously changes things around to avoid loading so much onto the graphics card.