Text rendering broken on my machine when using sf::Shape

[Qix]

Unloading the font after the text object is creating causes an access violation. That's probably expected (I was hoping the texture for the text object actually cloned the glyph-sheet).

I guess I'm going to have to live with just a TON of fonts loaded in.

EDIT: While writing this, another test came into my head, and I tried it, and found a complete workaround for the issue without a ridiculous amount of memory (only one font loaded, as it normally would be).

Regarding the previously listed order of operations for the workaround, only the dummy font needs to be (and can be) unloaded safely. Also, the desired font can be reused.

This achieves the desired functionality.

I'm going to put it into effect and try it as it will be in production to confirm this works. Wish me luck.

[Laurent]

Unloading the font after the text object is creating causes an access violation.

sf::Font holds the texture that sf::Text uses for rendering, so yes it is expected. It would be a waste to duplicate glyphs inside each sf::Text instance. It's similar to how sf::Sprite and sf::Texture work.

So having a TON of fonts loaded helps to keep the memory consumption low, by sharing glyphs among all sf::Text objects that use it, instead of duplicating them. Remember  that only the used glyphs are loaded in a sf::Font instance, nothing else is (the font file is streamed on the fly when a new glyph is needed).

But wait... was it your problem? You were destroying sf::Font instances that were still being used?

[Qix]

But wait... was it your problem? You were destroying sf::Font instances that were still being used?

Nonono, that was just a test for a workaround. Read the edit in the post before yours. I found a workaround that seems to fix the problem without having to load the same font multiple times for each Text object.

It seems like the perfect workaround (as perfect as it could get).

Just to reiterate, Upon the label creation, yes the font is re-loaded into memory, but destroyed directly after. This seems to work; I'm going to re-work the issue and re-create the Lua scripts to get rid of all the mangled crap. I'll report back here after I'm done.

[Laurent]

Ok ok.

I didn't read everything on the wiki yet, but I can see that at the end you talk about font size, and link to a forum topic where threads are involved.

This reminds me two things:
- bigger (and/or more) glyphs need bigger textures; if you reach your graphics card's limit additional glyphs will fail, SFML can't handle multiple textures for the same character size (yet?)
- a font loaded in a thread may not be updated in the rendering thread; in this case you need to call glFinish() after loading the font

This probably doesn't explain your problem, but it may help you to understand better how things work internally.

[Qix]

This reminds me two things:
- bigger (and/or more) glyphs need bigger textures; if you reach your graphics card's limit additional glyphs will fail, SFML can't handle multiple textures for the same character size (yet?)
- a font loaded in a thread may not be updated in the rendering thread; in this case you need to call glFinish() after loading the font

Calling glFinish() worked for one font, actually. All subsequent fonts failed to load. It also only works for setting one text object. It's an improvement but not a total fix.

EDIT: CALLING glFinish() AFTER ALL FONTS WORKS. >.> Holy crap.

Are there any implications or warnings/potential side effects with this?

EDIT2: Seems to be a complete fix. Images and text are working fine. Going to test on the Integrated intel (mac)...

[Laurent]

glFinish() forces all the queued OpenGL commands to execute and finish. The call returns when the driver has executed everything.

If it solves your problem, it means that you use multi-threading, or at least multiple OpenGL contexts (ie. multiple sf::RenderTarget and/or sf::Context). Is that what happens in your program?

[Qix]

glFinish() forces all the queued OpenGL commands to execute and finish. The call returns when the driver has executed everything.

If it solves your problem, it means that you use multi-threading, or at least multiple OpenGL contexts (ie. multiple sf::RenderTarget and/or sf::Context). Is that what happens in your program?

Multithreading.

[Laurent]

Ok... so you actually face a well known problem. We could have saved a lost of wasted time and effort

[Qix]

Ok... so you actually face a well known problem. We could have saved a lost of wasted time and effort

I've mentioned it was in another thread. I wasn't aware different threads were an issue other than with setActive... >.>

This should be better documented IMHO.

EDIT: I hope to hear from opatut to see if any of this helps solve his issue.

[Laurent]

I've mentioned it was in another thread

The only reference to the word "thread" is lost in the middle of a sentence, in the middle of your first post, and does not really emphasizes the fact that font loading and text rendering happen in two separate threads

Again it pushes the transforms, etc. and locks (thread and GL states, including setting the target to be active) and draws.

This should be better documented IMHO

This should even be fixed!

I hope to hear from opatut to see if any of this helps solve his issue

I think the ATI bug which is solved by the latest beta drivers has nothing to do with that. Your problem is a logic problem in SFML, his problem is purely a driver bug (which happens in monothreaded applications).

[Qix]

I think the ATI bug which is solved by the latest beta drivers has nothing to do with that. Your problem is a logic problem in SFML, his problem is purely a driver bug (which happens in monothreaded applications).

Gah, well I feel useless now.

EDIT: Laurent, should I make a bug report for the glFinish() issue?