I suppose you could test this theory by calling SetWindowPosition(), then moving and resizing the window under quartz's nose \[you can get the window handle with IOverlay::GetWindowHandle() as we often do in tests\], then seeing whether it renders into the window as-is or where the window used to be.
Good idea. Unfortunately it looks like rendering moves with the window. I'll recheck that I'm testing what I think I'm testing, but this seems pretty definitive.
Trouble is you still need to get to screen coordinates _somehow_. If you can't use ClientToScreen() you're in a bit of a pickle. In theory you can render to an arbitrarily deep child window \[granted, I haven't tested this\], but getting on the screen in ddraw requires blitting to the primary using screen coordinates. Unless I'm mistaken about that and there's another way?
That sounds right :/ It does give me the idea that maybe VMR7 is really supposed to use the ddraw clipper for this, perhaps via `IDirectDrawClipper::SetHWnd` on the child window. I don't know the details here, so maybe it's not workable but I'll have a look.
Ah! That makes sense. Fortunately I think 9585 will get us closer to that.
I didn't notice, very glad to see it!
In any case it probably makes sense to resend this merge request without the presentation bits. The rest is fine (well, after the GetFourCCCodes() usage is fixed) and we are getting a bit close to freeze.
Fair enough :thumbsup: -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9520#note_124603