[mythtv] Ticket #9223: Sluggish menu when watching a recording

brad dreisbach bradd at ameri.ca
Sat Feb 12 15:57:45 UTC 2011


On Feb 12, 2011, at 10:46 AM, John Sturgeon wrote:

> On Feb 10, 2011, at 9:06 PM, Mark Kendall wrote:
> 
>> On 11 February 2011 12:46, John Sturgeon <john.sturgeon at gmail.com> wrote:
>>> On Feb 10, 2011, at 8:24 PM, MythTV wrote:
>>> 
>>> #9223: Sluggish menu when watching a recording
>>> -------------------------------------+--------------------------------
>>> Reporter:  glemsom@…                |          Owner:  markk
>>>    Type:  defect                   |         Status:  infoneeded_new
>>> Priority:  minor                    |      Milestone:  0.24.1
>>> Component:  MythTV - Video Playback  |        Version:  0.24-fixes
>>> Severity:  medium                   |     Resolution:
>>> Keywords:  sluggish menu            |  Ticket locked:  0
>>> -------------------------------------+--------------------------------
>>> 
>>> Comment (by markk):
>>> 
>>> Thanks to John and Brian, I now have a couple of fixes/0.24 binaries that
>>> display the issue.
>>> 
>>> Having re-read dgatwood's analysis and comments above, looked at the
>>> commit that introduced the issue (or moved it from painfully sluggish to
>>> totally unresponsive a328d996b94f62814cf065e60311d973283ec6c8) and
>>> considered the Qt version differences, I think the UI thread blocking
>>> issues are not the issue here.
>>> 
>>> What is probably relevant is how Qt is handling the event loop internally,
>>> which I imagine may well be different between cocoa and carbon builds.
>>> With the cocoa build, the event loop is clearly being processed as
>>> expected and for carbon - not. Hence no CFRunLoop references as dgatwood
>>> noted.
>>> 
>>> So, in the commit I've referenced above, the only piece that would appear
>>> to change the behaviour of the main event loop is the addition of
>>> hasPendingEvents() check. The Qt source for QEventDispatcher_mac is chock
>>> full of #ifdef QT_MAC_USE_COCOA, so trying to unpick the Qt internals
>>> isn't going to be fruitful.
>>> 
>>> But by way of a quick and easy test, can someone try removing the
>>> hasPendingEvents() check in tv_play (there's only one use) and see if that
>>> helps. It may well simply revert to the previous sluggish behaviour but at
>>> least that will be progress of sorts.
>>> 
>>> There is only one instance of hasPendingEvents and that's in
>>> mythmainwindow.cpp:
>>> void MythMainWindow::SetDrawEnabled(bool enable)
>>> {
>>> [snip]
>>>        while (QCoreApplication::hasPendingEvents())
>>>            d->m_setDrawEnabledWait.wait(&d->m_setDrawEnabledLock);
>>>        return;
>>>    }
>>> [snip]
>>> }
>>> Did you want me to comment the entire loop?
>> 
>> John
>> 
>> Line 368 of libs/libmythtv/tv_play.cpp (in fixes/0.24 anyway)
>> 
>> regards
>> 
>> Mark
> 
> That did it!
> 
> Thanks Mark, pausing, skipping is better than I've ever seen it on 0.24.  WAF ++++

i can also confirm that this is working for me as well.  thanks mark.

can someone who has osx-packager.pl working with qt 4.7.1 send it to me please?
i was not able to get qt 4.7.1 to build inside the perl script.

> 
> -- 
> John <><
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/mailman/listinfo/mythtv-dev



More information about the mythtv-dev mailing list