About dynamic text & SDL_TTF API

[Gabriele_Greco]

I don’t know if anyone looked at this, but a guy made a simple, but
effective benchmark that compares SDL2 vs SFML, and SDL2 seems to win all
benchmark except one, the dynamic text rendering.

https://github.com/swarminglogic/SFML-vs-SDL-Benchmark/tree/master/src

The problem with dynamic text rendering is that SDL, at least with SDL TTF,
renders on a NEW surface and that you have to convert the surface to a
texture to use it with the new API.

Here is what the benchmark does, that AFAIK is the only correct way to go
at the moment:

SDL_Surface* surfaceText = TTF_RenderText_Blended(font, oss.str().c_str(),
textColor);
SDL_Texture* text = SDL_CreateTextureFromSurface(renderer, surfaceText);

// Define the text rectangle
SDL_Rect rect;
rect.x = 0;
rect.y = i * 30;
rect.w = surfaceText->w;
rect.h = surfaceText->h;

// Blit the text surface
SDL_RenderCopy(renderer, text, NULL, &rect);

I’ve looked at SDL_TTF HG head, but there is not yet an API like:

int TTF_RenderText_Blended_Texture(TTF_Font *font, SDL_Texture *texture,
const char *str, SDL_color color, SDL_Rect *rect);

I think it could be useful.

The idea could be that the texture could work as a clip rect for the
rendering, so the user will have to give the API a big enough texture, or
he will get only a partial rendering (the return code could be used to
detect if the text hits the limits of the texture).

The height/width of the area will be filled with the width/height of the
text displayed (if rect is not null).

I think this will work better if the texture used is a “streaming” texture.

If there is interest, and the API freeze is only relative to SDL2, I can
try to add this feature to SDL_TTF.–
Bye,
Gabry

[slouken]

Actually a better thing to add would be direct OpenGL or SDL renderer
support. The right way to do this is to keep a cached set of textures for
the glyphs and use draw calls to place them using hinting and wrapping
rules.

The existing SDL text interface is really designed around the SDL 1.2
software surfaces.

I know there are other libraries out there that do this for OpenGL, it
might be interesting to port one of the good ones to SDL’s 2D renderer and
deprecate SDL_ttf for SDL 2.0.On Fri, May 31, 2013 at 12:45 AM, Gabriele Greco <gabriele.greco at darts.it>wrote:

I don’t know if anyone looked at this, but a guy made a simple, but
effective benchmark that compares SDL2 vs SFML, and SDL2 seems to win all
benchmark except one, the dynamic text rendering.

https://github.com/swarminglogic/SFML-vs-SDL-Benchmark/tree/master/src

The problem with dynamic text rendering is that SDL, at least with SDL
TTF, renders on a NEW surface and that you have to convert the surface to a
texture to use it with the new API.

Here is what the benchmark does, that AFAIK is the only correct way to go
at the moment:

SDL_Surface* surfaceText = TTF_RenderText_Blended(font, oss.str().c_str(),
textColor);
SDL_Texture* text = SDL_CreateTextureFromSurface(renderer, surfaceText);

// Define the text rectangle
SDL_Rect rect;
rect.x = 0;
rect.y = i * 30;
rect.w = surfaceText->w;
rect.h = surfaceText->h;

// Blit the text surface
SDL_RenderCopy(renderer, text, NULL, &rect);

I’ve looked at SDL_TTF HG head, but there is not yet an API like:

int TTF_RenderText_Blended_Texture(TTF_Font *font, SDL_Texture *texture,
const char *str, SDL_color color, SDL_Rect *rect);

I think it could be useful.

The idea could be that the texture could work as a clip rect for the
rendering, so the user will have to give the API a big enough texture, or
he will get only a partial rendering (the return code could be used to
detect if the text hits the limits of the texture).

The height/width of the area will be filled with the width/height of the
text displayed (if rect is not null).

I think this will work better if the texture used is a “streaming” texture.

If there is interest, and the API freeze is only relative to SDL2, I can
try to add this feature to SDL_TTF.

–
Bye,
Gabry

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[slouken]

FYI, for those that don’t know him, Sean Barrett rocks.

Here’s some simple code he wrote that could be a good base for an SDL 2
based text rendering system:

nothings/stb

He’s also got a lightweight image loader for loading your own images:
http://nothings.org/stb_image.cOn Fri, May 31, 2013 at 2:20 PM, Sam Lantinga <@slouken> wrote:

Actually a better thing to add would be direct OpenGL or SDL renderer
support. The right way to do this is to keep a cached set of textures for
the glyphs and use draw calls to place them using hinting and wrapping
rules.

The existing SDL text interface is really designed around the SDL 1.2
software surfaces.

I know there are other libraries out there that do this for OpenGL, it
might be interesting to port one of the good ones to SDL’s 2D renderer and
deprecate SDL_ttf for SDL 2.0.

