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 (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? Software information
Photoshop23 System information
- GPU: GTX 1070ti - Driver: 535.183.01 - Wine version: 9.2 (latest, not proton-wine) - VKD3D-Proton version: (latest)
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 (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. 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. Then if they're the same window, then there might be bugs in d3d/d2d, for example, related to clip distance etc. You can try reproducing a renderdoc record on Windows and turn on traces like +d3d,+d2d,+d3d11,+dxgi,+winediag. Find out what the application uses for rendering the window then focus on that area. Also, try to figure out what dragging did that might be related the bug. For example, is it sending new messages? what if I filter out some of those messages? what if I filter out the calls to render the dragged icon? etc.
Software informationPhotoshop23
System information
- GPU: GTX 1070ti
- Driver: 535.183.01
- Wine version: 9.2 (latest, not proton-wine)
- VKD3D-Proton version: (latest)
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?
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?
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.
Thank you very much for your suggestions.
However, it still doesn’t work, and the issue is the same as shown in my video.
That said, I’ve learned a lot about the basics of offscreen rendering from your reply.
It seems like its Windows messages are a bit chaotic, often rendering the background layer over the foreground. It feels like the background layer assumes there’s nothing on top of it.
In theory, with a window style like CLIPCHILDREN, overlapping regions shouldn’t be rendered.
I’d like to know how you typically analyze these kinds of issues. For instance, when you suspect something went wrong, how do you output intermediate rendering results? Are there any debugging methods you recommend?
On Thu, Dec 12, 2024 at 9:09 PM Rémi Bernon rbernon@codeweavers.com wrote:
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.
-- Rémi Bernon rbernon@codeweavers.com
-
Rémi Bernon -
zhengxianwei -
Zhiyi Zhang