[mythtv-firehose] mythtv/master commit: 204f81881 by Gavin Hurlbut (Beirdo)

MythTV noreply at mythtv.org
Sat Jun 11 01:46:51 UTC 2011


      Author:  Gavin Hurlbut <ghurlbut at mythtv.org>
 Change Date:  2011-06-10T18:35:25-07:00
   Push Date:  2011/06/10 18:46:44 -0700
  Repository:  mythtv
      Branch:  master
New Revision:  204f81881ee95e1c913075e04b6381d81b1b5953
   Changeset:  https://github.com/MythTV/mythtv/commit/204f81881

Log:

Fix remote (mythweb) screenshots

Seems in the rework done in fa9f32bd29bfb26445ea88ba35a3042e4d43955a, there
was an incorrect assumption as to the use of GetScreenShot as used over the
frontend's control socket.  It is actually used by mythweb to give a
rudimentary (so far) remote control setup, and the screenshot has to be
actually sent back to mythweb for this to work.  Also, since this is going
over the public internet in many cases, the size of PNG is not acceptable, so
specific support was made for JPG for this use.  I kinda reverted part of that
changeset in the process of fixing this regression.

To take a screenshot in any thread other than the UI thread, it is necessary
to get the UI thread to do the work.  This is why we need a signal to force
the code to cross the thread boundary.  If not, QPixmap spews a warning (which
can become fatal with QT_FATAL_WARNINGS set, or in some debug modes).

The flow for a remote (i.e. non-UI) thread to get a screenshot is:
MythMainWindow *window = GetMythMainWindow();
window->RemoteScreenShot(sFileName, nWidth, nHeight);

This calls a method in the MythMainWindow class that will then signal (and
block until the slot has returned) that is also in the MythMainWindow class
to cross the boundary into the UI thread.  The slot will then create an event
and use sendEvent to run that event immediately in the main window (which
remains in the UI thread).  When that completes, following the same code path
as a UI-triggered screenshot, the slot returns, which then causes the
RemoteScreenShot method to return, unblocking the original HTTPServer thread,
precipitating the resultant file to be sent back to mythweb as a response.

This is all horribly complex, but it pretty much has to be that way to be
operational.

Modified:

   mythtv/libs/libmythui/mythmainwindow.cpp
   mythtv/libs/libmythui/mythmainwindow.h
   mythtv/programs/mythfrontend/mythfexml.cpp



More information about the mythtv-firehose mailing list