Custom fonts render with glitches on certain Windows devices

[Akurn]

Summary

• Issue: Text with custom fonts appear with artifacts/glitches on certain Windows machines.
• Phaser version(s): Phaser-CE v2.20.0
• Live example:
  • Phaser-CE: https://jsfiddle.net/Akurn/u3xb4rs2/ (the only one that shows the font glitch)
  • Phaser 3: https://jsfiddle.net/Akurn/58wbe6n7/
  • PixiJS 3: https://jsfiddle.net/Akurn/13u602wb/
  • Vanilla JS: https://jsfiddle.net/Akurn/2evyskft/
  • (I need to do a test on PixiJS v2 in case its also reproducible)
• What steps produce the bug:
  • View the JSFiddle on affected machines in the Chrome browser
  • So far we've replicated on Dell i7 laptops with Intel Xe integrated graphics chips running either Windows 10 or 11
  • Text between 10-29 px without a Stroke, seem to be affected more
• What should happen: Text should render cleanly
• What happens instead: Text renders with random chunks missing from the fill
• Screenshot:
  

Description

Hi all, we've been experiencing this strange text glitch when using custom fonts in Phaser-CE on some Windows machines (it's similar to these posted Chrome issues, caused by hardware rendering. And is also addressed when hardware rendering is turned off).

Even though this does appear to be a Chrome/Windows issue, the reason I'm posting it here is that I've tested this with various other Canvas 2D frameworks, and they all seem to circumvent the issue, as I only see it in Phaser-CE (yet to test PixiJS v2, but v3 is fine). Links to each version are listed above.

I plan to further investigate this issue myself when I get more time, but thought to post it here in case others have also experienced the issue, or have ideas of what it could be. Or maybe we need to replicate what other frameworks do, and patch Phaser-CE to address it.

The glitch only appears in Chrome on some Windows machines (i7 laptops with integrated Intel Xe graphics). Our company supplies these to some non-dev employees, and most or all are seeing this glitch. It does not appear on MacOS or Desktop Windows (with dedicated graphics chips). On the affected machines it doesn't matter the display drivers versions, Windows updates or Windows versions 10 or 11, all show the glitch. I suspect it's related to type of hardware, since our tested Desktops don't reproduce the issue.

The bug has been seen for over a year (since 2022). Haven't tested with other Phaser-CE or Pixi versions other than listed above.

More Symptoms

• The location of the missing chunks is inconsistent, refreshing or reloading the text object, can change the glitch locations, or even not show it
• Doesn't matter on the particular font (tested over 20 different custom fonts, both Google Fonts and custom loaded ttf)
• Larger text sizes (above 30px) don't seem to show it
• In certain conditions, the first text object doesn't have the glitch, but additional text objects can
• Changing font sizes also removes the glitch but only if the next font size is drastically different (within a few pixels, 1-4px difference, they can still be visible)
• Adding a text stroke (even very tiny like 0.0001) or rendering the text without fill, also avoids the issue
• The text possibly also needs word wrapping and a new line char (\n)

Current Workarounds

• Turning Off Hardware Rendering in Chrome prevents the issue: https://support.google.com/chrome/thread/2331445/chrome-displaying-font-problem?hl=en
• Calling text.updateText() after instantiation, also seems to prevent the glitches (our current workaround)

Suspected issues

It could be some memory issue related to BaseTexture in updateTexture method?

---

I plan to investigate this more, but thought to post it here first to gather some helpful clues or additional things to check or test

[samme]

Someone reported a similar issue in Phaser 3.

[iammatthewbirch1]

We've just had reports of the same thing happening, thanks for raising the issue

[photonstorm]

The Text Game Object is literally just a hidden canvas that uses fillText to draw the text to it. The Canvas API does all of the text rendering, strokes, etc. The canvas is then turned into a WebGL texture and uploaded to the GPU.

If disabling hardware rendering fixes it, then clearly something is very wrong in that combination of Chrome + GPU + Windows. The fact that resizing the text to a much larger size fixes it is curious. Doing that would cause it to resize the canvas it was using, re-draw the text, and re-upload it to the GPU. Perhaps this is triggering a certain size threshold (next power of two up, perhaps?) on the GPU?

Also, I wonder if mipmaps may cause this. I honestly can't remember if they're supported in CE, but if they are, I would try disabling them.

We definitely can't fix the root cause of the issue (i.e. whatever causes Chrome to nuke parts of the font), but maybe there is a combination of sizes, or a certain texture size/ratio that prevents it from occurring in the first place. If you were to run WebGLSpector on one of the 'broken' machines, you could profile a frame and inspect all of the textures on the GPU. I fully expect you to see the glitch in there, but you'd also get to inspect the rest of the texture properties, too. I still reckon this is related to the base canvas size that the Text object creates initially (which is driven by the text content)

[Akurn]

You've just made me realise I've overlooked the type of renderer in my tests. Currently I've only seen the issue via the Canvas renderer, but I now realise the tests in Phaser 3 and Pixi are likely using WebGL. So I'll need to do some more tests with WebGL vs Canvas2D once I get access to the broken machines again.

Thanks for all the replies and insight, already very helpful ❤️