[Bug 796640] Fix for a synchronization bug in 1.14.1 ext/qt/gstqsgtexture.cc

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796640

Matthew Waters (ystreet00) <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ystreet00 at gmail.com

--- Comment #12 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
(In reply to jimmy from comment #9)
> (In reply to Jan Schmidt from comment #8)
> > (In reply to jimmy from comment #7)
> > > (In reply to Jan Schmidt from comment #6)
> > > > Does the mutex actually have any effect, or is the
> > > > gst_gl_sync_meta_wait_cpu() call sufficient?
> > > 
> > > In my testing the gst_gl_sync_meta_wait_cpu call was sufficient (appears to
> > > be the same as glFinish()) BUT
> > > 
> > > From reading the comments it seemed as if the gstreamer thread calls
> > > GstQSGTexture::setBuffer while Qt:s render thread calls on
> > > GstQSGTexture::bind, this prompted me to add this lock.
> > 
> > Which comment are you thinking of? If I remember correctly, the setBuffer
> > call is made while blocking the Qt render thread, preventing ::bind from
> > running simultaneously.
> 
> Yes I seem to have misinterpreted the comment, it says that it is indeed
> blocking the rendering thread.
> 
> Is my understanding correct that this is the call that eventually invokes
> the bind() function? : 
> 
> // from qtitem.cc:
>   gst_buffer_replace (&qt_item->priv->buffer, buffer);
>   QMetaObject::invokeMethod(qt_item, "update", Qt::QueuedConnection);
>   g_mutex_unlock (&qt_item->priv->lock);
> 
> If so, is there really a guarantee that rendering has been invoked by the
> time the mutex is unlocked? (note there is also
> Qt::BlockingQueuedConnection).

That's the way we force an update to be displayed.  Qt can add it's own in
there if it likes.

Qt scenegraph update happens in two stages which can actually be in two
different threads (where supported by drivers et al.  A helpful diagram is
available from the Qt docs:
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#threaded-render-loop-threaded

So, there are three parts to GStreamer displaying things using qmlglsink:
1. Receive buffer and send it to the component/item.  Rather boring stuff, just
atomically updates a pointer atm.
2. Qt calls item::updatePaintNode() which uses the updated buffer and then sets
the buffer/caps/information on the associated node that is attached to
scenegraph like setBuffer, setCaps.  Happens in the updatePaintNode section of
the above diagram
3. Qt then calls bind() whenever it wants the texture bound and drawn.  Happens
in the 'scene graph is rendered' stage in the above docs.

With all that, the multithreaded approach is actually not used everywhere (as
mentioned in the above link) like on mesa drivers and the threaded vs
non-threaded loop can be changed with the QSG_RENDER_LOOP environment variable.
 Try changing it between 'threaded' and 'basic' and see if that makes a
difference.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.