-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-04 08:56, schrieb Henri Verbeet:
We never render directly to the front buffer, and in case of e.g. a P8 front buffer, we would fail surface creation if we were to enforce format restrictions.
This patch uncovers a problem I am not quite sure how to solve.
We set the frontbuffer as render target in wined3d_device_init_3d if there's no backbuffer, i.e., when ddraw is used. In theory this doesn't matter because we're not rendering to it, just blitting.
Similarly, dlls/ddraw/device.c calls set_render_target to set the ddraw frontbuffer on release. The call fails now, but that doesn't cause any visible problems yet. There is a zombie wined3d surface left, but it goes away on ddraw shutdown or when a new ddraw IDirect3DDevice is created.
However, when we create wined3d textures for standalone surfaces, the ddraw surface isn't destroyed until the wined3d surface goes away because we're waiting for the callback. This keeps the ddraw surface alive as well.
The ddraw tests notice this because keeping the IDirectDrawSurface alive means keeping an IDirect3DDevice1 alive as well. The device holds a reference to the attached viewport(s), which triggers a failure in the ddraw1 tests.
The test failure was lingering before, I fixed this by adding a similar set_render_target call to ddraw_surface_release_iface_destroy. See the attached patches for reference.
The easiest solution seems to create a separate dummy render target that ddraw can use to unset application targets. That still leaves the problem that we're initializing wined3d with an invalid render target now.