[PATCH 1/4] d3d9/tests: Add a windowed GetFrontBufferData test.

Stefan Dösinger stefandoesinger at gmail.com
Wed Jul 15 06:58:38 CDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2015-07-15 um 13:23 schrieb Henri Verbeet:
> I didn't review the entire set, but that's a problem. I think 
> flip_surface() is incredibly ugly, fragile and probably broken in
> some way. I would very much like it to go away, so I don't think
> anything that expands its usage is much of an improvement. 
> ddraw_surface7_Flip() doesn't exactly make me happy either, but at 
> least it only swaps complete surfaces and views, instead of
> depending on all kinds of wined3d internals. Not invalidating
> basically everything is probably a good thing too.
Yeah, it's ugly, but in the patchset I kept it for now because there
are plenty of other problems to solve as well. How we flip the
surfaces or surface contents is fairly easy to separate from the rest
of the issues we need to fix.

One idea would be to swap the swapchain resource pointers (and render
target views if one of the buffers is currently assigned) and have a
callback that tells the client libraries to re-fetch the wined3d
objects for its front and back buffers. The lucky part is that render
targets aren't stored in stateblocks in d3d8/9. I have done absolutely
no investigation how well this would work with d3d10/11 yet. The
expected problem is that in d3d10 the swapchain textures can be part
of any number of views and they all need to be updated.

I don't think controlling everything from the client library (the
current ddraw_surface7_Flip way) works without having the shadowfb in
the client library as well.

The other option would be to restructure the FBO cache to store GL
textures instead of surfaces to make the GL texture swapping scheme
more efficient. That won't fix the remaining ugliness of flip_surface
though.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVpkruAAoJEN0/YqbEcdMwBa4P/iplzdKoooOiIW8ia0rOH+qE
KkJlTC21UcPlQOPYD9IGkiGQzIlhPYZidf6swZzD+t4a8OEjmE2LytnfHdMinatA
yUJhvMCBSBmUKrDGSK/S/BaT47cYlkXfDdmCxUKeGq0tiptXKo+HQh4H2ZVx3ktf
x3DBlWw1fzd/57ZqoeojAF7bQ5NyhSCO5dKOcmAgdqxte61Y1/24Lnjt4M1LRlgZ
1aWhTksmA2voF44r9jhrJKSMyHobWWWsvq8X4+1KZD0mcdBnkhdH2MKgYntfqSMc
G2GMEQbHuH6+IcnbskB0PTs/XGOSIJu7PpSVvQIdIea3Qj92rYfW/CbqJEcTRg2z
0OlVaST7x+AZvD9PNd0y2ihLxwGUkJ0GSatXBbDzsp3b3h9WsoIwJvEoRZje2uVQ
QzVN4+oO1OPYnjYCbz4dARhziPoDlD4ZBHMCb7xjelsblx7CbkPbBxsgrlSJQPIO
LEUWJ8om5lQkE1E0zg3AczIUyUcWakZoJnXOdV2nxXadr7geOzWmGQK42+jectg7
L9ZpL78jR9WsumbROQCNVmSZjnqiBWPuO5nbIca8xvZPcXQeCv8mCWzr2F4uskqU
g0pCTV78ptKmtVN431yLyrZlV49aN/nekLXyK5+Gd1Rd4xlkUuOU1gtYgPzqGGaF
uasFlKSwUiKyC3NG6SX0
=0oMe
-----END PGP SIGNATURE-----



More information about the wine-devel mailing list