[mythtv-users] Mythfrontend idle cpu consumption help

[Jim Stichnoth]

On Sun, Jan 24, 2010 at 8:20 AM, Chris Pinkham <cpinkham at bc2va.org> wrote:
> * On Sun Jan 24, 2010 at 06:40:07AM -0800, Jim Stichnoth wrote:
>> My patch in ticket #7953 reduces my ION system's CPU usage to under 1%
>> on the Main Menu screen and under 2% on the Watch Recordings screen
>> (as long as there are no animations going on).
>
> What theme are you using this with?  How long have you been running with
> it?

I use Blue Abstract.  So far I've only been running about a day with the patch.

> Daniel mentioned in IRC that you probably need to use
> Qt::BlockingQueuedConnection in the connect() so that animate() runs in
> the UI thread.  Have you had any segfaults since since you started running
> with this patch?

I haven't seen segfaults yet, but I will keep a lookout.  I'm not a Qt
programmer, but my assumption was that since the new instance of the
QThread subclass doesn't run an event loop, the timeout() signal would
get sent to the UI thread's event queue and executed in the UI thread.

> On themes that use pulsing, like Graphite's menus and MythVideo screens
> specifically, does the pulsing still look smooth with this patch, and
> what is your CPU utilization sitting at on these screens with the
> patch?  Do you know how much is it without the patch?

I couldn't find any actual pulsing with Graphite or with MythVideo
(pointers would be appreciated).  Everything I looked at in Graphite
was equally smooth and consumed the same CPU as Blue Abstract.  In
Blue Abstract, there is an animated icon for commflagging and
transcoding, which is equally smooth with and without the patch.
Without the patch, CPU usage is about 8% with pulsing versus 7%
without pulsing.  With the patch, CPU usage is about 3-5% with pulsing
versus about 2% without.  Also, the fades from one screen to another
are equally smooth with and without the patch.

In any case, this patch may be considered a proof of concept.  Daniel
mentioned tying the animation cycle to the screen refresh, which would
be a really good idea.  The important point is to avoid using QTimer
for high-resolution timers.

Jim