Broken graphics in a WPF window when using GStreamer

[Ralph]

I have written a few C# WPF applications using OSSBuild 0.10.7 Beta 4 (I've tested 0.10.6 as well), I'm displaying the video using XOverlayAdapter and a handle to a hosted WindowsForms control.  My pipeline contains gnonlin with a few filesources, I'm using either dshowvideosink or d3dvideosink (the user can choose his preferred one).


The problem:

Occasionally the window graphics get broken.  Either the entire content becomes black (except the video rectangle), or a few large parts of the window get black, or just a few controls get black.  That's a classic graphics update problem.

It happens only after operations like starting playback, stopping playback, seeking or loading a new file.  It practically always happens after starting or stopping the playback for the first time, all subsequent play/stop operations are usually performed without any problems (but that's not a rule).

When the graphics get broken, dragging the application window around the screen or trying any sorts of invalidating displayed WPF controls programmatically don't work, the only way of forcing the window to be repainted is resizing it, minimizing and restoring, or hiding and showing.  I've tried everything, but WPF does all the rendering autonomously by design and there is no way I can force it to physically repaint the content of the window.  The only solution that works is hiding the window and displaying it again very quickly, but it is a nasty hack, very annoying for the user.

Has anyone experienced similar problems?  Any suggestions?

[Ralph]

I've found a workaround.
Each time I start/stop playback or load a new video file, I change the opacity of the window to 0.0 and then back to the original value.  This seems to fix the graphics while not producing any visible side effects.

[Holger Kaelberer]

Hi,

this sounds like what we saw on Linux/XWindows with video-sinks not handling expose events (don't
know what the Windows equivalent is).

We solved it by filtering out Expose XEvents in the application from further event-processing by the
GUI framework (Qt) and calling gst_x_overlay_expose() on the video-sink for them instead.

Holger

On 05/28/2012 04:28 PM, Ralph wrote:

> I've found a workaround.
> Each time I start/stop playback or load a new video file, I change the
> opacity of the window to 0.0 and then back to the original value.  This
> seems to fix the graphics while not producing any visible side effects.
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Broken-graphics-in-a-WPF-window-when-using-GStreamer-tp4655120p4655121.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel