SFML community forums
General => Feature requests => Topic started by: FRex on January 16, 2019, 06:02:16 pm
-
I've mentioned it in pain points thread already. It'd let someone play with them on their own, like cache a few texts and pretransform them, or put them in a VertexBuffer. Just a simple getVertexCount + getVertexPointer, just like Image now has?
-
Just a simple getVertexCount + getVertexPointer, just like Image now has?
Or even directly a sf::VertexArray. Well, 2 sf::VertexArray since that's what it has internally. And you see where I want to go: if one day we change the implementation details of sf::Text, so let's say it has 1 or 3 vertex arrays instead, we'd have to break the public API. That's something to consider in my opinion.
-
Sure, 4 functions total then, or two const sf::VertexArray& ones. I say it's still worth it to let people cache or use it themselves. Especially since text layout code is so complex so it's not reasonable to ask people to reimplement it themselves if they want it. API breakage will be easy to fix for the user and rare.
-
SFML tries to generally not break the API in public versions, and I think overall this makes a lot of sense.
If it were different for some parts of the API, those would need to be clearly identified as unstable. Unfortunately, C++ doesn't natively offer something here, so probably the best fit would be the documentation. So this might be more a discussion about API stability than the sf::Text feature at hand...