Re: Photoshop 2023 flink

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 <[email protected]> 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 <[email protected]>
> wrote:
> >
> >>
> >>
> >> On Sat, Dec 7, 2024 at 10:51 AM Zhiyi Zhang <[email protected]>
> >> 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 <[email protected]>
>