This fixes black bars in warning windows in Arc Raiders and The Finals.
Those windows are dialogs and black bars are would-be scrollbars from edit control created with WM_VSCROLL | WM_HSCROLL. Later, however, before the control is actually shows, the scroll attributes are cleared with SetWindowLong during WM_INITDIALOG processing in custom dialog procedure, without SetWindowPos (... SWP_FRAMECHANGED). Under these circumstances, upon showing parent window the space for scroll bars is reserved but those areas are never actually painted. I extensively unit tested those aspects separately and that is Windows behaviour. Both on Windows and Wine those areas stay with whatever pixels are in the window surface previously (initially). E. g., if the parent window paints the background before showing client, those areas will have parent window background colour. However, the dialog class has NULL background brush and WS_CLIPCHILDREN.
I found that on relatively modern Windows at least that initial background is never black, as the test shows. What it actually ends up with through all the cases ultimately depends on window compositor and its window appearance effect. By default, the window surface will start with underlying windows colours and will be transitioned to window colour after inititial WM_WINDOWPOSCHANING / WM_WINDOWPOSCHANGED handling. Under normal circumstances the window should already be painted already. If it (or some parts of it) weren't, DWM will transition it to white colour. Removing DwmSetWindowAttribute( DWMWA_TRANSITIONS_FORCEDISABLED ) in test and adding various amount of sleep in WM_WINDOWPOSCHANGING instead of DwmFlush will deliver, depending on sleep time, intermediate colours between the image behind the window and white, settling at white. In practice, if trying to show window in a way similar to test but without explicit effect and composition disabling may result in various colours in that ranges, but with actual handling of paints and window initialization it looks like in practice it tends to end up in white (it is also that not skipping but default handling of those WM_NCPAINT, WM_ERASEBACKGROUND messages may also have some interference with this compositor behaviour).
So while we don't yet implement neither composition nor transition effects, I think ending up with white initial window surface is better default than black surface.