ddraw / wined3d fighting over the resolution!

[Peter Dons Tychsen]

Hello S.

I have studied this a bit more.
The app seems to do this purposely.

In any case wined3d should not change the mode in this case.
Either wined3d must detect this, or the code should be moved into
d3d8/d3d9.

On a similar note, i found i found a funny "RestoreDisplayMode()" call
in "SetCooperateLevel()", when switching from full-screen. I tested with
win-xp, and here this does not happen. This causes additional
mode-switch flicker.

I think i will chew on some nice German wine-gums (Haribo), 
and then send some patches :-). mmmmmm.... wine-gums.... they should
sell them on wine.org... would be appropriate... :-)

/p


On Thu, 2008-02-14 at 09:18 +0100, Stefan Dösinger wrote:
> Am Donnerstag, 14. Februar 2008 04:22:16 schrieb Peter Dons Tychsen:
> > Why does the SwapChain-destroy function play around with the resolution
> > at all. Is that really necessary? I think it should not do it if the
> > caller is ddraw at least.
> I thought I'm filtering this out in the case of ddraw, but maybe that got 
> lost. The reason why the swapchain restores the resolution is the different 
> way ddraw/d3d8 and d3d8/d3d9 set up the screen.
> 
> In ddraw the app calls IDirectDraw7::SetDisplayMode. This sets the mode. Then 
> it creates a DDSCAPS_PRIMARYSURFACE surface, which creates the swapchain.
> 
> In d3d8/d3d9 the swapchain controls the video mode
> 
> I think the problem is that RestoreDisplayMode is called before the primary 
> surface is destroyed. The question is why this happens. I can think of the 
> following reasons:
> 
> -> Refcounting problem, or the app just doesn't release the surfaces. Then 
> ddraw.dll destroys the objects on DLL_PROCESS_DETACH
> 
> -> The app calls it that way. This needs a test, but I think it is not allowed 
> to call SetDisplayMode / RestoreDisplayMode while a primary surface is around