Transparent textures are not transparent in MonoGame with Linux

Graphics
1

So I’m writing a terminal emulator using SpriteFonts for text rendering. It works perfectly on Windows, however on Linux I get a fair bit of graphical bugs.

We tested on two different distros. Arch Linux and Ubuntu 17.04. Both were running MonoGame 3.6 Stable with the mesa video driver. The system running Arch uses i3wm as a window manager. My Ubuntu system uses compiz as a window manager. Both systems run with extreme reliability.

The developer running the Arch system reported hieroglyphics displaying in his terminal where text wasn’t being rendered. He also reported the contents of other windows on the system being rendered in the game window anywhere where the terminal was supposed to be drawn. Finally, after a few consecutive launches of the game, his game failed to boot even after a clean rebuild of the entire solution.

This is a screenshot of the hieroglyphics he’s talking about:

Hieroglyphics
Hieroglyphics1920×1080

Note that everywhere where text IS rendered it is fine. It’s just where it isn’t rendered that it goes all Egyptian on us.

Although he reported other windows drawing inside the game window, he did not post a screenshot of it (possibly for security/privacy reasons in case really personal info would be captured.)

I also cannot post a screenshot of the effects on the Ubuntu system yet because it is not currently in front of me, but trust me - same build of the game, but the effects are way worse. And they’re reproducible. When I get home I’ll record a video of it in action and post it here. EDIT: I can post the Ubuntu version of the glitch.

The graphical effects seem to depend on what windows are open and visible on-screen (i.e which ones are in the same desktop workspace as the game, and which ones are NOT minimized.) In this one I could see the game’s console log (aka gnome-terminal) rendering inside the game mixed in with the in-game terminal’s text output.

Also, unlike the Arch screenshot above, this recording shows more severe layout bugs in the terminal - text simply does not get placed correctly. It seems to get shifted over by whatever outside window happens to render in the game.

Also, either my eyes were playing tricks on me or the Infobox that appeared to tell the user that the game uses cloud save features was also affected by the bug. If so, then this could be something even deeper than SpriteFonts as that message uses a different style of text rendering (pangomm and cairomm p-invoked by the game)

Here’s the code for this terminal emulator: https://gitlab.com/watercolor-games/the-peacenet/blob/monogame/ShiftOS.Frontend/Apps/Terminal.cs

Your attention is specifically drawn to the TerminalEmulator class where rendering actually takes place.

Are there any ways I can fix this issue? It seems to only be a thing on Linux. Any help would be greatly appreciated!

Edit 2: Worked around the bug slightly by drawing a box the same color as the current background color of the character in the terminal. I draw this box every time I come across a \n in the standard output, and the box starts at the position of the \n. It ends at the right edge of the terminal render area and is one char tall.

Edit 3: Considering renaming the thread to “Transparent textures aren’t transparent in MonoGame on Linux”. It seems that any time there’s alpha transparency in a texture, issues like these arise. Heck, the various icons in my UI which are rasterized FontAwesome icons (with transparent BGs if I may add) draw with black backgrounds. This is undesired and doesn’t happen at all on Windows.

2

Try disabling texture compression, Linux drivers are known to be very buggy with it.

3

How would I do that in code? Note that a lot of my textures are either created at runtime (as RenderTarget2Ds) or converted from System.Drawing.Bitmaps. All FontAwesome icons in the game are Bitmap resources converted to Texture2Ds as necessary.

So, the Content Pipeline is rarely (if ever) used in this game. That may change given that MonoDevelop doesn’t do resx files very well.

4

I can honestly say that this is not a common occurrence. This is the first I’ve seen this issue posted here. We have several devs using Linux, including Arch, and some games released on Linux such as Stardew Valley.

Looking at your code repo, I see a commit with the comment “Fix bug with terminal rendering”. Was it a bug in your code? Is this no longer an issue?

Another thing I noticed in the code was a thread populating the same text buffer that is used by the render method, without any thread synchronization or guards between the threads.

5

This commit was not targeted at fixing the bug. It was just to make sure that any \n characters written to the terminal actually created a new line instead of expecting \r to return the carriage to position 0.

Several commits earlier I also made it so when the game encounters a \n it draws a rectangle at the end of the current line to the right edge of the window and one at the next line from the left to the right. These rectangles match the background color of the current character.

They were introduced to MITIGATE the rendering bug in the terminal but do not actually fix it. For example when I made the commit, the bug was a lot less noticeable and persistent, but I could still see it.

Also, note the black backgrounds in the FontAwesome icons in the UI. Those aren’t supposed to be there. They’re supposed to have fully transparent backgrounds (and, in fact, they do on Windows.)

6

Its not something you do in the code, its something you do with the .mgcb files, but if the problem is occurring with textures you’ve created, you are probably just not filling them right.

This however did remind me of something…

I’ve had graphical glitches that are due to the video driver on Linux too many times to count.

7

@Watercolor_Games are you aware of how alpha blending works in MG/XNA? If you use SpriteBatch, by default it expects textures with premultiplied alpha. Shawn Hargreaves has some great write-ups about it: Shawn Hargreaves Blog Index

I know there was an issue before where loading textures through FromStream premultiplied alpha for GL and not for DX, not sure if that was still there in 3.6.

8

I’m quite aware of how alpha blending works with MG. I have the game (in most cases) set to expect nonpremultiplied textures. The only time I set it to expect premultiplied is when I’m drawing a RenderTarget (are they premultiplied? Not actually sure.) and when I draw the output of our Pango-based text renderer (Pango premultiplies the text when rendering.)

Perhaps the issue is with that first scenario with drawing RenderTargets as premultiplied textures?

1 Like
9

Just got the game to a semi-usable state in my development environment. If anyone has any clues as to how to actually fix these glitches (instead of just mitigating 'em) now’s the time to tell me :stuck_out_tongue:

10

Status update:

After moving some of the FontAwesome icons over to Content Pipeline and setting the processing to “NoChange”, I no longer see the black backgrounds. They’re perfectly transparent.

So we can knock that off as being a GDI+ bug in Mono. However, even though it’s a bit less prevalent now, the initial bug with the terminal is still present and annoying. It seems to be more sporadic and random. I’ve given up debugging this.

Edit: On second thought, just added a gfx.Clear(_bgColor) call inside the if(_resizing == true) statement in RenderText(). This helps mitigate the bug even more.

11

Happened in xna 3.1 setting a rendertarget with rgba 0 0 0 0 to the backbuffer i was able to actually see the desktop thru the game window fully…

Sounds similar.

try clearing the background with a color that has a alpha value of 255 (including black) especially if you have premultiplied alpha on.

check the font glyph area’s opacity or color against the transparency color key in the content pipeline could be the font itself.