On Fri, May 31, 2013 at 12:45 AM, Gabriele Greco <gabriele.greco at darts.it>wrote:

I don’t know if anyone looked at this, but a guy made a simple, but
effective benchmark that compares SDL2 vs SFML, and SDL2 seems to win all
benchmark except one, the dynamic text rendering.

https://github.com/swarminglogic/SFML-vs-SDL-Benchmark/tree/master/src

The problem with dynamic text rendering is that SDL, at least with SDL
TTF, renders on a NEW surface and that you have to convert the surface to a
texture to use it with the new API.

Here is what the benchmark does, that AFAIK is the only correct way to go
at the moment:

SDL_Surface* surfaceText = TTF_RenderText_Blended(font,
oss.str().c_str(), textColor);
SDL_Texture* text = SDL_CreateTextureFromSurface(renderer, surfaceText);

// Define the text rectangle
SDL_Rect rect;
rect.x = 0;
rect.y = i * 30;
rect.w = surfaceText->w;
rect.h = surfaceText->h;

// Blit the text surface
SDL_RenderCopy(renderer, text, NULL, &rect);

I’ve looked at SDL_TTF HG head, but there is not yet an API like:

int TTF_RenderText_Blended_Texture(TTF_Font *font, SDL_Texture *texture,
const char *str, SDL_color color, SDL_Rect *rect);

I think it could be useful.

The idea could be that the texture could work as a clip rect for the
rendering, so the user will have to give the API a big enough texture, or
he will get only a partial rendering (the return code could be used to
detect if the text hits the limits of the texture).

The height/width of the area will be filled with the width/height of the
text displayed (if rect is not null).

I think this will work better if the texture used is a "streaming"
texture.

If there is interest, and the API freeze is only relative to SDL2, I can
try to add this feature to SDL_TTF.

–
Bye,
Gabry

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[D_B]

I can second his code for TTF loading. We have it implemented with
Font-Stash, found here:

akrinke/Font-Stash

We have gotten extremely good performance with this code combination,
although Font-Stash does require OpenGL.On Sun, Jun 2, 2013 at 10:34 PM, Sam Lantinga wrote:

FYI, for those that don’t know him, Sean Barrett rocks.

Here’s some simple code he wrote that could be a good base for an SDL 2
based text rendering system:
http://nothings.org/stb/stb_truetype.h

He’s also got a lightweight image loader for loading your own images:
http://nothings.org/stb_image.c

On Fri, May 31, 2013 at 2:20 PM, Sam Lantinga wrote:

Actually a better thing to add would be direct OpenGL or SDL renderer
support. The right way to do this is to keep a cached set of textures for
the glyphs and use draw calls to place them using hinting and wrapping
rules.

The existing SDL text interface is really designed around the SDL 1.2
software surfaces.

I know there are other libraries out there that do this for OpenGL, it
might be interesting to port one of the good ones to SDL’s 2D renderer and
deprecate SDL_ttf for SDL 2.0.

On Fri, May 31, 2013 at 12:45 AM, Gabriele Greco <gabriele.greco at darts.it wrote:

I don’t know if anyone looked at this, but a guy made a simple, but
effective benchmark that compares SDL2 vs SFML, and SDL2 seems to win all
benchmark except one, the dynamic text rendering.

https://github.com/swarminglogic/SFML-vs-SDL-Benchmark/tree/master/src

The problem with dynamic text rendering is that SDL, at least with SDL
TTF, renders on a NEW surface and that you have to convert the surface to a
texture to use it with the new API.

Here is what the benchmark does, that AFAIK is the only correct way to
go at the moment:

SDL_Surface* surfaceText = TTF_RenderText_Blended(font,
oss.str().c_str(), textColor);
SDL_Texture* text = SDL_CreateTextureFromSurface(renderer, surfaceText);

// Define the text rectangle
SDL_Rect rect;
rect.x = 0;
rect.y = i * 30;
rect.w = surfaceText->w;
rect.h = surfaceText->h;

// Blit the text surface
SDL_RenderCopy(renderer, text, NULL, &rect);

I’ve looked at SDL_TTF HG head, but there is not yet an API like:

int TTF_RenderText_Blended_Texture(TTF_Font *font, SDL_Texture *texture,
const char *str, SDL_color color, SDL_Rect *rect);

I think it could be useful.

The idea could be that the texture could work as a clip rect for the
rendering, so the user will have to give the API a big enough texture, or
he will get only a partial rendering (the return code could be used to
detect if the text hits the limits of the texture).

The height/width of the area will be filled with the width/height of the
text displayed (if rect is not null).

I think this will work better if the texture used is a "streaming"
texture.

If there is interest, and the API freeze is only relative to SDL2, I can
try to add this feature to SDL_TTF.

–
Bye,
Gabry

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org