Thread-Text Bug

[Geheim]

Good evening guys,
I found a bug with sf::Thread and sf::Text. It's a known bug, because I also found some topics about it, but they didn't help me out with my problem. ( http://en.sfml-dev.org/forums/index.php?topic=7730.0 or http://en.sfml-dev.org/forums/index.php?topic=2073.0 )

To the problem:
I made a chat, where the messages are shown in the window. But in nearly every message some letters are missing, or kinda buggy :/  The strange thing is, when I (or someone else) write more messages, the older messages slowly fill up (sometimes immediately): (Some pictures for better illustration) (I come from Austria, so its in german , but you can see it quite good I guess)


I also found out that this happens, when sf::Text is made in a sf::Thread and rendered in the main thread. The text is in a std::list and i have a sf::Thread in one class. I also wrote a simple program that pruduces the bug for me (thats the important part) (writeData is the threadfunction):

void Chat::render()
{
        for(iText=textList.begin(); iText!=textList.end(); ++iText)
                window.draw((*iText));
}

void Chat::writeData()
{
        while(true)
        {
                std::string text;
                std::getline(std::cin, text);
                sf::Text tempText(text);
                tempText.setColor(sf::Color(102, 23, 123));
                tempText.setPosition(0, static_cast<float>(textList.size()*20));
                textList.push_back(tempText);
        }
}

In my chat I use a font called "french grotesque" (http://www.dafont.com/french-grotesque.font)
I also tried out other fonts and the default font, but nothing really helped...
Maybe someone knows how to fix this bug, because it's really annoying, espiacially in a chat
Greetings Geheim!

[eXpl0it3r]

A week ago or so, Laurent removed the default font from SFML 2, unfortunatly the RC release still has the default font included which can lead to some buggy behaviour on multiple levels and sometimes ending with a crash at exit.
I'm not sure how far this is connected to your problem. If you think that it doesn't affect you, since you're using your own font, then it's not completly true, because as soon as you instanciate a sf::Text object without passing the a font to the constructor the default font gets used.
If you don't want to compile SFML 2 on your own, you can still try if it's related to the default font or not, by passing the used font through the constructor.

Like I mentioned it's just a guess and as I've already mentioned in the spieleprogrammierer forum I had the same problem a few month back and never figured out how to really solve it.
Btw welcome to the official SFML forum.

[Geheim]

Haha, yes i know That's the reason I ask here, because the problem wasn't solved yet.
Your suggestion also didn't help :/

Btw welcome to the official SFML forum.

Thx^^ In the Spieleprogrammierer forum they recommended me to write here, so here I am.

[eXpl0it3r]

In the Spieleprogrammierer forum they recommended me to write here, so here I am.

Yeah it's always a good thing to get to the original source and Laurent (the creator of SFML) is quite a lot around and very helpful.

As for your problem, it would probably best to have a sample code that is minimal but complete, so Laurent or anyone else could try it immediatly and figure out what goes wrong. (Minimal really means as less code as possible.)

[Geheim]

Yes, Laurent does a very good job!
Here is the class, i made it as less as possible!
Chat.h:

#ifndef CHAT_H
#define CHAT_H

#pragma warning(disable : 4355)         //warning C4355: this': wird in Initialisierungslisten für Basisklasse verwendet
#include <list>

class Chat
{
        private:
                sf::RenderWindow &window;
                sf::Clock &clock;
                sf::Thread writeThread;
                std::list<sf::Text> textList;
                std::list<sf::Text>::iterator iText;
                void writeData();
        public:
                Chat(sf::RenderWindow &windowGame, sf::Clock &clockGame);
                ~Chat();
                void update();
                void render();
};
#endif

Chat.cpp:

#include <SFML/Graphics.hpp>
#include <SFML/Network.hpp>
#include <iostream>
#include <list>
#include "chat.h"

Chat::Chat(sf::RenderWindow &windowGame, sf::Clock &clockGame)
: window(windowGame)
, clock(clockGame)
, writeThread(&Chat::writeData, this)
{
        writeThread.launch();
}

Chat::~Chat()
{
        //Don't forget to release memory!
        textList.clear();
        writeThread.terminate();
}

void Chat::update()
{
}

void Chat::render()
{
        for(iText=textList.begin(); iText!=textList.end(); ++iText)
                window.draw((*iText));
}

void Chat::writeData()
{
        while(true)
        {
                std::string text;
                std::getline(std::cin, text);
                sf::Text tempText(text);
                tempText.setColor(sf::Color(102, 23, 123));
                tempText.setPosition(0, static_cast<float>(textList.size()*20));
                textList.push_back(tempText);
        }
}

[Laurent]

Can you try to call glFlush() in the writeData function, after textList.push_back(tempText);?

You'll need to include <SFML/OpenGL.hpp> and link to opengl32.lib.

[Geheim]

Hey Laurent, I tried it and it really worked! It also worked for the chat!
I gave my best to pruduce the bug, but it was gone

eXpl0it3r, maybe this will also work for you as well?

Thanks Laurent you really helped me a lot!
Will this be in the next update or do I have to do this after every new text?
But I don't understand exactly why this helped... The definition is: "glFlush — force execution of GL commands in finite time", so every letter is a GL command? And because of the thread the command (letter) is not getting executed immediately?

[Nexus]

Chat::~Chat()
{
        //Don't forget to release memory!
        textList.clear();
        writeThread.terminate();
}

It is not necessary to clear a std::list explicitly if you don't need it anymore. At time of destruction, it automatically releases its memory. So the compiler-generated destructor should be enough.

Furthermore, don't terminate threads. The recommended way is to let them finish execution themselves.

And the list iterator is not part of the object state, so a member variable isn't appropriate. It is only used locally in your render() function, so you can move its declaration there, into the for loop head. Always declare variables as late and as locally as possible

[Geheim]

It is not necessary to clear a std::list explicitly if you don't need it anymore.

Thanks for the advice, I didn't know that!

Furthermore, don't terminate threads. The recommended way is to let them finish execution themselves.

Yes I know, but in my chat the threadfunction is to receive data and so it won't end until it gets a message or?
Because I tried it first with thread.wait() (like it's recommended in the tutorial), but there was something strange (I cannot exactly remember what)?

Always declare variables as late and as locally as possible

Again thanks for the advice! I also didn't know that I'll keep it in mind and change it from now on

[Laurent]

Will this be in the next update or do I have to do this after every new text?
But I don't understand exactly why this helped... The definition is: "glFlush — force execution of GL commands in finite time", so every letter is a GL command? And because of the thread the command (letter) is not getting executed immediately?

OpenGL commands are queued and flushed to the graphics card only when the driver decides so. Usually this doesn't matter because the driver does its job perfectly, but with threads and shared OpenGL contexts this can cause problems. glFlush simply forces the driver to execute the pending commands immediately.

Unfortunately I don't know if this can be integrated automatically in SFML. It highly depends on what the user code does, there's no good place to put a glFlush in SFML code. For example, in someone else's program, a similar glFlush might ruin performances.

[Geheim]

Alright, thank you guys you really helped me a lot!
Keep up the good work!^^