The new graphics API in SFML 2

[Mikademus]

Since Font and Text was separated, this might also be the time to introduce a much needed extension to text styles. Especially outline colours but also shadows would be extremely appreciated additions.

[Laurent]

Anyway I think that all 2.0 compliant drivers will support the extension since that is the dependency and we can only trust that. Because according to OpenGL it has officially supported Instancing since 3.0 (but the extension was created in 2.0).

A dependency on 2.0 doesn't mean that anything which supports 2.0 will have this extension too. The only way to see how an extension is supported is to use this kind of software.

You can fake instancing on the CPU and still get big GPU/CPU performance boost

How would you do that?

Since Font and Text was separated, this might also be the time to introduce a much needed extension to text styles. Especially outline colours but also shadows would be extremely appreciated additions.

I can't implement that easily.

[Groogy]

How would you do that?

It's not pretty, but it's how they originally did it before hardware support came. But I have to kind of go trough the basics of how instancing works in order to explain how I think. IF you are interested I could send it in a private message instead of bloating it here?

Any how this will not be implemented for SFML2 then. And faking it on the CPU can be done without SFML doing anything special behind the scene.

[Laurent]

IF you are interested I could send it in a private message instead of bloating it here?

Yes please

[Mikademus]

Since Font and Text was separated, this might also be the time to introduce a much needed extension to text styles. Especially outline colours but also shadows would be extremely appreciated additions.

I can't implement that easily.

What would be required, or are there particular problems associated with font rendering?

[Laurent]

What would be required, or are there particular problems associated with font rendering?

Fonts glyphs are pre-rendered, that's why effects are hard to achieve. Glyphs already come in two versions: bold and regular, which doubles the amount of video memory that sf::Font requires; I can't add more overhead.

In the future I might be able to add new effects, when text rendering will be rewritten to use shaders and distance fields.

[Mikademus]

Aah, ok, that explains it. Thanks for the explanation.

A thought: since creating a large set of textures with all combinations of styles is obviously unrealistic, an alternative possibility might be to request the creation of a font texture with a given (user-specified) combination of styles when a typeface is loaded. A specialised typeface like that would of course not be able to take any other styles, but it would solve principally all problems and satisfy all usage scenarios I can think of, as well as actually reduce memory footprint when only a particular style is needed.

The drawback of this solution is of course that colours would need to be part of the requested style.

[Groogy]

Alright I sent you a very LOOOOOONG message about instancing now
I tried to cut as many corners as possible and forced myself not to give you complete code examples to demonstrate what I mean, else I might had broken some buffer in PHP by the shear amount of text :twisted:
If anyone else want's it then just let me know and I'll PM it to you as well.

[Ricky]

Alright I sent you a very LOOOOOONG message about instancing now
I tried to cut as many corners as possible and forced myself not to give you complete code examples to demonstrate what I mean, else I might had broken some buffer in PHP by the shear amount of text :twisted:
If anyone else want's it then just let me know and I'll PM it to you as well.

me  

[Groogy]

Done

[Laurent]

A thought: since creating a large set of textures with all combinations of styles is obviously unrealistic, an alternative possibility might be to request the creation of a font texture with a given (user-specified) combination of styles when a typeface is loaded. A specialised typeface like that would of course not be able to take any other styles, but it would solve principally all problems and satisfy all usage scenarios I can think of, as well as actually reduce memory footprint when only a particular style is needed.

That's a possible solution. But like I said, text rendering will probably be rewritten soon and allow much more flexibility, so it's not worth changing it now

Alright I sent you a very LOOOOOONG message about instancing now

Thanks

[Tank]

But like I said, text rendering will probably be rewritten soon and allow much more flexibility, so it's not worth changing it now

Will it get faster, too? sf::Text is the main framerate dropper in SFGUI applications.

[Laurent]

Will it get faster, too? sf::Text is the main framerate dropper in SFGUI applications.

It should already be much faster with the new graphics API of SFML 2.0 -- as long as the text doesn't change every frame.

Distance fields, if I implement them in the future, should not improve performances that much. The main benefit of this technique is that you need only a single texture to store the glyphs for every possible size -- compared to one texture per size now.

[Tank]

Is that comparible to texture atlases?

Any chance that you push your current progress to the SFML experimental repository? I wouldn't mind if it doesn't build at all.

[Tank]

...if you mean SFML2's current state, here's what a simple benchmark shows:



We did play around with caching texts into render textures, which (of course) boosted everything up at the cost of video memory. So are there optimizations for the new 2.0 API or are they already included?