http://bugs.winehq.org/show_bug.cgi?id=22290
Summary: PlayOnline viewer can't be resized in windowed mode Product: Wine Version: 1.1.42 Platform: x86 URL: http://dl.square-enix.co.jp/polus/setup.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wylda@volny.cz
Continuing "PlayOnline viewer" saga (previous bug 22197, bug 22145) i found out, that when running this app in windowed mode, it's window (not wine's) can't be resized. In other words if resized, than the window becomes black.
1. You need to apply not-yet-merged-patch for current git (wine-1.1.42-30-ga7d000e): http://bugs2.winehq.org/attachment.cgi?id=27235 (from bug 22197).
2. I did a regression test between 1.1.40-151-g78166b0 and 1.1.42-30-ga7d000e:
commit dc918d43946462ad4c04ed373cda72d1ebe9b6d3 Author: Stefan Dösinger stefan@codeweavers.com Date: Sun Mar 28 16:42:32 2010 +0200
wined3d: Use FBOs when the onscreen depth stencil format isn't suitable.
This allows proper support of float depth buffers when rendering to onscreen surfaces.
:040000 040000 44d70c59cce2f82aa3f2d8b6e19679588f81e1b8 15635de2c11dfbeb36cc3542bbaa6bc3f840468f M dlls
3. No other bug report suffers from this commit.
4. Revert of this patch on top of wine-1.1.42-30-ga7d000e makes that problem go away (again needs patch http://bugs2.winehq.org/attachment.cgi?id=27235)
5. Adding author of this patch to CC.
--private keyword: bisected
http://bugs.winehq.org/show_bug.cgi?id=22290
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=22290
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #1 from Wylda wylda@volny.cz 2010-04-06 14:18:41 --- Created an attachment (id=27246) --> (http://bugs.winehq.org/attachment.cgi?id=27246) Console log from wine-1.1.42-79-g770c9bc + Henri's patch
Adding console log. Attached log begins (triggered by) window resize.
Carrot for search engine:
err:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 1505
fixme:d3d:context_apply_state Activating for CTXUSAGE_BLIT for an offscreen target with ORM_FBO. This should be avoided.
err:d3d:context_apply_draw_buffer >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawBuffers() @ context.c / 1890
err:d3d_surface:read_from_framebuffer >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 1277
http://bugs.winehq.org/show_bug.cgi?id=22290
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #2 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-06 14:28:55 ---
fixme:d3d:context_apply_state Activating for CTXUSAGE_BLIT for an offscreen target with ORM_FBO. This should be avoided.
This is probably not the cause of the problem, but I am curious why it hits this codepath. Can you attach the output of glxinfo?
Can you also try to find out which d3d version this app uses? A +ddraw,+d3d8,+d3d9 log should give clues - just look at which channel shows activity after the app started up.
http://bugs.winehq.org/show_bug.cgi?id=22290
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #3 from Henri Verbeet hverbeet@gmail.com 2010-04-06 14:40:00 --- (In reply to comment #2)
fixme:d3d:context_apply_state Activating for CTXUSAGE_BLIT for an offscreen target with ORM_FBO. This should be avoided.
This is probably not the cause of the problem, but I am curious why it hits this codepath. Can you attach the output of glxinfo?
You can hit that from e.g. swapchain_blit() if the backbuffer format has fixups (P8, for example).
Can you also try to find out which d3d version this app uses? A +ddraw,+d3d8,+d3d9 log should give clues - just look at which channel shows activity after the app started up.
It's a ddraw application, note that the download isn't very large.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #4 from Wylda wylda@volny.cz 2010-04-06 15:01:27 --- Created an attachment (id=27247) --> (http://bugs.winehq.org/attachment.cgi?id=27247) Output of glxinfo
(In reply to comment #2)
this codepath. Can you attach the output of glxinfo?
I guess, that Henri replied for the rest you ask.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-06 15:39:33 --- Framebuffer_blit is supported, so we're falling back to the non-fbo blit path due to a conversion. I cannot think of a reason why it would hit this codepath though. If it is using P8, then it can't use D3D, and we shouldn't hit the backbuffer->frontbuffer swap "blit". And that's the only way a windowed ddraw app can end up in swapchain::present.
I'll download the app and look at it.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #6 from Wylda wylda@volny.cz 2010-04-09 05:36:48 ---
This bisected regression is still not fixed in wine-1.1.42-146-g1c02a90.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #7 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-09 10:51:03 --- The app fails rather miserably on MacOS, I'll try on Linux.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #8 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-09 14:52:33 --- Created an attachment (id=27304) --> (http://bugs.winehq.org/attachment.cgi?id=27304) Pol fix
The app uses a 32 bit depth buffer, which doesn't work with the D24S8 onscreen depth buffer we request from WGL(that's a bug on its own). So wined3d falls back to rendering the backbuffer offscreen.
Unfortunately, there's a bug in the context manager that activates FBOs in this situation even if the app actually tries to access the front buffer. No good. This happens when the app tries to blit the backbuffer onto the front buffer(it has to, it's the only way when rendering to a window in ddraw.
The attached patch fixes the game, but it does two things: First, it avoids falling back to offscreen rendering when the front buffer is requested as target surface. This fixes the GL errors, but doesn't fix the black screen.
Second, it allows the Present-instead-of-blit hack with stretching, since Present() can now do that. This should be done in a nicer way though. The present-blit hack should old be used when using backbuffer ORM or be removed entirely. It's an old hack that was needed to make windowed d3d7 useable on old drivers. Now that we have FBOs pretty much everywhere it's not much of a concern any longer.
I'm surprised that the context.c part doesn't fix the black screen. However, even if I force backbuffer ORM I get a black screen. Is this expected? Or yet another regression of top of the two known ones?
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #9 from Wylda wylda@volny.cz 2010-04-10 14:34:31 ---
Hi Stefan, good job with the patch. Resizing works again and you also removed all three "bonus points" mentioned at the end of bug 22197 (#c0)!
But if you want your patch to be perfect instead of good ;) there is probably one missed scenario. Move the app's window so, that 50% is visible (rest is behind the edge wine's windows, i.e. not visible). Now try to resize -> window becomes completely black again until you move it so, that 100% of app's is visible.
I guess that question regarding removal of ORM belongs to Henri, doesn't it?
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #10 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-10 16:34:59 ---
But if you want your patch to be perfect instead of good ;) there is probably one missed scenario. Move the app's window so, that 50% is visible (rest is behind the edge wine's windows, i.e. not visible). Now try to resize -> window becomes completely black again until you move it so, that 100% of app's is visible.
That's part of why the surface.c part of the patch(that actually fixes things) is incorrect. We still need proper backbuffer->frontbuffer blitting. But before we implement this I'd like to wait for Roderick's blitter fixes. Trying to hack this feature into the current code is futile.
I am still wondering why the context.c part doesn't fix window drawing. It should, but something's still wrong. That is the actual problem here.
I guess that question regarding removal of ORM belongs to Henri, doesn't it?
It was more a general remark for the archives. I think I discussed this with Henri a while ago, and we decided to keep the hack until the Mesa versions that support FBOs are more widespread. We also have to keep OSX in mind, since front buffer access isn't possible on OSX.
http://bugs.winehq.org/show_bug.cgi?id=22290
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Winehq@cnormington.plus.com
--- Comment #11 from Austin English austinenglish@gmail.com 2010-04-11 12:08:45 --- *** Bug 22335 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22290
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
--- Comment #12 from Wylda wylda@volny.cz 2010-04-18 05:45:19 ---
Component set to Direct3D.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #13 from Wylda wylda@volny.cz 2010-04-21 14:09:06 ---
This regression (bisected) is still present in wine-1.1.43-191-g7614656.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #14 from Wylda wylda@volny.cz 2010-04-29 06:08:37 ---
This regression (bisected) is still present in wine-1.1.43-347-gb939193.
http://bugs.winehq.org/show_bug.cgi?id=22290
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #15 from GyB gyebro69@gmail.com 2010-05-01 10:39:38 --- Star Trek: Klingon Academy (at least the demo, I tried) is also affected by this regression: since Wine-1.1.42 the game shows only a black screen upon starting, although music is playing and the game responds to keyboard and mouse input.
Regression testing resulted the same commit:
commit dc918d43946462ad4c04ed373cda72d1ebe9b6d3 wined3d: Use FBOs when the onscreen depth stencil format isn't suitable.
The patch in comment #8 solves the problem and the game can be started normally again.
Link to the demo (in case of testing): http://www.fileplanet.com/38260/30000/fileinfo/Klingon-Academy
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #16 from Wylda wylda@volny.cz 2010-05-10 14:36:22 ---
Well, the behavior changed and now in wine-1.1.44-72-g658209b. Initially the windows is displayed correctly and when i try to resize the apps window (not wine's) the content becomes upside down.
It's funny. You move mouse up and cursor goes down ;)
Also when moving such resized window, it's content moves asynchronosly with it's borders so inside picture is shifted so it does not full fill the bordered area :(
Patch in comment #8 mixed many things and apps behaved correctly, please reconsider sending of the patch. Things will get better here.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #17 from Henri Verbeet hverbeet@gmail.com 2010-05-19 11:53:49 --- Created an attachment (id=28088) --> (http://bugs.winehq.org/attachment.cgi?id=28088) patch
Should be fixed by 4889c33da6831a909e505229bc59cf64461617ec.
The attached patch should help a bit for the black border. We'll probably still want to fix BltOverride() to not do a needless software fallback though.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #18 from Wylda wylda@volny.cz 2010-05-19 12:55:32 --- Created an attachment (id=28097) --> (http://bugs.winehq.org/attachment.cgi?id=28097) pol.exe refresh problem when in windowed mode
(In reply to comment #17)
Should be fixed by 4889c33da6831a909e505229bc59cf64461617ec.
OK, this one puts that into before regression state. Can we continue to live here or open a new one?
GyB, you joined here. Is:
git checkout -f 4889c33da6831a909e505229bc59cf64461617ec
also OK for your comment #15?
The attached patch should help a bit for the black border. We'll probably still want to fix BltOverride() to not do a needless software fallback though.
Yes, the patch is good, content moves synchronously with it's window, but there is still one unfix scenario:
Move the app's window so, that 50% is visible (rest is behind the edge wine's windows, i.e. not visible). Now try to resize -> window becomes completely black again until you move it so, that 100% of app's is visible.
I would say, that this is some kind of refresh problem, because if you make just 50% visible, than move again so 60% of the window is visible, then newly visible 10% is not refreshed. Attachment shows that better.
Or this issue is the BltOverride() SW fallback you talked about?
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #19 from Henri Verbeet hverbeet@gmail.com 2010-05-19 13:06:32 --- (In reply to comment #18)
OK, this one puts that into before regression state. Can we continue to live here or open a new one?
Probably better to open a new one.
Yes, the patch is good, content moves synchronously with it's window, but there is still one unfix scenario:
Move the app's window so, that 50% is visible (rest is behind the edge wine's windows, i.e. not visible). Now try to resize -> window becomes completely black again until you move it so, that 100% of app's is visible.
I would say, that this is some kind of refresh problem, because if you make just 50% visible, than move again so 60% of the window is visible, then newly visible 10% is not refreshed. Attachment shows that better.
Or this issue is the BltOverride() SW fallback you talked about?
I think what happens is that the blit is rejected because it's partialy outside the screen. While moving the window to the outside that isn't very noticeable, but as soon as you move it back you see the now cleared parts of the window that don't get updated untill the window is fully inside the screen again.
http://bugs.winehq.org/show_bug.cgi?id=22290
--- Comment #20 from GyB gyebro69@gmail.com 2010-05-19 13:16:10 --- Star Trek: Klingon Academy now starts up correctly, using wine-1.1.44-322-g5cc00e8. The upside-down display issue also fixed now.
http://bugs.winehq.org/show_bug.cgi?id=22290
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #21 from Wylda wylda@volny.cz 2010-05-19 14:38:12 --- (In reply to comment #20)
Star Trek: Klingon Academy now starts up correctly, using wine-1.1.44-322-g5cc00e8. The upside-down display issue also fixed now.
OK, then let's continue at bug 22778. Feel free to add yourself to CC. I will be few days off (1 week?) so if you could take care, GyB, about retesting in case of new patch...
http://bugs.winehq.org/show_bug.cgi?id=22290
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2010-05-21 14:39:51 --- Closing bugs fixed in 1.2-rc1.
http://bugs.winehq.org/show_bug.cgi?id=22290
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |4889c33da6831a909e505229bc5 | |9cf64461617ec Regression SHA1| |dc918d43946462ad4c04ed373cd | |a72d1ebe9b6d3
-
wine-bugs＠winehq.org