[r210] Zooming in on text causes draw calls to skyrocket

Problem Description

It seems that Construct 2 (Or maybe just the browser itself) struggles to render very large text characters, with draw calls steadily increasing, eventually crashing the browser. In C2, this manifests when zooming in on a text object, and presumably also when text size is increased to very large values.

I'd wager that this isn't a problem that you'll be able to fix (I'm sure browser aren't design with super large text rendering in mind) however I think it would probably be a good idea to at least force the engine to stop rendering text when it's drawn over a certain size, to prevent very mysterious crash issues.

Attach a Capx

I can't seem to attach a file, here's a link: C2 text zoom bug

Description of Capx

Zooms in on a text object

Steps to Reproduce Bug

• Run the capx

Observed Result

Increasing draw calls, browser crash

Expected Result

Normal zooming

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

Win 8.1 64bit

Construct 2 Version ID

r210

This is to do with the way text is rendered in WebGL mode. Since WebGL provides no features to render text, a text object does the following:

1. Create a normal 2d canvas.

2. Render text with the 2d canvas (since that is a capability canvas2d has, but not webgl).

3. Create a WebGL texture the size of the object.

4. Paste the 2d canvas in to the texture.

5. Render the texture like a sprite.

This is a pretty well optimised process - it only does that when the text changes or its size changes, and the rest of the time it's basically a Sprite. Normally it's also only operating on small rectangles.

The problem is when you zoom in it increases the detail of the text by creating a larger texture - the size of the object in screen space and rendering larger text (so as large as the object would appear if your monitor were large enough to display it all). If you keep zooming in, you end up creating huge textures. Worse if you are zooming in a bit further every tick, every frame it will run the whole process again, including creating a new texture.

So this is by-design for high-detail text. The best thing to do would be to use SpriteFonts, or, er, not zoom in on text that far. I guess I could put in a max detail level clamp though so it doesn't explode. I'll leave this bug open for that.

This is only tangentially related, but I'd love if someone could answer.

As a mobile dev, I only ever use spritefont and never really use normal text, so I have to ask - what is the advantage of using normal text?

The problem is when you zoom in it increases the detail of the text by creating a larger texture - the size of the object in screen space...

Wouldn't make more sense if the texture size was based on the object size in layout coordinates? This would avoid things blowing up.

Elliott Off the top of my head, the main advantage would be ease of use (don't need to manually put together a proper spritesheet and set character spacing etc). Other advantages would be lower graphics memory usage (presumably, although if it's pasting to super large textures this might be negated) and perhaps dynamic bolding/styling etc, as well as the fact that it's vector based so you can render large text without blurriness - although this can have bad implications as revealed by this very topic!

This is only tangentially related, but I'd love if someone could answer.

As a mobile dev, I only ever use spritefont and never really use normal text, so I have to ask - what is the advantage of using normal text?

I advise against using regular text instead of spritefonts. It might look better but if the user isn't able to load the font properly (and this can happen for a bunch of different reasons) it will most likely make some things in your game unreadable.

Spritefonts aren't that hard to get used to - thanks to this tool made Blackhornet you can pick a font and it will convert it so C2 uses the right spacing and everything.

Game rule xxxxx3: "don't zoom text"

Alrighty

sqiddster

I would never use Text objects unless I had too. Perf issues, formatting issues, compatibility issues...bleh...

That being said, spritefonts were a pain too...until Blackhornet made GYFM:

The best thing about GYFM is that it generates a JSON file that can be used to automagically configure your spritefont to the correct kerning.

> The problem is when you zoom in it increases the detail of the text by creating a larger texture - the size of the object in screen space...

>

Wouldn't make more sense if the texture size was based on the object size in layout coordinates? This would avoid things blowing up.

Layout co-ordinates don't change as you zoom in. So this would mean as you zoom in to text it becomes blurry or pixellated, instead of increasing detail. It would look the same as putting some text in a Sprite object and zooming in very far.

I could perhaps add that as an optional mode for the Text object? Something like a 'Upscaling quality' property which can be 'Low' (no detail increase, goes blurry as you zoom in, but uses less memory) or 'High' (as it works now, increases detail but can use lots of memory).

Ashley that sounds like a good idea!

Is it possible to remove the letters that aren't visible on screen? If I understand the explanation on how it works, it is creating a texture for the entire string? If letters are off screen, I would think removing those would allow smaller texture size?

Prominent - it's an option, but it could actually work out slower in some cases. Right now if you zoom in a long way then scroll around, it's just moving around a large texture as if it were a sprite, which is fast. If it cropped the texture area to the size of the screen, then scrolling around will need to keep updating the texture, and texture updates are slow (especially every frame, hence the poor performance when zoomed in a long way in the example in this thread). So really it's just another tradeoff between memory use and performance, and isn't necessarily always better. Also given that it would probably be very tricky to implement that correctly (especially when layer scaling and rotation gets involved!) I'm not sure it's worth the trouble.

hm.. yea, that makes sense.

thanks for the explanation!

Layout co-ordinates don't change as you zoom in. So this would mean as you zoom in to text it becomes blurry or pixellated, instead of increasing detail. It would look the same as putting some text in a Sprite object and zooming in very far.

Yes, I probably expect more that this happens than the memory exponentially increasing due to zoom.

I could perhaps add that as an optional mode for the Text object? Something like a 'Upscaling quality' property which can be 'Low' (no detail increase, goes blurry as you zoom in, but uses less memory) or 'High' (as it works now, increases detail but can use lots of memory).

It's an option. However I would prefer if the texture was always based on layout coordinates and there was an additional parameter to set the texture's max level of detail. An integer like 2x, 3x... the size of the object in layout coordinates, with the texture size capped at 2048 or 4096 px to avoid crashing. This would mean that the text could be zoomed 2x, 3x... without looking blurry.

The Tiled background also misses something like this, but more like a texture scale parameter similar to how the sprite font has. If you are designing a game with double size textures (to look crisp when the game is scaled to bigger screens), sprites looks crisp while tiled-backgrounds looks blurry. Currently only sprites allows double size textures while tiled backgrounds textures are limited to always be 1:1 to layout coordinates.

The Tiled background also misses something like this, but more like a texture scale parameter similar to how the sprite font has. If you are designing a game with double size textures (to look crisp when the game is scaled to bigger screens), sprites looks crisp while tiled-backgrounds looks blurry. Currently only sprites allows double size textures while tiled backgrounds textures are limited to always be 1:1 to layout coordinates.

yeah, thats super anoying, i had some cases where i had to use several sprite objects instead of one tiledbackground

+1 for scale on tiled background and 9 patch