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

[Jim Hauxwell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georgi Petrov wrote:
> Thanks Jim, I was just starting to work on this. I'll test it later
> today and report the results! Also I haven't seen the patch yet (and I
> don't know if you did it this way), but we need larger backbuffer
> allocation and changing of viewport later only for WinID >=0 case.
> Otherwise we're just taking more memory. I was thinking of two "resize
> paths" - one for WinID < 0 (the current one) and one for WinID >=0
> (backbuffer = fullscreen, changing of viewpin). Also there should be a
> check when upsizing in case the window is moved on a second display
> where the resolution is bigger, so if the window gets bigger than the
> backbuffer, a Reset is done to upsize it.

The backbuffer gets allocated to its largest supporting dimensions, not
to the size of the display, so moving it to another display should not
be an issue.

I take the point on the memory.  The memory is in the GPU or already set
aside for GPU activities in a UMA. so its not wasted.  If your max
surface dimension is 2k x 2k then in 32bit, this is 16MB.  Only a really
really low end system would have about this much graphics memory set aside.

Don't forget that on older systems the directx vo still works.  It's
only on Vista that this became an issue.  Can you see anyone running
Aero with only 32MB video memory?  I would also worry about other issues
on low end systems, such as texture throughput or texture support, there
is no fall back on OSD for example if you GPU doesn't support LA textures.

Even if you don't allocate the memory at the start, the user could load
a video that required that much space and then, crash! They are left
scratching their heads as to why it bombed out on them.

I do see the point, and I am not adverse to adding other code paths, or
anyone else for that matter.  I just think that the reason 'because we
can' is not always the best.  You should examine the arguments for and
against and come to a consensus.  Plus someone else can think of things
you haven't.

Jim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAklCH4QACgkQhrNWoHjgI1DD3ACVGiHSLkDSLun50ShqZ6Z+nqwW
CACePRtmChFyIulVBEeDlvrV5pK1bBY=
=UQop
-----END PGP SIGNATURE-----