[MPlayer-dev-eng] [PATCH] - No Reset of D3D device on resize

[Georgi Petrov]

I attach the final (IMHO) patch. I used Jim's patch as a starting
point. I use this algorithm:

0. Create backbuffer with monitor's dimensions. This allows for smooth
resize up to current monitor's dimensions (only change viewport).
1. On each resize, compare current backbuffer's dimensions relative to
the new vo_dwidth/vo_dheight. If the backbuffer is larger (most
cases), just set a new viewpoint. If it's smaller, grow it and reset
the D3D. All subsequent shrinks relative to the new grown dimensions
are fast (change viewport).
2. The backbuffer is only grown. No shrinking is ever done. This
ensures smooth shrinking once the backbuffer is enlarged. We enlarge
it only as neede (unfortunately by doing reset).
3. If the movie is larger than the monitor's dimensions, only one
reset will be done (to grow the backbuffer). It's not noticed by the
user at all. If the movie is smaller than monitor's dimensions (most
cases), no reset is done. If the movie is resized to a xinerama-like
configuration (larger than current monitor), only one reset is done.
The user will not notice it, as it will happen only once. All
subsequent shrinkings are only viewport changes.
4. Once the backbuffer is grown, each resize, which is a subportion of
it, uses only viewport for speed (the rationale behind this patch as a
whole).

This way we accomplish 4 tasks:
0. Ensure smooth resize for virtually 99% cases (resizing on the
current monitor).
1. Ensure no reset when going / coming back from fullscreen.
2. Ensure dynamic backbuffer growth if for some reason the window
becomes larger than the current screen. All downsizing afterwards is
fast (viewport change).
3. Take up only as much memory as required. Typical 1280x1024x32bit
backbuffer takes up only 5,1MB video RAM. Even in xinerama
configuration with two such displays, this is 2560x1024x32bit = 10,2MB
video RAM.

I think that such behaviour is fully acceptable. The ONLY downside is
that once the window is grown beyond current monitor, each upsize
requires reset (as it's larger than the previously grown backbuffer),
but I think we can live with that, because this will be used by 1% of
the population and still it's not that big drawback relative to what
we win.

Further possible optimizations (not needed really):

0. Detect xinerama in the beginning and set the initial backbuffer
size accordingly. Not really needed, because after we know the movie's
dimensions, we test if the backbuffer is smaller and grow it before
creating the device. So this conditions is handled.

1. On each upsize bigger than current backbuffer (multiple resets
needed, like the current implementation before the patch), set the new
backbuffer dimensions slightly bigger than the current request, in
order to avoid some of the resets. Grow the backbuffer with (current /
2) size for example. We win fewer resets and lose potentially more
allocated memory.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: smooth_resize.txt
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081213/9159d40b/attachment.txt>