GNOME Bugzilla – Bug 697868
d3dvideosink: fix scaling with some drivers
Last modified: 2018-05-04 08:41:23 UTC
Created attachment 241343 [details] [review] d3dvideosink: fix scalling with some drivers The back buffer should have the same size as the rendering window so scalling is done in StretchRect from the offscreen surface to the back buffer using the bilinear filter. If not, scalling happens from the backbuffer to the rendering window outside the sink, which is not correctly filtered with some drivers.
This do not apply in master anymore and won't work after: d3dvideosink: Implement a buffer pool that shares D3D surfaces with upstream Resizing requires resetting the device and all the resources allocated to this d3d pool if we use the default pool. I believe that using a managed pool instead allows resources to persists in a device reset: http://msdn.microsoft.com/en-us/library/windows/desktop/bb147168(v=vs.85).aspx "Use the D3DPOOL_MANAGED flag at creation time to specify a managed resource. Managed resources persist through transitions between the lost and operational states of the device. These resources exist both in video and system memory. A managed resource will be copied into video memory when it is needed during rendering. The device can be restored with a call to IDirect3DDevice9::Reset, and such resources continue to function normally without being reloaded with data. However, if the device must be destroyed and re-created, all resources must be re-created." We should also be using the managed for devices lost, and not recreate the device as it's done now but only reset it to reuse the existent resources.
Using a managed pool makes D3D provide system memory and then whenever necessary copies between that and GPU memory? In that case we could as well revert my changes to make d3dvideosink provide a buffer pool and work in zerocopy mode, if we do the copy on our side or let D3D do it doesn't really matter.
Marking as blocker for 1.2 as it must be fixed or reverted until then.
Andoni, did you get more information about what this MANAGED pool is and how it works? Is it really memcpy'ing internally from system memory to hardware memory, and as such useless for us?
I had didn't have time to investigate in this. The big difference is that using this pool the resources persists across device lost and resets.
And the problem with the current pool is that resources are not valid anymore after a device lost or reset, meaning you need to invalidate the whole pool.
I created #706566 for that. Independent of that, could you update your patches to apply against GIT master?
My patches do not apply in git master because the 1.0 version was ported before some important refactoring in 0.10 where we moved from a shared d3d device with different swap chains for each instance of the sink to a single d3d device with a single swap chain for each instance.
Is this still relevant for git master though? Or can it be closed?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!