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> (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>