Font Characters/Glyphs Over 512 Bound Size Will Cause An Infinite Loop in Threading Task That Results in Major Memory Leak

[stiefeljackal]

Describe the bug?

When certain properties are changed for font components, it causes a threading task to go into an infinite loop that will very quickly eat up the computer's available memory (roughly 1 GB per second). Exiting the world with the item in, forcing an asset cleanup, forcing a garbage collection, or deleting the offending item will not cause the task to stop. The particular font components that this occurs in are DynamicSpriteFont and StaticFont

For DynamicSpriteFont:

If the MaxSize property is more than 506, then the memory leak will occur.

For StaticFont:

Adjusting the GlyphEmSize, PixelRange, and Padding to higher numbers may cause a memory leak depending on the font. For the record, GlyphEmSize tops at 512, PixelRange tops at 64, and Padding tops at 16 despite entering a higher number than the specify maximum. This can easily happen with emoji fonts as well as the default Neos font type (neosdb:///c801b8d2522fb554678f17f4597158b1af3f9be3abd6ce35d5a3112a81e2bf39.ttf and neosdb:///bcda0bcc22bab28ea4fedae800bfbf9ec76d71cc3b9f851779a35b7e438a839d.otf)

For DynamicSpriteFont, it appears that Padding is always 1 and PixelRange is always 4. The glyph/character size will always be set to whatever MaxSize is set. This is why a MaxSize greater than 506 will cause the memory leak.

Bounding Box Size: 512 Glyph Size: MaxSize + PixelRange [always 4] + (Padding [always 1] * 2)

For StaticFont, the x and y values are flipped (so x becomes y and vice versa). In addition, you can change the Padding, PixelRange, and GlyphEm on the component. Depending on the font type, setting the three mentioned properties to high values will cause the Glyph Size to go over the 512 size value for height.

Bounding Box Size: 512 Glyph Size for Y: 570 [internal font size value] + PixelRange + (Padding * 2)

Relevant issues

None.

To Reproduce

WARNING: Performing these steps will produce a memory leak that will consume your RAM within a few seconds. You will need to close out of the client!

For StaticFont:

1. Cause the Root slot to produce the StaticFont components. Usually creating an Empty, double clicking the Controller slot and Root slot back and forth will cause them to appear.
2. Locate the StaticFont with neosdb:///c801b8d2522fb554678f17f4597158b1af3f9be3abd6ce35d5a3112a81e2bf39.ttf as the URL.
3. Set Padding to 16 or higher.
4. Set PixelRange to 64 or higher.
5. Set GlyphEmSize to 512 or higher.
6. Watch your RAM go up.

For DynamicSpriteFont:

1. Create an empty slot and add the DynamicSpriteFont component.
2. Set MaxSize to 507.
3. Add Glyph item.
4. Set SpriteURL to be any URL to a Sprite (plenty of sprites from Neos Essentials).
5. Set SpriteName to "ro".
6. Create the example UIX Canvas from Object > UIX Canvas.
7. Go to any of the Text Slots.
8. Change the reference for Font to the DynamicSpriteFont component we created earlier.
9. For Content, type "\<sprite name="ro">"
10. Watch your ram go up.

Expected behavior

No memory leak.

Log Files

No response

Screenshots

No response

How often does it happen?

Always

Does the bug persist after restarting Neos?

Yes

Neos Version Number

2022.1.28.13xx

What Platforms does this occur on?

Windows

Link to Reproduction Item/World

No response

Did this work before?

I Don't Know

If it worked before, on which build?

No response

Additional context

None.

Reporters

Investigation and Debugging:

• StiefelJackal

Original Group That Found the Initial Bug with DynamicSpriteFont:

• art0007i
• Lexevo
• DarkSurgar

[epicEaston197]

did I do something wrong? it's running perfectly fine

[stiefeljackal]

Did you look at your RAM utilization after doing this? It should be climbing up.

[epicEaston197]

Did you look at your RAM utilization after doing this? It should be climbing up.

no but Neos ran normally and smoothly I even kept it like that in my home World while i was World hopping