I've been digging through some SFML code related to images and noticed 2 things...
First, I noticed that when you load an image it leaves a local (uncompressed) copy in the myPixels vector after passing the loaded texture off to OpenGL. This is only useful if the user later calls resize, setPixel, or something similar. But I'd be willing to bet that the vast majority of times, people load an image and then never modify it which makes the uncompressed local copy extremely wasteful of memory.
So what about adding an extra bool parameter to the loading functions (with a defualt value to preserve the pubic interface, if needed) bPreserveLocalCopy or something that if false would free the local copy after the first call the Update (to preserve the thread-safeness you added) and then cause the methods that would access it to just do nothing and/or return an error?
Secondly, there is no option to use compressed textures. A big bottleneck in SFML is likely going to be re-binding textures on every draw call. (Some simple tests I ran seem to support this.) You already said that you were not planning to implement some sort of background texture-combining/atlasing to save texture binds, which is understandable. But allowing compressed textures would be a much simpler way to still help this a good bit since at least there will be less stuff to move around on the GPU. (Testing this with even only a couple dozen sprites produced measurable speed increases of about 1500->1725 FPS on my rig.) Also, it will obviously allow more textures to be crammed on the GPU as well.
I know that compressed textures is technically an extension to OpenGL, but I think pretty much every video card supports it and it would be easy enough to do an auto fall-back to uncompressed if the GPU didn't support it.
Are these features you'd consider adding or do they violate your "simplicity" design philosophy too much? I'll probably do them myself if something like this is not on your roadmap; but if it is, I'll just wait.
Thanks.
