[Bug 59109] New: Final Fantasy XI Online: White flash upon game client launch.
http://bugs.winehq.org/show_bug.cgi?id=59109 Bug ID: 59109 Summary: Final Fantasy XI Online: White flash upon game client launch. Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs@list.winehq.org Reporter: chiitoo@gentoo.org Regression SHA1: 18339eb0f5048500efb668e6a9b679ed2f62d7a3 Distribution: Gentoo After 18339eb0f50 [1], when transitioning from the launcher, PlayOnline Viewer, to the Final Fantasy XI Online game client, there is a brief white flash where it used to remain black. This also causes white flashes when switching away and/or back to the game window when running in windowed mode, but it seems to be more a symptom of the commit blamed in 58491 [2]. Using the open-source amdgpu/mesa drivers, and KWin-X11. Last tested at d60f8286056 [3]. Thank you! 1. https://gitlab.winehq.org/wine/wine/-/commit/18339eb0f5048500efb668e6a9b679e... 2. https://bugs.winehq.org/show_bug.cgi?id=58491 3. https://gitlab.winehq.org/wine/wine/-/commit/d60f8286056559233e992c4084f3199... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |pgofman@codeweavers.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 Paul Gofman <pgofman@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Paul Gofman <pgofman@codeweavers.com> --- Took me a bit to figure out how to setup PlayOnline and add FFXI to it, but finally I managed. And observed that the described behaviour deemed as a regression happens on Windows. What I am doing is: - Start pol.exe in PlayOnline install directory; - Log in to PlayOnline (entering SQUARE ENIX password and one time code with pre-setup PlayOnline member); - Go to FINAL FANTASY XI; - Press Play; - Choose Play between Play and Back in consequent choice. That results in ESRB warning shown in the same PoL window, then that window is closed and new (actual game) window appears which is initially white on Windows but then quickly switches to black and then intro video starts. I observe exact same with current Wine. Without the blamed commit the game window appearing after Play is black at once indeed, and that looks more correct per se, but that's not what I see on Windows. So commit seems to be improving the compatibility in this case. Closing as invalid. In case I am missing somethings and there is actually an observable difference to Windows with the blamed commit could you please describe in more details how to reproduce and where the difference is? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #2 from Chiitoo <chiitoo@gentoo.org> --- That is interesting. I certainly can't remember it happening on Windows, but I haven't used it since 2010 for any personal use... though I did test this application there just a few years ago, to confirm that something happens there too, and not just with Wine, and either I didn't notice this then, don't remember it, or there's some hardware/driver dependency I perhaps. In any case, when I find enough {motivation,energy,time} to install Windows somewhere, I'll make a note of this then. Thank you! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #3 from Paul Gofman <pgofman@codeweavers.com> --- I was checking on Windows 11. Maybe if back then it was Windows 7 it could be different (while I don't expect that to be different at least with Win10). Also, something could've changed in the PlayOnline launcher or the game, the first thing it does after install is downloading update online. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #4 from Chiitoo <chiitoo@gentoo.org> --- I still had my previous testing install around, which is Windows 10, and I could indeed see the window go white first in windowed mode. However, in either of the full-screen modes, I don't see it (using the Borderless Window mode mainly), so I suppose there is still some kind of a difference somewhere. One difference here is that the version of the game I had installed from previous testing, and from trying to get the Japanese IME working, is the JP version, while from the ESRB screen I know you had the US version (or the EU version with no specific language selected in the very first PlayOnline Viewer screen) since it's only shown for the US version. The PlayOnline Viewer itself hasn't been updated since ages past, I believe, but the game client is indeed still being updated, and they definitely don't tell their customers everything they change. I suppose one difference here could indeed be the Windows 11 vs 10, though I forget if they announced any compatibility changes for 11 yet (that said, I might guess the "flash" doesn't happen on 11 either, aside from the Windowed mode). Not exactly sure what goes on at the point when transitioning from the viewer to the game, since I don't think it is just launching a new executable, but rather hook to another DLL or something (which is when the application icon is no longer correct, but the Wine icon, too). Unsure if there is something worth pursuing there, depending maybe if the flash is there in all modes on Windows 11, but any any case, thank you again, especially for going through the trouble to get that far into the game. I know it's an ordeal on itself especially for someone who is not familiar with it before. :] -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #5 from Paul Gofman <pgofman@codeweavers.com> --- So you confirm it is Windows behaviour in windowed mode. I only tried in default (windowed) mode, going to look what happens in fullscreen mode. -- 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.
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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #7 from Chiitoo <chiitoo@gentoo.org> --- I might have found something a bit less cumbersome to re-produce this with: Diablo / Hellfire (GOG): https://bugs.winehq.org/show_bug.cgi?id=59782 Currently there is an issue where the screen stays white, though, but before the change mentioned there, there are white flashes when moving between menus. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #8 from Paul Gofman <pgofman@codeweavers.com> --- I am not sure how exactly this bug is related? The apparent problem in that bug is that the rendering fails to update due to ddraw or else reasons, thus probably results in default window surface color showing up. The fact it changed to white maybe makes window more visible. For the essence of issue itself, also looks unlikely related, what is observed here in fullscreen mode is initial transition to d3d fullscreen and it is d3d8 while that bug is about frontbuffer update details beyond initial initialization with ddraw. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59109 --- Comment #9 from Chiitoo <chiitoo@gentoo.org> --- Related in that without this commit, there are no white flashes, and with it, there are. Not that this is related to the screen being white all the time there, that's a different commit as mentioned there, but I figured it might be useful since it doesn't require all the account shenanigans etc. -- 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.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla