On Tue, Jun 3, 2025 at 5:33 PM Zhiyi Zhang <zzhang@codeweavers.com> wrote:

On 6/3/25 17:02, zhengxianwei wrote:
> Hello,
>
> I would like to implement part of the logic within |dcomp.dll| in order to properly support applications that depend on it.
>
> I found that Zhiyi Zhang has implemented some data structures and interface stubs:
>
> https://gitlab.winehq.org/zhiyi/wine/-/commits/directcomposition?ref_type=heads <https://gitlab.winehq.org/zhiyi/wine/-/commits/directcomposition?ref_type=heads>
>
> Among these, the only method with actual logic appears to be |IDCompositionDevice::Commit|.
>
> However, after reviewing the implementation, I suspect there may be an issue with the current approach.
>
> It seems that Zhiyi Zhang starts a separate thread for each |IDCompositionDevice|, and this thread runs at a fixed refresh rate.
>
> But this approach appears to introduce a problem: from the window's (|HWND|) perspective, there are now *two threads* concurrently updating its device context.
>
> This results in a frame sequence similar to the following (note: the frame intervals are illustrative only):
>
> gdi_frame | dcomp_frame | gdi_frame | gdi_frame | dcomp_frame
>
> In this model, GDI-generated frames and DComp-generated frames are interleaved.
>
> Is my understanding correct?

Hi,

This is indeed possible. However, this only happens when the window is using both GDI and d2d/dcomp to render the window. Normally, it's either
GDI or d2d and then composited by dcomp so usually this doesn't happen

In a normal Windows system, GDI output is processed by DirectComposition (DComp).

However, in Wine—at least based on your code—I feel you haven’t enforced the serial relationship between GDI behavior and DComp behavior.

You simply started a thread composite_proc, which, at fixed intervals, pulls a surface from the visual’s swapchain and copies it to the HWND's DC.

But if the HWND itself performs a repaint, such as in response to a WM_PAINT message, that GDI repaint behavior bypasses your logic entirely and flushes directly to the screen.

Here's a diagram illustrating what I believe the correct behavior should be under Windows:

```

gdi
\
dcomp -> dwm.exe
/
d2d

```

But in your current implementation, it behaves more like this

```
gdi ------------------> dwm.exe (flush_window_surface)
↘ ↗(bitblt)
dcomp (composite_thread_proc)
↗
d2d

```

It’s just that GDI’s own repaint behavior seems to be rarely triggered, so your DComp logic appears to work mostly fine in some smaller cases.

That’s just my understanding—I haven’t done any thorough debugging of your code