Mailing List Archive

Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI
Jim (if you are listening):

I have been trying this with current trunk, and it doesn't seem to be
operational anymore. In the program listing, the alphapulse "Recording..."
in Arclight gets stuck on permanently, and doesn't ever seem to change
alpha.

On the good side (for me at least), the CPU usage is great... 2% rather
than 48% of a Pentium-D... but that's because alphapulse isn't pulsing
anymore.

Could you update this for current trunk and test again?

Thanks.
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Sat, Aug 21, 2010 at 11:00 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> Jim (if you are listening):
> I have been trying this with current trunk, and it doesn't seem to be
> operational anymore.  In the program listing, the alphapulse "Recording..."
> in Arclight gets stuck on permanently, and doesn't ever seem to change
> alpha.
> On the good side (for me at least), the CPU usage is great...  2% rather
> than 48% of a Pentium-D...  but that's because alphapulse isn't pulsing
> anymore.
> Could you update this for current trunk and test again?

I see what you mean. I'll look into it.

To make it easier for me, do you have any idea when it might have
stopped working?

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Sun, Aug 22, 2010 at 12:31 PM, Jim Stichnoth <stichnot@gmail.com> wrote:

> I see what you mean. I'll look into it.
>
> To make it easier for me, do you have any idea when it might have
> stopped working?
>
>
Sorry, I really don't know. I started trying it about a week back, and it's
been not right that whole time. With the number of rendering changes
lately, I guess we shouldn't be too surprised.

It might just be something simple, but I figured you'd have a better chance
of tweaking it as you know it fairly well.

Thanks.
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Sun, Aug 22, 2010 at 1:40 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> On Sun, Aug 22, 2010 at 12:31 PM, Jim Stichnoth <stichnot@gmail.com> wrote:
>> To make it easier for me, do you have any idea when it might have
>> stopped working?
>>
>
> Sorry, I really don't know.  I started trying it about a week back, and it's
> been not right that whole time.  With the number of rendering changes
> lately, I guess we shouldn't be too surprised.
> It might just be something simple, but I figured you'd have a better chance
> of tweaking it as you know it fairly well.

That's good news, actually. Most likely the patch was never working
for that case. I'll update the ticket when I figure it out.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Sat, Aug 21, 2010 at 11:00 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> Jim (if you are listening):
> I have been trying this with current trunk, and it doesn't seem to be
> operational anymore.  In the program listing, the alphapulse "Recording..."
> in Arclight gets stuck on permanently, and doesn't ever seem to change
> alpha.
> On the good side (for me at least), the CPU usage is great...  2% rather
> than 48% of a Pentium-D...  but that's because alphapulse isn't pulsing
> anymore.
> Could you update this for current trunk and test again?

I fixed the alphapulse bug in the patch, as you probably saw.

I maintain this patch and run my production systems with it, which is
easy enough to do since that part of the code doesn't change much.
However, I really don't find much benefit. Even without the patch, it
really doesn't take much processing to walk the tree every 1/70 of a
second and verify that nothing needs pulsing. On an Atom, real
pulsing consumes >50% CPU on one core, which is an entirely separate
problem (if you want to call it a problem). The extra complexity of
having to insert an extra call every time an object field changes that
affects the pulsing decision, just doesn't seem worth the minimal
performance gain.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, Aug 26, 2010 at 7:13 AM, Jim Stichnoth <stichnot@gmail.com> wrote:

> I fixed the alphapulse bug in the patch, as you probably saw.
>

Yes, I did notice things were pulsing again, but I didn't get a chance to
check CPU usage last night. I'll have to check tonight.


> I maintain this patch and run my production systems with it, which is
> easy enough to do since that part of the code doesn't change much.
> However, I really don't find much benefit. Even without the patch, it
> really doesn't take much processing to walk the tree every 1/70 of a
> second and verify that nothing needs pulsing. On an Atom, real
> pulsing consumes >50% CPU on one core, which is an entirely separate
> problem (if you want to call it a problem). The extra complexity of
> having to insert an extra call every time an object field changes that
> affects the pulsing decision, just doesn't seem worth the minimal
> performance gain.
>

