[mythtv] [mythtv-commits] Ticket #7525: Optimize Pulse handling in MythUI

[Gavin Hurlbut]

On Thu, Aug 26, 2010 at 3:45 PM, Daniel Kristjansson
<danielk at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100826/bcb33839/attachment.htm>