Performance impact of rendering text.

0 favourites
  • 15 posts
From the Asset Store
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
  • Hey there!

    I was wondering if there's any big difference in using pre-rendered text (images of text) vs actually render the text on run time. (this for texts that don't change, or change just once per layout, like text that need to be in different languages, i could use an sprite with frames instead of text, assuming it has a significant impact on performance)

    Also, when the text is the same every tick, and it's set to "set text" in an always condition, does construct re-render it every tick or, since it hasn't change, it leaves it alone?

    This seconds question is for things like "health points". where you set the text to, for example; player.hp.

    I'm guessing the game does render the texts again and again, and would be best to just set text when needed to, right? I've feel rendering text is a lot heavier on performance than it seems.

  • Dom Objects don't render in the canvas. So they add terrible overhead. While desktop's can soak this. Any mobile game shuold avoid them like the plauge.

    Sprites Fonts should be the only one considered.

  • Use Sprites Fonts or sprites.

  • jayderyu sorry, but I'm gonna need clarification :S

    you mean that objects like the Text objects are incredible hard to process? and I should go with a sprite of text instead?

    Meaning that events like "every tick; set text to X" will drop fps like crazy?

    I also found this Article that pretty much says what you said, i think...

    I had never though about any of this prior tonight, and my game is actually full of events with always conditions, specially text objects and frame setting on sprites...

    So i'm going to have to implement a ton of "checkers" and functions to replace all the "always". It should really improve performance though =O

  • iceangel thanks, i see that now =O

    do you have any information regarding sprites font vs sprite performance? should they be identical? (i speculate the pre-rendered sprite should perform a little bit better)

  • In my opinion goes better using sprites that sprites font especially if you are using CocoonJS.

  • iceangel it seems I have some objects to replace and a ton of events to modify now =P!

  • Using sprites is more work but you are better performance.

  • I believe there is a big difference between text and textbox. Textbox is a dom element. I think (please correct me if I'm wrong here) is rendered on the canvas and so it is efficient (the implementation is scirra's). Having said that, spritefont is best because you get consistent look across all browsers, platforms.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • jayderyu - the Text object is not a DOM object. It's a pure canvas feature like Sprite.

    Sargas - if the contents of the Text object is not changing, it renders as fast as a normal Sprite. However changing the text causes re-flow of the text, and in WebGL mode a copy-to-texture which can be slow. Generally if you avoid changing text's contents every tick it's fine. Even if you need to keep changing text, just change it on a timer instead (e.g. once a second). Alternatively you can use a Sprite Font which never needs the possibly slow copy-to-texture that Text object needs to do when its contents changes.

  • Well, this is disappointing... I changed every text to either an image or sprite fonts, and all the "every tick" to a setter. I made a ton of "performance efficiency" upgrades on my program... and the amazing result; about 3% increase in performance xD

    Hopefully slower devices will make it more noticeable.

    The game sure looks prettier now, after with the graphics overhaul

  • The cpuutilisation is not a precise measurement, and the debbuger maybe has an overhead for each different object, also at the end, it is by testing on the devices you are targetting (not in preview only) that the result will be clear

  • Yep, optimisation is often a waste of time. Rely on measurements with the profiler to direct your optimisation efforts, and only do it if necessary.

  • haha, thanks Ashley! I actually had read that when it came out.

    I like the program to be as smooth and elegant as possible, i'm all for doing it the best way. I just needed to understand how the inner machinery worked ^^

  • Well, this is disappointing... I changed every text to either an image or sprite fonts, and all the "every tick" to a setter. I made a ton of "performance efficiency" upgrades on my program... and the amazing result; about 3% increase in performance xD

    Hopefully slower devices will make it more noticeable.

    The game sure looks prettier now, after with the graphics overhaul

    That 3% of your CPU, if its an Intel i5 or i7, is MASSIVE when it comes to mobiles.

    I tell you from my own experience, having my games using an average 20% of my i5-3570K will lag older devices with Tegra 3, but if its using 15% of my i5, Tegra 3 devices will hold a 40-50 fps on it, perfectly playable. It's ONLY 5%, but 5% of my i5 is like 25-30% of the total processing power of that quad core Tegra 3.

    Optimizations matter when we're dealing with a power constrained platform. Even IF your game is running at 60 fps on newer devices which you target for, optimizing it means the device would run it more efficient and thus generate less heat or consume less battery, something users on mobiles appreciate.

    Contrary to Ashley, for mobile development, with HTML5 already losing 50-60% of performance compared to native code, my mantra is to optimize it as much as possible.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)