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

��