[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