SFML Text Artifacts

[kpulv]

Using the SFML Text in the DotNet binding I'm having problems with the text class.  I have tried multiple font sizes, and multiple fonts, and multiple strings, all with the same results.





You can see in this example there are stray pixels being rendered in the upper left hand corner of the text.  It seems to always appear on the upper left of the first character's bounding box, and it also seems like it is smaller than a single pixel because moving the text around the screen causes the artifact to appear and reappear.

I have not tried the C++ version yet, but I have spoken to at least one other DotNet developer who is experiencing the same issue with the DotNet binding of SFML.

Does anyone know what's going on or how to fix this?

Update
A friend of mine tried Text in pySFML and found the same result:


Update 2
It seems that further investigation shows that this artifact will appear when the text is drawn at a y coordinate of 0 to 0.5.  So for example if the text is at Y 50.1, the artifact will appear.  However, at 50.51, the artifact will not appear, and then it will appear again at 50.5.

It would seem that rounding is the solution -- however this is not a very good solution as this results in a loss of fidelity in drawing, as things become jittery when moving when they are always rounded to the nearest integer.

[TechRogue]

I can confirm this. It also happens when I set the scale of a Text object.

Is there a way to set smoothing on the texture used to render the text? I have a feeling that might help things.

[kpulv]

Strangely enough right now this appears to be a work around.

Create a dummy text object, like so:
Text dummytxt = new Text("Å", font, 100);

Then create your actual text:
Text testtext = new Text("QUICK!", font, 100);

Then only draw the actual text:
Window.draw(testtext);

This seems to prevent the offending pixel from appearing.

[Atrius]

@TechRogue-- In C#, I tried drawing to a RenderTexture with smooth set to false, and then copying that to a sprite and drawing it on the window. It still occurs. So it doesn't appear to be smoothing related.


I was able to repro this using C++ with the SFML 2.0 windows binaries. It's not the C# wrapper.

I don't see the extra pixel when I create and draw the Text object, but if I scale it, it's instantly visible.

        sf::RenderWindow window(sf::VideoMode(1024, 768), "Test Window");

        sf::Font font;
        if (!font.loadFromFile("c:\\windows\\fonts\\arial.ttf")) return EXIT_FAILURE;

        sf::Text text("test", font, 100);
        text.setPosition(50,50);
        text.setScale(2,2);

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                        {
                                window.close();
                        }
                }
                window.clear();
                window.draw(text);
                window.display();
        }

[TechRogue]

I was referring to the actual texture used as a source for the font, not the render texture. 

Noticing how the pixel shows up on both 't's in your example, I'm guessing it's a matter of how the source texture is created.

[kpulv]

Yeah, it has something to do with how the texture for the font is created.  Apparently the upper left corner of the texture has a small white 2x2 box placed on it: https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Font.cpp#L584

So that little set of pixels will show up on the first character of your string because of pixel interpolation (I think?)  Making a dummy text object (see my previous post) with a character you'll never use, like Å or something, will place the dot next to that Å character, and the rest of your characters will be safe.

[TechRogue]

Interesting...I wonder if that's necessary any more? Ever since the new graphics API was introduced, underlining is done by adding vertices to the vertex array. That block of code dates back to 2009 (scroll all the way down).

[Atrius]

Sorry I haven't had time to dig into this. This was the first location I tweeted but Kyle mentioned he was working in C# and didn't have it setup to compile the libs. I got home from work and looked into it.

These pixels are still required for the underline to work. If you remove the code that sets these pixels it fixes the problem but also makes it so underline doesn't work.

This confirms the issue is caused by the code at SFML/Graphics/Font.cpp:584. However, it also brings to light that you cannot remove this without losing functionality.

When I get some more time I'll look into if this can be improved and retain the functionality.

[Laurent]

You should create a ticket on the task tracker, I already have an idea how to fix it

[TechRogue]

I'll open the issue if nobody else is going to. I didn't want to jump on it because I'm not the one who found it in the first place.

[Laurent]

It's fixed, thanks for your help