http://bugs.winehq.org/show_bug.cgi?id=59109 Paul Gofman <pgofman@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Ever confirmed|0 |1 Status|RESOLVED |REOPENED --- Comment #6 from Paul Gofman <pgofman@codeweavers.com> --- In borderless or fullscreen mode I could not reproduce the white flash on Windows 11, while it is present with Wine. The game creates window, shows it and then creates d3d8 device on it immediately, without even processing message queue, then starts presenting to it. After some debugging I think that initial window surface is still white on Windows but it is the matter of how that gets onscreen (while message queue is not processed between creating window and first d3d present). E. g., I could see the white flashing with dxvk's d3d on Windows in fullscreen mode (which doesn't make it a d3d bug or something fixable in d3d but indirectly suggesting that the white colour is also initially present on Windows in the window surface and it is only a matter of compositing the window and transitioning to 3d rendering). What happens with Wine is that the window surface (not initialized by game in WM_PAINT) always gets flushed before the d3d presentation can take place. The flush may happen either due to unrelated window / events manipulation when all the window surfaces get flushed, or if that is avoided (like it happens, e. g., with dxvk's d3d) it will be copied onscreen when deleting the window surface (due to client window now present) in apply_window_pos which moves surface bits onscreen if new surface is not present. So essentially we currently don't have a scenario how the current surface bits can avoid getting onscreen for a moment when client surface is created. I initially made a naive attempt to improve that (https://gitlab.winehq.org/wine/wine/-/merge_requests/9864) but quickly realized that it is going to break more than fix, the fact the client surface is created doesn't mean that the current surface image is not needed anymore, the actual 3d rendering may happen much later and the current surface image should remain onscreen until then. So, while my description and debugging doesn't yet cover every single bit of how it avoids the white screen on Windows, it looks apparent that it is on the mercy of the gore compositing details, which I am not sure we can properly replicate. I am reopening the bug, while right now I don't see a reasonable solution. Maybe it is going to be a bit easier once we have compositing / WSI in Wine, while that is a long way to go and even that will unlikely fix the bug per se. So for now I am going to leave this and see how broad the problem with white flashing is across the apps. If that appears to be high impact and if I won't get better ideas I will probably suggest revert for the offending patch (even though it still looks correcrt per se). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.