**5/9**
Oh, right, this is the bug where the game hooks a bunch of stuff. So do we expect that this change is a no-op in the absence of hooking?
Effectively yes.
After looking into it some more, I'm not so convinced that we want to do this, though. It looks like we can't depend on `GetClientRect` giving a proper origin (which BTW I think is supposed to always be at (0,0)? At least MSDN is very explicit about it), while `ClientToScreen` just returns `FALSE` for the video child window. Maybe using `presenter->native_size` and / or `info->szAspectRatio` is more proper?
I think those are supposed to be the original size of the video. We want the size that's actually going to be displayed on screen, which may be stretched to match the window we're rendering into.
I'll probably try something along those lines.
Actually I'm starting to think that the interesting info is supposed to be stored by the VMR filter during the `VideoWindow_SetWindowPosition()` call and then passed to the presenter via `info->rcDst` in `PresentImage()`.
Hmm. rcSrc/rcDst look like they're supposed to come from rcSource/rcTarget in VIDEOINFOHEADER, but at least in renderless mode they don't. Maybe in windowed mode they should be used like that. I'm not sure. SetWindowPosition() IIRC takes the window rect, so we would need to account for that. But it's plausible. 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. Of course, you might also get the same effect by just calling GetWindowRect() then AdjustWindowRect(). 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?
**6/9**
It doesn't look like RE2 calls that function, not sure if there are other ways to get there? I don't see `IVMRAspectRatioControl` being queried either. Hacking the vmr7 tests it seems to confirm that the default is to stretch (I guess you already knew this), but the game on Windows has the letterboxing. I'd be curious about the window dimensions on Windows, but I suspect that peeking into that is a step too far.
This is more of a problem though. I don't think we want to be changing the default AR mode. Is there a different path that we could be using to get the image onto the screen, one that might also be hooked by the native ddraw? \[and that might also sidestep the GetClientRect() issue...\]
I think I figured it out. The game window is 320x240 fullscreen while the video is 320x160. VMR is set up in windowed mode. The game calls `VideoWindow_SetWindowPosition(..., 0, 10, 320, 160)`, which would center the video vertically when accounting for the caption bar that the parent (ddraw, fullscreen) window is supposed to have. But we tweak the window styles when entering fullscreen and the game doesn't expect or check for that, so the child window ends up higher than it should be.
I don't think there is much we can do upstream for this one until we figure out some way to stop messing with window styles in wined3d.
Ah! That makes sense. Fortunately I think 9585 will get us closer to that. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9520#note_124586