[Bug 656905] [d3dvideosink] vsync + tearing problems

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Mar 22 11:58:45 PDT 2012


https://bugzilla.gnome.org/show_bug.cgi?id=656905
  GStreamer | gst-plugins-bad | git

--- Comment #23 from David Hoyt <dhoyt at llnl.gov> 2012-03-22 18:58:38 UTC ---
Review of attachment 194377:
 --> (https://bugzilla.gnome.org/review?bug=656905&attachment=194377)

I feel this should be reverted and it seems there's a bug in the device lost
logic. I admit my memory's a bit fuzzy -- won't you have to recreate every
device on a device loss? What I see here seems to indicate there could be a
memory leak as old d3d devices aren't correctly released after a device loss.

::: sys/d3dvideosink/d3dvideosink.c
@@ +2050,3 @@
   /* Ask DirectX to please not clobber the FPU state when making DirectX API
calls. */
   /* This can cause libraries such as cairo to misbehave in certain scenarios.
*/
+  d3dcreate = 0 | D3DCREATE_FPU_PRESERVE | D3DCREATE_MULTITHREADED;

D3DCREATE_MULTITHREADED should not be needed. Device access should always be
taking place on the rendering thread. Messages are posted to the render thread
otherwise. Access is already guarded and D3DCREATE_MULTITHREADED is therefore
redundant and only a performance hit.

@@ +2137,2 @@
+  ZeroMemory (&sink->d3dpp, sizeof (sink->d3dpp));
+  sink->d3dpp.Flags = D3DPRESENTFLAG_VIDEO |
D3DPRESENTFLAG_LOCKABLE_BACKBUFFER;

Is this needed? This can incur add'l performance costs. See
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172586(v=vs.85).aspx

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list