summaryrefslogtreecommitdiffstats
path: root/defaultopts.h
diff options
context:
space:
mode:
authorwm4 <wm4@mplayer2.org>2011-11-04 10:02:12 +0100
committerwm4 <wm4@mplayer2.org>2012-03-17 21:05:39 +0100
commitc67e1ba4a69cc2d843e1a8ba0379718fa2446d2c (patch)
treeac5c886bf4db8a1973816555b4ddbab6f569fd97 /defaultopts.h
parent6f02fb1cce94e42f4b2dc39aa508ff2f5c3e519a (diff)
downloadmpv-c67e1ba4a69cc2d843e1a8ba0379718fa2446d2c.tar.bz2
mpv-c67e1ba4a69cc2d843e1a8ba0379718fa2446d2c.tar.xz
vo_direct3d: refactor D3D initialization and reconfigure code
This simplifies the code and removes code duplication. There should be no actual semantic differences to the previous code. The only exception is that the new code doesn't query the display adapter's desktop pixel format on backbuffer resizing anymore. In my opinion the format can never change anyway, and if it does, it will cause the D3D device to become "uncooperative" and we will recreate it in flip_page. Remove attempts to handle d3d_device when it's NULL (outside of the initialization paths). d3d_device can only be NULL if recreating a D3D device, that was in "incooperative" state, fails. The current (and previous) code seems to assume that this never happens. It is unlikely that these NULL checks improved correct operation in any way, or at least they won't anymore after the recent changes done to the code. If it should be possible that a device can't be reset/recreated for a while (during display resolution changes? when another D3D application is in fullscreen mode?), another solution has to be found. It is unknown why the code recreates the IDirect3D9 interface when the device was uncooperative. At least on Windows XP + reference rasterizer, resuming works without recreating it. Leave this code just in case.
Diffstat (limited to 'defaultopts.h')
0 files changed, 0 insertions, 0 deletions