Hello Laurent,
I've been looking into the sf::Font source code and I believe I found a considerably serious issue. What I found doesn't stop the class from working correctly, but it still is a bad practice, I think. I did debug and confirm what I will say, but if for some reason I am wrong, ignore the post altogether.
Inside sf::Font, we find the std::map<unsigned int, Page> where we store the texture and glyph information of each character size. The sf::Font::Page class by itself declares a sf::Texture locally. I found this a little weird due to the type of the container. An std::map uses a tree internally to keep all members efficiently ordered and this means that whenever we add or remove an element, the tree will re-structure itself to remain ordered, effectively copying around the Page objects.
So, I looked into the sf::Texture copy constructor, and it downloads all data from the source texture and uploads it to the destination texture. This means that on a font with plenty of character sizes active, there are potentially dozens of texture copies, and lots of data transfering to/from the gpu.
I verified this by making sure when a new page was added, sf::Texture would be copied around a few times in the re-structuring process of the tree. It seems like a huge overkill of the performance when the map could be a std::map<unsigned int, Page*>, avoiding unecessary copies all together (I tested it and it works as good).
