Any suggestion on where to go from here? Does this need more discussion elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?
I'm having trouble understanding where I should be checking for this error and returning an the invalid call.
On Mon, Jul 21, 2008 at 9:28 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Ah, so it's essentially a recursive Reset call. My guess would be that we don't want to allow that, but it requires some tests on native win32 to verify. You could try returning WINED3DERR_INVALIDCALL when Reset gets called from inside another Reset call, to see how the application reacts to that.
This also raises another question regarding the window handling in wined3d: Are we allowed / supposed to modify the window size and position of the destination window the app supplies like this? A lot of apps seem to need that, otherwise the rendering is placed incorrectly or not visible because the window is hidden. However, it could be that Windows somehow renders correctly without changing the Window's properties.
So the SetWindowPos() call in Reset() might be the wrong thing here. It is not entirely unexpected that the app calls Reset when it receives a Window position / size change. If the Window size changes, the app is supposed to reset the D3D device, otherwise the rendering output is stretched in Present(which can look kinda ugly)