I do call it a problem to have a tiny "Recording..." on the screen pulsing
taking up nearly 50% of a CPU core. There are much better things to use CPU
for, especially on a combined frontend/backend setup, which is fairly common
out there. If alphapulse can't be knocked down to use significantly less
CPU, I will probably just go and disable it locally on my setup, and
maintain THAT as a patch. I'd rather spend the CPU on commflagging than in
idling in a menu, as pretty as the menu may be.

But I'll see what your current patchset does to the CPU usage. Maybe it
does enough :)

Thanks.
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, Aug 26, 2010 at 10:11 AM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> I do call it a problem to have a tiny "Recording..." on the screen pulsing
> taking up nearly 50% of a CPU core.  There are much better things to use CPU
> for, especially on a combined frontend/backend setup, which is fairly common
> out there.  If alphapulse can't be knocked down to use significantly less
> CPU, I will probably just go and disable it locally on my setup, and
> maintain THAT as a patch.  I'd rather spend the CPU on commflagging than in
> idling in a menu, as pretty as the menu may be.
>
> But I'll see what your current patchset does to the CPU usage.  Maybe it
> does enough :)

I think you'll be disappointed... For some reason, it just seems to
take a lot of CPU to update the "static" screens at 70Hz without
hardware acceleration.

One could globally reduce the pulse rate from 70Hz and get a
proportional drop in CPU use, but then some transition effects will
look strange.

One could also patch alphapulse to update only every few ticks, which
would make alphapulse less smooth but not affect anything else.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, Aug 26, 2010 at 3:05 PM, Jim Stichnoth <stichnot@gmail.com> wrote:

> One could globally reduce the pulse rate from 70Hz and get a
>
proportional drop in CPU use, but then some transition effects will
> look strange.
>

I'm not sure how 70Hz was ever decided on, but really, we only need to
refresh effects at most at the same rate (or maybe slightly faster?) that we
refresh the display. When running at 1080i output, we are only refreshing
the screen 29.97 times a second. Why on earth are we refreshing the screen
contents over twice as fast as we are displaying it? That's just wasted CPU
spin.

I would suggest that we change the pulsing (assuming this is even
technically possible) to happen at 24fps at the fastest (film rate). I
don't see any particular purpose to making it faster than that. I'm sure
the average user wouldn't even be able to tell the difference visually.

One could also patch alphapulse to update only every few ticks, which
> would make alphapulse less smooth but not affect anything else.


It would be no less smooth, I would expect... if you updated every other
tick at 70Hz. It may not even be noticably different at 1080i as BOTH are
refreshing faster than screen updates anyways.

Or am I missing something here?

Anyways, I don't know if I'll have time to mess with it much before 0.24
release anyways, but I may just resort to locally disabling alphapulse
completely if I can't find a better way.
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, 2010-08-26 at 15:17 -0700, Gavin Hurlbut wrote:
> On Thu, Aug 26, 2010 at 3:05 PM, Jim Stichnoth <stichnot@gmail.com>

> I would suggest that we change the pulsing (assuming this is even
> technically possible) to happen at 24fps at the fastest (film rate).
> Or am I missing something here?

Two things:

First, a refresh of 24fps would look terrible on a 1080i display.*
You want the animation refresh rate to be an integer mul/div
of the display refresh rate. For a 1080i display 14.99 fps
would probably be fine and 29.97 fps would be nice. 70 fps is
not an integer mul/div of any common TV display which makes
it not so great for animations, but when you don't match the
display refresh rate, then the higher the better.

Second, the existing animations are hard coded to a 70fps refresh.
If you lower the tick they run slower, If you increase it they run
faster.

It's the second problem which is a bigger problem. If someone went
through the code and fixed them to be time based it would be easy
to run the animation at say half the refresh rate i.e. 29.97fps
when there had been recent frontend activity. Then ratchet down to
half that after a while. This is not always trivial. Imagine a
bouncing rubber ball, if you take out the frame where it hits the
floor when dropping from 29.97 to 14.99 fps then it will look
very odd as it never hits the ground and never deforms as you
expect a rubber ball to do.

-- Daniel

*TV uses 3:2 pulldown and slows down the movie to 23.98 fps to
allow 24fps movies to work with NTSC rates. Applying pulldown
would use much more CPU..

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, Aug 26, 2010 at 3:45 PM, Daniel Kristjansson
<danielk@cuymedia.net>wrote:

