Blocky font rendering

[Aster]

Hi everyone.

I'm using SFML compiled from source from the feature/xcb branch.
When trying to render text in a virtual machine running Ubuntu 14.04 (both x86 and x86_64), my code gives me blocky text:

int main()
{
    // Load a font for text rendering
    sf::Font font;
    if(!font.loadFromFile("resources/sansation.ttf"))
        return EXIT_FAILURE;

    // Create a text object using the font we've just loaded
    sf::Text text;
    text.setFont(font);
    text.setCharacterSize(16);
    text.setColor(sf::Color::White);
    text.setPosition(0.f, 0.f);
    text.setString(
        "SFMLSFMLSFML"
    );

    // Create the main window
    sf::RenderWindow window(sf::VideoMode(640, 64), "SFML");

    // Start the game loop
    while (window.isOpen())
    {

        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window: exit
            if (event.type == sf::Event::Closed)
                window.close();

            // Escape key: exit
            if ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape))
                window.close();
        }

        // Clear the window of previously drawn content
        window.clear();

        // Draw our text
        window.draw(text);

        // Finally, display the rendered frame on screen
        window.display();
    }

    return EXIT_SUCCESS;
}

 

Here's an image:


This is weird because I'm using exactly the same font as the OpenGL example, and the OpenGL example's text renders just fine

The same code works just fine on Windows (8.1 x86_64)

Any ideas/feedback/help is appreciated.

Thanks,
Aster

[AlexxanderX]

Just tried the code in Ubuntu 14.04( not virtual machine) and everything render fine. Using the same font from OpenGL example.

[Aster]

Just tried the code in Ubuntu 14.04( not virtual machine) and everything render fine. Using the same font from OpenGL example.

Hm.. this is weird.. Did you try the feature/xcb branch? Why would both work outside of a VM, but only one would work within a VM?

[Laurent]

Can you try the master branch? Can you also try to create the window before doing anything else?

[Aster]

Can you try the master branch? Can you also try to create the window before doing anything else?

The same code with the master branch segfaults with backtrace:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0xb7cb53e9 in ___printf_fp (fp=fp@entry=0xbfffea90, info=0xbfffe654, args=args@entry=0xbfffe630) at printf_fp.c:1250
1250 printf_fp.c: No such file or directory.
(gdb) bt
#0  0xb7cb53e9 in ___printf_fp (fp=fp@entry=0xbfffea90, info=0xbfffe654, args=args@entry=0xbfffe630) at printf_fp.c:1250
#1  0xb7caf07f in _IO_vfprintf_internal (s=s@entry=0xbfffea90, format=<optimized out>, format@entry=0xb7560e4a "%.1f Chromium %s", ap=<optimized out>, ap@entry=0xbfffeb68 "") at vfprintf.c:1660
#2  0xb7cd18d2 in __IO_vsprintf (string=string@entry=0x2c <error: Cannot access memory at address 0x2c>, format=format@entry=0xb7560e4a "%.1f Chromium %s", args=args@entry=0xbfffeb68 "")
    at iovsprintf.c:42
#3  0xb7cb828f in __sprintf (s=0x2c <error: Cannot access memory at address 0x2c>, format=0xb7560e4a "%.1f Chromium %s") at sprintf.c:32
#4  0xb73fcf49 in packspu_GetString () from /usr/lib/i386-linux-gnu/VBoxOGLpackspu.so
#5  0xb76c3253 in cr_glGetString () from /usr/lib/i386-linux-gnu/dri/vboxvideo_dri.so
#6  0xb7f60d01 in sf::priv::GlContext::initialize (this=0x804e0d0) at /tmp/SFML/src/SFML/Window/GlContext.cpp:279
#7  0xb7f607fe in sf::priv::GlContext::globalInit () at /tmp/SFML/src/SFML/Window/GlContext.cpp:126
#8  0xb7f61bd7 in sf::GlResource::GlResource (this=0xbfffee00) at /tmp/SFML/src/SFML/Window/GlResource.cpp:53
#9  0xb7f657b4 in sf::Window::Window (this=0xbfffee00) at /tmp/SFML/src/SFML/Window/Window.cpp:48
#10 0xb7fb679e in sf::RenderWindow::RenderWindow (this=0xbfffee00, mode=..., title=..., style=7, settings=...) at /tmp/SFML/src/SFML/Graphics/RenderWindow.cpp:42
#11 0x08049f8a in main () at test.cpp:17


Moving the window creation to the top of the function doesn't change anything.

[binary1248]

Little known fact: VirtualBox has abysmal guest 3D (OpenGL included) support at the moment. I managed to get it working with an SVN build of the guest additions not too long ago on Arch Linux, but I assume that they aren't available that easily on Ubuntu. It becomes broken and gets fixed in their SVN revisions more often than the weather changes, so I wouldn't necessarily call a test in VirtualBox a valid one.

[Aster]

Little known fact: VirtualBox has abysmal guest 3D (OpenGL included) support at the moment. I managed to get it working with an SVN build of the guest additions not too long ago on Arch Linux, but I assume that they aren't available that easily on Ubuntu. It becomes broken and gets fixed in their SVN revisions more often than the weather changes, so I wouldn't necessarily call a test in VirtualBox a valid one.

Yeah, I had to compile the guest modules from source to get OpenGL working, and I'm only using Ubuntu because I'd assume VirtualBox would have better support for it.

But my question remains: why would text display in the OpenGL example and not in the code I pasted?

[binary1248]

My wild guess is, once again, context sharing. That is the only thing I can think of when comparing your code and the OpenGL example that is currently in master.

It is already not unexpected that sharing screws up even on implementations that claim to work, *cough* Intel *cough*. It is even worse when the people who support the implementation say themselves that it is in an unstable/broken state as is the case with the VirtualBox modules. This is basically "undefined behaviour by design" and there is nothing we can really do about it.

In software development, when using external libraries, one simply has to assume that a set of assumptions provided by those libraries holds true. OpenGL is a specification. Its context management functions (in wgl and glx) are more or less also specifications that provide assumptions which should hold true as well. If an implementation can't guarantee that sharing works as the specification requires, I have no choice but to call it broken, and you can't really expect SFML to support every single broken implementation out there. I can't really blame the VirtualBox guys that much, because they openly state that 3D support is a work in progress. On the other hand, vendors that say that "hardware" product XYZ supports OpenGL X.Y but fail to tell users that half of it is in software is simply unacceptable to me. People fail to realize that if a driver update fixes an issue with something that is normally taken care of in hardware, chances are that feature is fully realized in software and barely hardware accelerated. Unless there is a physical discrete card stuck into a PCIe slot in my system, vendors will have to convince me that their implementation is even partially hardware accelerated. Often they don't mention anything of the sort, because let's face it, 99% of their "customers" don't even know what the difference is. The 1% being us, for which it makes a difference are the losers in the end.

You can try to force all SFML resources and their underlying OpenGL resources to be created in one and the same context by first probing sf::Shader::isAvailable() and sf::Texture::getMaximumSize() right after you create the window. After that, set the window as active once more and it should stay active until the application closes. Everything that happens after that should happen in a single context (the window's one) and sharing shouldn't even be required in that case. So even if it is broken, the application should behave as expected.

[Aster]

Thanks for the clarifications.

The drive I had Arch on was really old and eventually gave up, so I've ordered an SSD and I guess I'll just wait for that to arrive to resume my Linux activities.

Cheers