SFML community forums
General => General discussions => Topic started by: Nexus on October 06, 2012, 01:37:25 pm
-
According to the documentation (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Font.php), sf::Font is not loaded completely in loadFromMemory() and loadFromStream(), I remember you saying that glyphs are loaded on demand. I think the same applies to loadFromFile(), so I would state in the doc that SFML requires read access to the file throughout the font's lifetime.
Furthermore, wouldn't it be more consistent with respect to sf::Music, if the functions were called open...() instead of load...()? Like this, the semantics are directly visible.
-
According to the documentation, sf::Font is not loaded completely in loadFromMemory() and loadFromStream(), I remember you saying that glyphs are loaded on demand. I think the same applies to loadFromFile(), so I would state in the doc that SFML requires read access to the file throughout the font's lifetime.
I can't imagine a situation where the font file is moved or removed while the program is running :P
But it's already written in the tutorial, don't worry.
Furthermore, wouldn't it be more consistent with respect to sf::Music, if the functions were called open...() instead of load...()? Like this, the semantics are directly visible.
I think it's different: sf::Music uses its source continuously due to its streamed nature, which is clearly and publicly stated by its base class. sf::Font uses its source continuously because I have no choice, it's an implementation issue. But if it was technically possible, I would rather load the entire font at once.
-
I can't imagine a situation where the font file is moved or removed while the program is running :P
An open file handle prevents these operations anyway. However, the font may be on an external storage device which is plugged out.
sf::Font uses its source continuously because I have no choice, it's an implementation issue. But if it was technically possible, I would rather load the entire font at once.
Ah, I thought it were only an optimization in the sense of "don't load before you need".
I see why it may be inefficient, but not technically impossible: Can't you copy the whole data to a buffer of which the lifetime is managed by the font?
-
Can't you copy the whole data to a buffer of which the lifetime is managed by the font?
Font files can take many MB.
-
Font files can take many MB.
Okay, so I misunderstood you.
Your decision to load data on demand however is not a pure implementation detail, since it has an effect to the API: The origin must remain valid during font usage. So if you are already sure that you won't ever change the implementation towards a complete preload, "openFromXY" might be more appropriate as it expresses there are still things to be done after the invocation.
But I see it's a bit a border case, also because sf::Font can be shared like the other resources (unlike sf::Music). Hm... Other opinions? :-\
-
So if you are already sure that you won't ever change the implementation towards a complete preload
I'm not. In SFML 1.6, glyphs were preloaded (but limited to a given character set), it changed in SFML 2.0.
-
Okay, then it looks like loadFromXY() makes sense, as you can still change the implementation in SFML 2.x without breaking code (the only thing that may happen are unnecessary copies).
Thanks for the explanations! :)