> First, a refresh of 24fps would look terrible on a 1080i display.*
> You want the animation refresh rate to be an integer mul/div
> of the display refresh rate. For a 1080i display 14.99 fps
> would probably be fine and 29.97 fps would be nice. 70 fps is
> not an integer mul/div of any common TV display which makes
> it not so great for animations, but when you don't match the
> display refresh rate, then the higher the better.
>
>
yeah, I guess on second thought, that does make a lot of sense. You'd want
the framerate to be related to the refresh rate or significantly different
from it or you'd end up with odd beat patterns, etc at times.



> It's the second problem which is a bigger problem. If someone went
> through the code and fixed them to be time based it would be easy
> to run the animation at say half the refresh rate i.e. 29.97fps
> when there had been recent frontend activity. Then ratchet down to
> half that after a while. This is not always trivial. Imagine a
> bouncing rubber ball, if you take out the frame where it hits the
> floor when dropping from 29.97 to 14.99 fps then it will look
> very odd as it never hits the ground and never deforms as you

expect a rubber ball to do.
>

Well, for 1080i, which is inherently 29.97fps (full frames, not fields), I
would expect either to run animations at 29.97fps or half-rate - 14.985fps.
For 720p, you may want to add 59.94fps, and of course for PAL: 50, 25,
12.5fps. But really these are the only sensible framerates I could expect
to see. Maybe even 1/4 framerate at times.

We do need to balance the desire for pretty eye-candy with the waste of
resources here. I don't think anyone would seriously disagree that using
~50% of a CPU core simply to pulse "Recording..." at the user in a menu is a
wise tradeoff. We can pulse it a lot slower and get nearly the identical
effect seen by the user, and at significantly lower CPU load. Now, if it
takes a lot of CPU to play back video smoothly, so be it. But for menus?
Come on.

I would propose that we change the animation to being time-based if that's
what it will take to make this less CPU intensive. We aren't making a Pixar
film here, people :) We can sacrifice a little on the quality of our
animations to be less CPU-hoggish :) I don't think we even need to worry
about slowing the animations down further. If we just animate at 1/2
refresh frame rate, we should be relatively OK for the forseeable future.

I guess I maybe just talked myself into another chunk of work. Crap.
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, Aug 26, 2010 at 4:17 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> I would propose that we change the animation to being time-based if that's
> what it will take to make this less CPU intensive.  We aren't making a Pixar
> film here, people :)  We can sacrifice a little on the quality of our
> animations to be less CPU-hoggish :)  I don't think we even need to worry
> about slowing the animations down further.  If we just animate at 1/2
> refresh frame rate, we should be relatively OK for the forseeable future.
> I guess I maybe just talked myself into another chunk of work.  Crap.

A better question might be, why does it take ~10,000 clock cycles to
change one pixel on the screen? (Assuming 2 GHz CPU, 150x10 pixels
being pulsed, 70 Hz pulse rate, 50% CPU utilization.) Solve that
problem, and we can surely ignore all the pulse rate stuff.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On 08/26/2010 06:17 PM, Gavin Hurlbut wrote:
> I'm not sure how 70Hz was ever decided on

For the actual animations stuff (the screen refreshes, but not
necessarily the alphapulse), IIRC, 70Hz was chosen because of the 60Hz
beat of the seconds display in the clock--we needed some value >60Hz to
ensure we didn't skip any seconds. Stuart M. could probably give a lot
more detail when he returns.

Also, remember that this pulsing is in the UI, not the OSD, so video
frame rates/refresh may not be that important. I'd expect we have a lot
of people running at 1080p60 or whatever because that's what their TV
supports, and maybe they drop to video-matched modes for video playback.

That said, optimizing it would be good--but I just hope we don't throw
out the baby with the bath water. :)

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On 08/26/2010 10:17 PM, Michael T. Dean wrote:
> On 08/26/2010 06:17 PM, Gavin Hurlbut wrote:
>> I'm not sure how 70Hz was ever decided on
>
> For the actual animations stuff (the screen refreshes, but not
> necessarily the alphapulse), IIRC, 70Hz was chosen because of the 60Hz
> beat of the seconds display in the clock--we needed some value >60Hz
> to ensure we didn't skip any seconds. Stuart M. could probably give a
> lot more detail when he returns.

