Windows with transparent background color doesn't get repainted properly in OpenGL games

Issue Description:

  • an in game window shows a temporary “loading” component during startup
  • the “loading” component is replaced with the actual in_game component once the current window is returned from the Overwolf API
    • the in_game component has a transparent background (important) that covers the whole window and a smaller inner element that is shown to the user

If the below conditions are met, then the background of the in_game component will not be transparent but will retain what was painted previously. In this case it will be the “loading” component.

  1. The in_game component is not visible when it replaces the “loading” component (either visibility: hidden or opacity: 0 in CSS)
  2. The game that is running it using OpenGL.


The “loading” component is shown even though it was replaced by the in_game component

How it should look

The background will become transparent once it gets painted over. Some ways I found that paints over the background:

  • tooltips that pop up will paint over a portion of the background that they appear over
  • modals can paint over the whole window
  • alt tabbing away from and back to the game while the in_game window is visible causes it to repaint the whole window. It doesn’t get repaint if the in_game window is not visible.

Can you reproduce it (exact steps to reproduce):

  1. Download Osu! for testing because Osu! uses OpenGL and has a compatibility mode that runs Dx9
  2. Download the demo app from the github page at the bottom of the post. It’s a basic create-react-app that opens an in game window.
  3. npm i and npm run build to build it
  4. Load the app using Overwolf dev tools
  5. Run the app
  6. Open Osu!
  7. Wait for the “loading” component to go away.
  8. Press ctrl+x to show the in_game component.
  9. See the blue square with the “loading” component in the background as seen in the first screenshot above.
  10. alt+tab out and back into the game to repaint the background to get to the same state shown in the second screenshot.

You can repeat the above using a DirectX game and the bug will not occur. To set Osu! to use DirectX go to Osu!'s Options > Renderer > Compatibility mode and check that option. Then close and relaunch the app.

There is another way to see this bug, but requires dev tools:

  1. Do the steps above to the build demo project and Osu!
  2. Run the app, run Osu!, and open the chrome dev tools for the in_game component.
  3. While the in_game component (blue square) is not visible and Osu! is in focus, mouse over the root element in the DOM to paint the in game window blue. Then move your mouse off the DOM element.
  4. Unhide the in_game component with ctrl+x and it will look like below.


Do you currently have a workaround?
Yes, but it doesn’t fix the underlying issue. I can use a timeout to hide the in_game window after the initial render to make sure the whole window is painted over once.

However, this won’t fix cases where the bug is triggered after the initial render.

Please reproduce and attach a zip package of your OW client logs
Link to github page with reproducible demo: GitHub - fgfl/min-demos-non-transparent-bg-bug

Hi, and thanks for the feedback.

We will check the issue and we will update you here.


@fgfl Hi,

Before we are diving in - From the above description, I understand that:

the in_game component has a transparent background that covers the whole window and a smaller inner element that is shown to the user.

Note that this is not a good practice in general, as you should keep your windows small as possible.
When Overwolf renders transparent windows, it does its best to do it efficiently. However, large windows do have performance costs.

Can you please tell me why you choose to implement it like that and if it is a must-have?


Hi @eransharv ,

I’m working on the Insights Capture app. The in game component has a pop up to select an option when it is clicked. The pop up is taller than the component, so the window needs to be larger to accommodate the pop up.


Hi @fgfl, I can confirm that using your steps, I was able to see the “Loading” red window when the game is launched. After Alt+Tab once, it’s not happening again.

I understand that you attached a demo app that demonstrates the issue (much appreciated!). But what is the “real” app you are working on, and for which game are you developing it? For osu!?

Hi @eransharv , I’m working on “Insights Capture”. It’s a recording app so it works with all games. A small percentage of our user base does play Osu! though.

The demo mimics loading our in game window that has the record button.

And the issue is just on osu or other games as well?

I haven’t tried any other OpenGL game, so I don’t know if this happens for every OpenGL games.

But I am guessing this only happens on OpenGL games because running Osu! in DirectX does not cause this bug to appear.

I tried Hearthstone and Counter Strike, which both use DirectX, and I didn’t see this bug happen.

OK. I will forward this issue to our R&D. I’m not set the prioritization of this as high, obviously, so it may take some time to fix it. But we definitely investigate it, and I’ll update you here.

Thanks for the details and all the info!

Hi. The ETA for releasing the fix is in OW client version 0.176.
Stay tuned for our announcements, and anyway will eventually update this ticket as well.


Hey @fgfl,

We released the fix. Would you please check it on the Developers channel and let me know?


It looks like it’s fixed. I can’t reproduce it on my demo app or Insights Capture. Thanks.

1 Like