display.newText = SLOW. Confirm please?

Can anybody else vouch for this function causing a sudden and considerable drop in frame rate? I have a menu screen which loads up, outputting around 12 text objects in a loop (a series of numbers over a grid). Upon execution, I get a sudden drop of around 15-20 FPS. Outputting just one text object causes around 5 FPS drop on older devices, 2-3 FPS on newer devices.

Ansca, can you log this in the Bug Tracker as something to investigate? Hopefully there’s a way to tune up the displayText API.

Thanks,
Brent Sorrentino
Ignis Design
[import]uid: 9747 topic_id: 5945 reply_id: 305945[/import]

and add inbuilt Retina support too :wink: [import]uid: 9371 topic_id: 5945 reply_id: 20398[/import]

I second this!

Thanks for putting it in the bug section Brent, hopefully someone from Ansca can way in on this issue.

I would also like to add that I am experiencing the same frame rate drop when updating a text value, not just when creating one.
[import]uid: 5786 topic_id: 5945 reply_id: 20509[/import]

yes theyre slow and theyre also a memory hog. try adding a few texts at font size 200+ … my app in the simulator went up about 0.05MB per letter (half meg for 10 letters). I’m guessing it’s the number of vector curves that make up a font, and with each letter creating a new texture on the GPU, not reused

[import]uid: 6645 topic_id: 5945 reply_id: 21190[/import]

still since here seems the newText() is a real showkiller…  way to slow… no way to speed that up??

The display.newText() function involves drawing text to a *new* bitmap and then pushing that bitmap as a texture to the GPU.  Every time you create text, change text, or resize text… we have to generate a brand new texture with the updated text and push it to the GPU.  So the answer is yes, this is a slow and expensive operation.  If you’re updating text on every frame, then yes, you’ll be killing the framerate.

If you need to update text frequently and you care about performance, then you should render text via sprites and an image sheet.  This is commonly referred to as “bitmap fonts” in the gaming industry (Google it for lots of examples).  This is the technique that most game studio use to render text with high performance.  The reason it’s faster is because all of the characters/glyphs for the text are preloaded, meaning that the app does not have to generate a new bitmap/texture for every text change.

I do know that there is a 3rd party tool called “Text Candy” that’ll do this for you in Corona.  There may be other tools as well.

In any case, that’s my 2 cents.  Hope this helps!

HI Joshua,

thank u so much, i will check with the newText() from Text Candy,

right now im bit busy of some other prios, but as soon i find time again for performance checks, i will definitly come back in here.

chris

Happy to help!

I also discovered another tool named “bmGlyph” which also supports Unicode characters.  I’m not sure if Text Candy supports Unicode yet, in case that concerns you.

   http://coronalabs.com/resources/3rd-party-tools-and-services/

Come on guys, this has been how the SDK has worked for ages…

The trade off is, render it every redraw (slow), or render it once when it’s created/changed (faster most of the time, except the create of course).

The other downside of the current method is that now your text “string” occupies some texture mem too… A screen full of just text on a retina device can Occupy a noticeable chunk (but this is not usually the case for games) – a couple MB, or more on an iPad3…

Overall though, with the emphasis being on high mid-level gameplay frame rates – me likes it the way it is now - if you’re changes aren’t too large/frequent, it seems pretty neat  :stuck_out_tongue:

Good call, CoronaLabs!

still since here seems the newText() is a real showkiller…  way to slow… no way to speed that up??

The display.newText() function involves drawing text to a *new* bitmap and then pushing that bitmap as a texture to the GPU.  Every time you create text, change text, or resize text… we have to generate a brand new texture with the updated text and push it to the GPU.  So the answer is yes, this is a slow and expensive operation.  If you’re updating text on every frame, then yes, you’ll be killing the framerate.

If you need to update text frequently and you care about performance, then you should render text via sprites and an image sheet.  This is commonly referred to as “bitmap fonts” in the gaming industry (Google it for lots of examples).  This is the technique that most game studio use to render text with high performance.  The reason it’s faster is because all of the characters/glyphs for the text are preloaded, meaning that the app does not have to generate a new bitmap/texture for every text change.

I do know that there is a 3rd party tool called “Text Candy” that’ll do this for you in Corona.  There may be other tools as well.

In any case, that’s my 2 cents.  Hope this helps!

HI Joshua,

thank u so much, i will check with the newText() from Text Candy,

right now im bit busy of some other prios, but as soon i find time again for performance checks, i will definitly come back in here.

chris

Happy to help!

I also discovered another tool named “bmGlyph” which also supports Unicode characters.  I’m not sure if Text Candy supports Unicode yet, in case that concerns you.

   http://coronalabs.com/resources/3rd-party-tools-and-services/

Come on guys, this has been how the SDK has worked for ages…

The trade off is, render it every redraw (slow), or render it once when it’s created/changed (faster most of the time, except the create of course).

The other downside of the current method is that now your text “string” occupies some texture mem too… A screen full of just text on a retina device can Occupy a noticeable chunk (but this is not usually the case for games) – a couple MB, or more on an iPad3…

Overall though, with the emphasis being on high mid-level gameplay frame rates – me likes it the way it is now - if you’re changes aren’t too large/frequent, it seems pretty neat  :stuck_out_tongue:

Good call, CoronaLabs!