[mythtv-commits] Ticket #9223: Sluggish menu when watching a recording
MythTV
noreply at mythtv.org
Fri Feb 11 04:24:38 UTC 2011
#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.
--
Ticket URL: <http://code.mythtv.org/trac/ticket/9223#comment:33>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list