http://bugs.winehq.org/show_bug.cgi?id=49055 realmaitreal@deadmail.lat changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |realmaitreal@deadmail.lat --- Comment #2 from realmaitreal@deadmail.lat --- Created attachment 81735 --> http://bugs.winehq.org/attachment.cgi?id=81735 testcase: viewport-scoped Clear() escapes the viewport on a presented additional swapchain Attaching a self-contained testcase that reduces this to one wrong pixel. The defect does not look WPF-specific. Once a swapchain created by CreateAdditionalSwapChain has been presented, a Clear(0, NULL, D3DCLEAR_TARGET) -- which D3D9 scopes to the current viewport -- repaints the whole back buffer instead of only the viewport. The testcase sweeps {IDirect3DDevice9, IDirect3DDevice9Ex} x {D3DSWAPEFFECT_COPY, D3DSWAPEFFECT_DISCARD} x {implicit swapchain, additional swapchain} x {Present, no Present}, with a fresh device and window per case (sharing either one between cases masks the failure), and reads pixel (10,10) after: SetViewport(0, 0, 400, 300); Clear(0, NULL, D3DCLEAR_TARGET, red) [optionally] Present() SetViewport(100, 100, 100, 100); Clear(0, NULL, D3DCLEAR_TARGET, blue) (10,10) is outside the second viewport, so it has to still be red. Twelve of the sixteen cases pass. The four that fail are exactly those where the render target is an additional swapchain's back buffer and a Present has happened -- they read blue, i.e. the second clear reached the whole surface: Device9 COPY implicit no present (10,10)=0xff0000 ok Device9 COPY implicit after present (10,10)=0xff0000 ok Device9 COPY additional no present (10,10)=0xff0000 ok Device9 COPY additional after present (10,10)=0x0000ff FAIL Device9 DISCARD implicit no present (10,10)=0xff0000 ok Device9 DISCARD implicit after present (10,10)=0xff0000 ok Device9 DISCARD additional no present (10,10)=0xff0000 ok Device9 DISCARD additional after present (10,10)=0x0000ff FAIL Device9Ex COPY implicit no present (10,10)=0xff0000 ok Device9Ex COPY implicit after present (10,10)=0xff0000 ok Device9Ex COPY additional no present (10,10)=0xff0000 ok Device9Ex COPY additional after present (10,10)=0x0000ff FAIL Device9Ex DISCARD implicit no present (10,10)=0xff0000 ok Device9Ex DISCARD implicit after present (10,10)=0xff0000 ok Device9Ex DISCARD additional no present (10,10)=0xff0000 ok Device9Ex DISCARD additional after present (10,10)=0x0000ff FAIL 4 failing case(s) Neither the swap effect nor Device9 vs Device9Ex changes this, so the two things that arm it are the additional swapchain and the preceding Present. Same result for i386 and x86_64 builds of the testcase. It is not perfectly deterministic: in roughly one run in eight, one of those four reads correct. No case outside those four has failed here, over a dozen runs on each architecture. Why this matches the reported symptom: WPF's MilCore composes through exactly that path -- Direct3DCreate9Ex, CreateDeviceEx, then one CreateAdditionalSwapChain per HWND with D3DSWAPEFFECT_COPY, clearing per-viewport rather than per-surface and presenting partial rectangles. So the client area ends up holding the last clear colour, and moving the pointer over a control repaints that small region and makes it appear -- which is what comment 0 describes with the 'info' icon. It also explains why DisableHWAcceleration works around it: the software rasteriser never creates a wined3d swapchain. Environment: wine-11.14 on macOS 15 (winemac.drv, OpenGL renderer, Apple M2 via Rosetta). To be upfront about the tree, this is a local fork carrying patches in ntdll and winemac.drv, none of them touching d3d. I rebuilt dlls/wined3d from unmodified wine-11.14 source, with and without wine-staging 11.14, and the results above are unchanged in every case. The original report is x86-64 Linux and I have not been able to check there, so it would be worth someone confirming the testcase on Linux -- it builds with mingw and runs in a couple of seconds. As a sanity check on the testcase itself, the identical binary run against a non-wined3d d3d9 implementation on the same machine passes all sixteen cases. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.