Ooops, there are 60 seconds in a /minute/, not in a second. nvm.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Thu, Aug 26, 2010 at 7:17 PM, Michael T. Dean <mtdean@thirdcontact.com>wrote:

> For the actual animations stuff (the screen refreshes, but not necessarily
> the alphapulse), IIRC, 70Hz was chosen because of the 60Hz beat of the
> seconds display in the clock--we needed some value >60Hz to ensure we didn't
> skip any seconds. Stuart M. could probably give a lot more detail when he
> returns.
>

Hmmm, doesn't compute. The seconds display changes once a second. You
wouldn't lose any seconds unless you were refreshing at < 1Hz. But I'm sure
there's something behind this :)


> Also, remember that this pulsing is in the UI, not the OSD, so video frame
> rates/refresh may not be that important. I'd expect we have a lot of people
> running at 1080p60 or whatever because that's what their TV supports, and
> maybe they drop to video-matched modes for video playback.


Yeah. I don't want the effect gone, just not hogging the CPU :)

BTW, the updated patch knocked it down from 48% to 45% (on a 2.8GHz
Pentium-D)
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Friday 27 Aug 2010 03:17:34 Michael T. Dean wrote:
> On 08/26/2010 06:17 PM, Gavin Hurlbut wrote:
> > I'm not sure how 70Hz was ever decided on
>
> For the actual animations stuff (the screen refreshes, but not
> necessarily the alphapulse), IIRC, 70Hz was chosen because of the 60Hz
> beat of the seconds display in the clock--we needed some value >60Hz to
> ensure we didn't skip any seconds. Stuart M. could probably give a lot
> more detail when he returns.

I'm not the guy to ask about the choice of 70Hz, that was inherited from the
original bones of mythui before I got my hands on it. Isaac chose the figure
and although I did discuss it with him a couple of years ago I really don't
remember the reasons given.

Daniel has neatly explained why it would be more efficient for effects to be
time-based but also why a precise time-based method isn't what we want either.
We'd want a compromise where we don't drop frames, we don't actually need to
do so since we're not worried about synchronisation*. We could treat times as
as "best effort" target and adjust future times to a maintain the correct
frame interval, so animations may run slowly but you'll avoid a see-saw with
it then running very fast to compensate.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
Before I forget... I last tried v3 of the patch, and it seemed to have
broken animated GIF support (i.e. it never would go past the first frame of
the animation). I thought I'd mention it... Maybe this was fixed in v4,
not sure.
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Mon, Sep 6, 2010 at 5:18 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> Before I forget...  I last tried v3 of the patch, and it seemed to have
> broken animated GIF support (i.e. it never would go past the first frame of
> the animation).  I thought I'd mention it...  Maybe this was fixed in v4,
> not sure.

Probably was not fixed in v4. I don't happen to have animated GIFs to
test on, but I believe it would just involve changing all 4 instances
of:

SetNextPulse(animPulse, (m_Delay > 0));

in the patched mythuiimage.cpp to:

SetNextPulse(animPulse, (m_Delay > 0 || !m_Delays.isEmpty()));

Any chance you could test that?

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI [ In reply to ]
On Mon, Sep 6, 2010 at 5:32 PM, Jim Stichnoth <stichnot@gmail.com> wrote:

> On Mon, Sep 6, 2010 at 5:18 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> > Before I forget... I last tried v3 of the patch, and it seemed to have
> > broken animated GIF support (i.e. it never would go past the first frame
> of
> > the animation). I thought I'd mention it... Maybe this was fixed in v4,
> > not sure.
>
> Probably was not fixed in v4. I don't happen to have animated GIFs to
> test on, but I believe it would just involve changing all 4 instances
> of:
>
> SetNextPulse(animPulse, (m_Delay > 0));
>
> in the patched mythuiimage.cpp to:
>
> SetNextPulse(animPulse, (m_Delay > 0 || !m_Delays.isEmpty()));
>
> Any chance you could test that?
>
>
I'll add it to my list of things to check out. Thanks