Re: [PATCH 2/5] ddraw: Use offscreen backbuffers.
On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote:
In principle this allows us to use more than one backbuffer in ddraw. It's also a requirement for the next patch. I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches.
d3d8 and d3d9 apps can request multiple backbuffers and access them explicitly just like ddraw apps can. In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself?
On 16 September 2011 01:03, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote:
In principle this allows us to use more than one backbuffer in ddraw. It's also a requirement for the next patch. I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches.
Maybe after 1.4, it's a bit more invasive to do it in wined3d. We don't want render the frontbuffer offscreen unless the swap effect is actually flip for performance reasons. However, the swap effect can potentially change when a reset happens. It's possible to make that all work, but I'd rather wait a bit to see how this works out for ddraw first.
In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself?
No, the wined3d frontbuffer and ddraw frontbuffer are different surfaces.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 16.09.2011 um 01:29 schrieb Henri Verbeet:
On 16 September 2011 01:03, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote:
In principle this allows us to use more than one backbuffer in ddraw. It's also a requirement for the next patch. I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches.
Maybe after 1.4, it's a bit more invasive to do it in wined3d. Works for me.
In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself?
No, the wined3d frontbuffer and ddraw frontbuffer are different surfaces.
Ok Another thing your second patch breaks is vsync because there won't be any swapbuffer calls. Although arguably that was kinda broken since we replaced flips with blits. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOcxQcAAoJEN0/YqbEcdMwHsEP/2zJIQZ66QbuYf7Z3hiqEZyh ZDKXVqvXZOy293Rd1xZPGPi98MSlFBmInnhL/8jRKAevpA0Bi/x0lhtxL3whHVky URhSqQQHErlNuvPS1kpAStf81QvTLQjA8KXLWa/5qNulxZl4a68I+K4H95dos7vO vZ+RAxSulYVm7hfbU5BqD5eFoTVQ6eEUAYRjxgy/hff0x7i3o4396BcnLukSFwLL YOA3zCR/8OO7WKEg/gibUFanc+jHAhostzf8krPL4voIwIli9oDln5SETekjbgZV TmG8c6334lWi7jTzWTfNPoHAgMhTiQb7KS6OB1zof6LwycbU7n50BzXHBb4lZ+g6 wW8ZIusZo9QRi97cxjsr/1BKS1s8W3x2TyMkq7W2TKJUByzO65GX8dygY2yZ1sCg YaYE/uKUXb5mzIgdhBVE+iD8e0+vxoDuryt5y94giOc0c2a+8hkO9GX7R0PNDUvT TmfxnsUgogjcJKiooTDytO+OqZU+/3pL0zjnX2zibaWGFhtyI8LYR+Vi1KYQjh5N j12dHZSK/jdD2uHFmR5t/a5JxisycOo96TdTe+/rLc89LeAuA9iB46t0q+siNnIB bmAzDa8/NwcStcWttl4RM1bcnRZTlKTHzxlm/WS5hRGQD8R+vzFelUEqcHNqiiO4 /WH9zBCc5fxorGtCHPEK =LFwI -----END PGP SIGNATURE-----
On 16 September 2011 11:17, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Another thing your second patch breaks is vsync because there won't be any swapbuffer calls. Although arguably that was kinda broken since we replaced flips with blits.
It was broken even before that, since it's set at context creation, while Flip tried to override it at the actual present call.
participants (2)
-
Henri Verbeet -
Stefan Dösinger