diff options
author | wm4 <wm4@mplayer2.org> | 2011-11-04 10:02:12 +0100 |
---|---|---|
committer | wm4 <wm4@mplayer2.org> | 2012-03-17 21:05:39 +0100 |
commit | c67e1ba4a69cc2d843e1a8ba0379718fa2446d2c (patch) | |
tree | ac5c886bf4db8a1973816555b4ddbab6f569fd97 /loader | |
parent | 6f02fb1cce94e42f4b2dc39aa508ff2f5c3e519a (diff) | |
download | mpv-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 'loader')
0 files changed, 0 insertions, 0 deletions