Hi!
I'm using FTGL for a while now in an quite complex mdi app under several platforms. I patched my version of FTGL to remove the bugs you addressed in the new version.
A weak point of FTGL which I patched away is the consistency of the used textures and display lists. My FTFont extension is an IsValid() method which determines if the used texture and display list identifiers correspond to textures and display lists.
If the font object isn't valid in my sense I usually reinitialize it by setting FaceSize().
It would quite gorgeous if something like this would arrive in the upcoming version of FTGL.
Let me know if some of the work could be done be me.
Thank you for developing FTGL!
Cheers, Yves.
Here is an example (FTGLTextureFont) how I implemented it:
class FTFont {
...
virtual bool IsValid() const = 0;
...
};
class FTGLTextureFont
{
...
virtual bool IsValid() const;
...
};
bool FTGLTextureFont::IsValid() const
{
for( std::size_t i(0); i < textureIDList.size(); ++i ) {
if( glIsTexture( textureIDList[i] ) != GL_TRUE )
return false;
}
return true;
}
Logged In: YES
user_id=37415
Originator: NO
What would cause the textures and display lists to become invalid? I'm
not really opposed to your fix but I think it causes a useless abstraction
leak and could very well be fixed internally without the user even
realising that the lists are invalid.
Logged In: YES
user_id=1162650
Originator: YES
An invalid gl context causes invalid display lists and texture ids. This happens from time to time in mdi environments on x11, even if one uses a mature tk like qt4. I had a look to your tests and it's most likely you never come across something like that.
I understand your consideration regarding a design break. I encapsulated this stuff inside a font manager, so it doesn't hurt too much but I would highly recommend and appreciate you solve this issue internally. My solution is nothing more than a quick hack but it's one solution to the problems I had.
Thanks a lot for considering to address that issue.
Logged In: YES
user_id=37415
Originator: NO
Would you have a suggestion on how to reproduce the problem, maybe
with a piece of code that deliberately invalidates the GL context?