On 12/12/24 02:12, zhengxianwei wrote:
I think it might be related to this part of the PR. Offscreen rendering could be causing some states to not sync properly. However, I’m not very familiar with offscreen rendering yet, so I’m still reviewing this PR.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6427 https://gitlab.winehq.org/wine/wine/-/merge_requests/6467
On Sun, Dec 8, 2024 at 5:25 PM zhengxianwei baikaishiuc@gmail.com wrote:
On Sat, Dec 7, 2024 at 10:51 AM Zhiyi Zhang zzhang@codeweavers.com wrote:
On 12/6/24 17:19, zhengxianwei wrote:
Hello, I am trying to run Photoshop 23 using the DLL generated by
VKD3D-Proton.
I noticed that after opening an image, dragging it causes display
issues.
Here’s a video showing the problem:
https://www.youtube.com/watch?v=JgWrsFx4GrM < https://www.youtube.com/watch?v=JgWrsFx4GrM%3E (Because I have not been using the successful obs recording, so I switched to recording with my cell phone, the result is worse, sorry!)
When I capture frames with RenderDoc, the images appear normal.
I suspect the issue might be related to the desktop gui composition
process, but I’m unsure how to analyze such problems. Do you have any suggestions?
Looks like the `recent` window is fighting for z-order with its image window. Use spy++ and see if they're the same window.
I used Spy++ to check, and if my operation was correct, these are indeed two separate windows.
If there are different windows, then it might be some window manager/winex11.drv bugs.
You can also try running it on macOS with winemac.drv to check if it's
caused by WM.
This flickering only occurs when D3D12 hardware rendering is enabled.
I disabled vkd3d-proton’s d3d12.dll and d3d12core.dll, forcing Photoshop 23 into the software rendering process (CPU mode). The flickering during dragging disappeared. Does this indicate that the window management is not the issue?
After using spy++ to grab messages, I found that in cpu mode, there are many different types of messages (WM_ERASEBKGND, WM_MOUSEMOV, WM_MOUSEDOWN, WM_MOUSEUP, etc ) under the ps panel (the panel with the doraemon image), but in gpu mode, there is only WM_NCHITTEST, why is this?
I feel that in gpu mode, the ps panel seems to be drawn with some kind of canvas, and all the events, are taken over by some other mechanism, but I don't clear what that mechanism is?
Hi! Yes there's been some possible regression related to offscreening. We were previously not allowing vulkan surfaces to be created on windows with children, but that was only checked at creation time, and vulkan surfaces could be successfully created before the window got children.
This has been changed to implement vulkan child window rendering in a more general way, and windows with children are using offscreen rendering and being blit separately to clip the child windows out of the vulkan rendering area.
In some cases the children windows aren't actually visible and don't need to be clipped out. In addition, offscreen rendering is known to be bogus and the blit is also not synchronized with the rendering at the moment. It works in some cases, doesn't work well in others.
For the cases where the vulkan surface was created on a window without children, and which later got some invisible children added, it is indeed unnecessary to move the surface offscreen like we do now, and it causes a regression when the offscreen rendering doesn't work well.
You can try with https://gitlab.winehq.org/wine/wine/-/merge_requests/6998, which is supposed to fix that case by checking whether children windows really need to be clipped out or not, and by moving the surface back onscreen if it's not necessary.