SFML community forums

General => Feature requests => Topic started by: hobby on December 19, 2015, 08:22:35 am

Title: Extending Font & Text to support multiple textures (bug fix)
Post by: hobby on December 19, 2015, 08:22:35 am

EDIT: This thread has come to implementing a bug fix (https://github.com/SFML/SFML/pull/1034) for the problem of discarded glyphs when the texture used by Font and Text gets filled. It can be useful in case of big text, large alphabets or software renderers (e.g. Windows without GPU).

---

Use case: an application that can be resized by the user and draws some text in various character sizes. The size of the text varies according to the size of the window and the set of font glyphs that are needed changes over the course of the application.

The current behavior of SFML is to discard new glyphs if the underlying texture cannot be enlarged. The maximum texture size is implementation-dependent and is especially small in SW renderers (e.g. 512x512), resulting in some of the characters not displaying. To prevent that, I use some heuristics to calculate a limit on the character size and then use Text::setScale() to scale the font for the desired size. Large text can become a bit blurry on SW renderers, but this is more tolerable than characters not displaying.

The problem is that with multiple fonts, and new characters being added dynamically, it is not simple to estimate a safe limit on the character size that the maximum texture size will be able to accommodate. It would be easy to start high and decrease the limit on the fly if SFML provided a simple way of determining whether Font had discarded any glyphs for a given character size. (I guess I could redirect sf:err() to a stringbuf and test it at runtime, but I'm looking for a more standardized approach...)

Title: Reliable solution for discarded glyphs?
Post by: hobby on December 26, 2015, 09:23:56 am

I managed to partially workaround over the problem for large character sizes (titles/subtitles) by creating multiple instances of sf::Font for the same font, and re-creating them whenever the "context" changes (suggesting different titles/subtitles).

However, taking into account the trend in PC screen resolutions (https://en.wikipedia.org/wiki/List_of_common_resolutions#Computer_graphics), this method is not too reliable. How can I be sure that what I write today will also work X years from now, on larger screens? Am I the only one that has run into dropped glyphs? I can think of other scenarios, such as big marquees, that are risky to do with SFML.

Is there any interest in extending sf::Font and sf::Text to support multiple textures so that all characters are displayed regardless of how big they are?

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on December 26, 2015, 10:35:51 am

Quote

Is there any interest in extending sf::Font and sf::Text to support multiple textures so that all characters are displayed regardless of how big they are?

Of course, we'll have to fix this one day, we can't leave something broken in the API.

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on December 26, 2015, 01:21:01 pm

Quote from: Laurent on December 26, 2015, 10:35:51 am

Of course, we'll have to fix this one day, we can't leave something broken in the API.

Can't it be fixed already in SFML 2? The only issue is designing how to extend the interface of Font (and possibly Glyph) in a backward-compatible way. I could come up with some suggestions, but I'm not familiar with your practices so it may be a waste of time.

For example, suppose that we have a method Font::getTextureCount(). One option is to add some textureIndex as a field to Glyph and an optional parameter to Font::getTexture(). Another option, that is less clean in terms of interface but may be simpler to implement, is to not modify Glyph at all, but rather add a new method Font::getGlyphAndTexture() that returns a pair.

Anyway, since new glyphs are currently discarded, SFML users that assume that Font has only one Texture and use the coordinates returned by Font::getGlyph() on the wrong texture may not be impacted too much. If the current behavior must be preserved, a method such as Font::setMultipleTextures() can be added.

How would you extend the existing interface?

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on December 26, 2015, 01:47:13 pm

What about simply adding a pointer to the texture in sf::Glyph? So there would only be Font::getGlyph, no more Font::getTexture.

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on December 27, 2015, 11:10:13 pm

Quote from: Laurent on December 26, 2015, 01:47:13 pm

What about simply adding a pointer to the texture in sf::Glyph? So there would only be Font::getGlyph, no more Font::getTexture.

It's great in terms of interface, but can make it a bit harder to optimize if needed.

Anyway, you can see my implementation here (https://github.com/hobby8/SFML/commit/39a85a7173660d0552720d1f16732a5974e042c3). For start, I favored a simpler implementation over a more optimized one. In the case of underlined/strike-through text, this results in one more RenderTarget::draw() call (can be removed easily later).

I suggest that you or one from the SFML team will review the changes, not in terms of functionality but in terms of SFML practices, as there were many options throughout the implementation. I prefer to discuss everything here (not in GitHub).

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on December 28, 2015, 09:25:50 am

I just made a quick review without looking too much at the details, but I think it looks good. The only drawback is that your implementation forces to free and reallocate the vertex arrays' memory every time the geometry changes, whereas the memory is always kept allocated in the current implementation (std::vector::clear doesn't deallocate). But as you said, you started with a simple implementation, which is a good thing.

Oh, and the texture member of sf::Glyph should be const :P

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on December 28, 2015, 07:15:05 pm

Thanks for the quick feedback. Fixed both issues and created pull request #1034 (https://github.com/SFML/SFML/pull/1034).

The implementation can be tested by manually modifying the maximum texture size in Font::findGlyphRect() (https://github.com/hobby8/SFML/blob/font_text_multiple_textures/src/SFML/Graphics/Font.cpp#L674) to a small hard-coded value, thereby forcing the use of multiple textures.

Backward-compatibility can be tested by additionally taking my version of Font and Glyph but keeping the existing implementation of Text.

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on December 28, 2015, 10:58:58 pm

Quote

Fixed both issues

Now the entries in the vertex map will stay forever, even if never used again by the sf::Text instance.

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on December 29, 2015, 06:56:53 pm

Quote from: Laurent on December 28, 2015, 10:58:58 pm

Quote

Fixed both issues

Now the entries in the vertex map will stay forever, even if never used again by the sf::Text instance.

EDIT: Perhaps you have missed the elusive line (https://github.com/hobby8/SFML/blob/972b662ea95763aede91f245f3bf7947a0718f77/src/SFML/Graphics/Text.cpp#L82) that frees the entire vertex map on calls to Text::setFont()? If that's what you were looking for, then I can add this line also to Text::setCharacterSize() and I think it will work fine. Anyway, below you may find my reasoning for the current implementation. /EDIT

My rationale for this particular point along the performance/memory/code complexity tradeoff in sf::Text stemmed from assumptions regarding the most likely scenario of sf::Text instances reuse.

More specifically:
1. Allocations (~120 bytes per char) are reused in all the following cases:

• change in text string
• change in color
• change in text style (underline/strike-through/italics/bold)

2. Allocations are not reused in case of:

• change in character size

3. And lastly, all allocations are freed on:

• change in font

I assumed that if anything in the sf::Text instance changes between draw() calls, it will most likely belong to group (1) above. And that the likelihood of changing (2) without changing (3) is low. And that anyway, while changes to (3) are unlimited in nature, (2) is a discrete number so it can have some upper bound (I was thinking more on PCs in this last statement).

Sure, I can optimize for both performance & memory usage by always reusing allocations done by previously-clear'ed vector's. It will add some bits to the code. Shall I do that? Or did you have other things in mind?

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on December 30, 2015, 06:06:10 pm

Quote

Perhaps you have missed the elusive line that frees the entire vertex map on calls to Text::setFont()?

Indeed :)

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on December 30, 2015, 11:13:03 pm

Quote from: Laurent on December 30, 2015, 06:06:10 pm

Quote

Perhaps you have missed the elusive line that frees the entire vertex map on calls to Text::setFont()?

Indeed :)

That was for the better :) - I've just added a few comments to sf::Text and also aligned setCharacterSize() to match the behavior of setFont().

Below please find a program that drops glyphs on Win7 64 bit if no GPU is installed (i.e. 512x512 max texture size), and additionally some version of my test program. I've performed both black-box and white-box testing, including backward-compatibility for users of Font::getTexture(), and also used apitrace (https://apitrace.github.io/) to verify the textures and drawing sequence.

(click to show/hide)

void main() {
    sf::RenderWindow window(sf::VideoMode(800, 600, 32), "Marquee");

    sf::Font font;
    if (!font.loadFromFile("resources/DejaVuSans.ttf"))
        return;

    sf::Text text("This string will not display correctly on Windows GDI Generic", font, 360);  // any char size >= 180 is bad
    sf::Clock clock;
    int frame = 0;

    while (window.isOpen()) {
                sf::Event event;
        while (window.pollEvent(event))
            if (event.type == sf::Event::Closed)
                window.close();

        window.clear();
        text.setPosition(static_cast<float>(800 - clock.getElapsedTime().asMilliseconds()), 0);
        window.draw(text);
        window.display();
        if (!frame++)
            clock.restart();
    }
}
 

(click to show/hide)

void main() {
    sf::RenderWindow window(sf::VideoMode(800, 600, 32), "Test");

    sf::Font font;
    if (!font.loadFromFile("resources/DejaVuSans.ttf"))
        return;

    // Note: Texture::getMaximumSize() needs to be modified to return 256 for this test to be effective.

    std::string str;
    for (int i = '!'; i <= 'z'; i++)
        str += (char) i;
    sf::Text text("(not displayed)", font, 30);

    while (window.isOpen()) {
                sf::Event event;
        while (window.pollEvent(event))
            if (event.type == sf::Event::Closed)
                window.close();

        window.clear();
        float y = 0;
        for (int charSize = 48; charSize <= 72; charSize += 24) {
            text.setString(str);
            text.setCharacterSize(charSize);
            text.setStyle((charSize == 72 ? sf::Text::StrikeThrough : 0));
            text.setColor(sf::Color::White);
            sf::FloatRect textRect = text.getLocalBounds();
            for (float x = 0; x < textRect.width; x += window.getSize().x, y += charSize) {
                text.setPosition(-x, y - textRect.top);
                window.draw(text);
                text.setColor(sf::Color::Green);
            }
            std::reverse(str.begin(), str.end());
        }
        window.display();      
    }
}
 

Do you consider this issue a bug or a feature?

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on December 31, 2015, 10:25:21 am

Thanks for the tests :)

Quote

Do you consider this issue a bug or a feature?

Glyphs not showing is definitely a bug.

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on February 08, 2016, 09:40:27 pm

Quote from: Laurent on December 31, 2015, 10:25:21 am

Quote

Do you consider this issue a bug or a feature?

Glyphs not showing is definitely a bug.

I've noticed #1034 (https://github.com/SFML/SFML/pull/1034) has been tagged with "feature". Are you not convinced glyphs are dropped? Or is it not that important considering the target audience of SFML?

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: Laurent on February 08, 2016, 10:18:26 pm

This is most likely an oversight. The title of the PR is also a bit misleading, "extended" usually refers to an additional feature rather than a bug fix.

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: eXpl0it3r on February 09, 2016, 10:34:10 am

Yes, when I set the label, I only read the title and the description which also reads as:

Quote

Extending Font and Text to support multiple textures so that glyphs are not discarded in case one texture gets filled.

If I extend some classes, I'm adding new things, making it a feature. Then again the PR itself could probably go either way. In the end it's not really that important. ;)

Title: Re: Determining if glyphs for a given character size have been discarded
Post by: hobby on February 09, 2016, 09:42:10 pm

Quote from: eXpl0it3r on February 09, 2016, 10:34:10 am

Then again the PR itself could probably go either way. In the end it's not really that important. ;)

Sure. The important thing to ask is, what process do you use to decide regarding undecided PRs?

Title: Re: Extending Font & Text to support multiple textures (bug fix)
Post by: hobby on March 18, 2016, 10:07:44 am

More specifically, I need to know whether the bug fix (#1034) (https://github.com/SFML/SFML/pull/1034) is going to be merged. I can update it to support outlined text (https://github.com/SFML/SFML/pull/840) but I will not bother to do so just for my project.
As I target PCs not mobiles, I may as well just join the club of those having their own version of SFML, where I can freely implement additional fixes/optimizations (#1015 (https://github.com/SFML/SFML/pull/1015) and this one (http://en.sfml-dev.org/forums/index.php?topic=19472.0)) without regard for new SFML functionality.