[mythtv] [PATCH] Limit the updates for nonexisting LCD

[Kenneth Aafløy]

On Friday 08 October 2004 11:54, Tako Schotanus wrote:
> Kenneth Aafløy wrote:
> > Also, after I had a look at this compile time option I must say I do not
> > understand why this was even made a compile time option. I would say that
> > what qualifies as a compile time option is a large part of code that is
> > either very unstable and/or contains external dependecies that not every
> > user would want or need to have. LcdDevice is neither, right?
>
> Sorry, have no idea about the rationale for making it a compile time
> option.

Do you have an oppinion on this Isaac?

> > I also would like to move most of the lcddevice data into a private data
> > object that is created after the lcddevice has connected to the lcdproc
> > server, to minimize the memory footprint this class represents if no
> > lcdproc server is running. 
>
> Is it that much data?

No it's not much, about 10 QObjects + some variables, so I'm reconsidering, 
since the amount of change won't be worth the benefit.

> > If you follow the nvp->calcSliderPos() call you would discover that in two
> > out of three cases this call requires a call to the backend. The only
> > case this backend query would not happen is when you have access to the
> > backend recording directory on your frontend, so that the ringbuffer can
> > access a file directly. I do not have things setup that way here, so for
> > me using MythTV will always go through the backend.
>
> Ok, so does this mean that it does this as well when the OSD (with
> postition) is on-screen?

Many locations in MythTV use this call, try grepping the libs for it. These 
however mostly is called once on user interaction. It would be nice to have 
this sent from the server along with the return number from a remote Read 
(for example), which could then be cached for calcSliderPos and other usage.
Does that sound sane?

> > I have no idea since I don't have access to a lcd and have not tried the
> > curses based version of this since I don't plan on getting one.
>
> It was more a rethorical question ;-)

 :)

> A lot of LCD displays don't even support per-pixel progress bars so they
> would see even less, but imagine a 500 pixel wide display (which is very
> large) and a 15 minute program (900 seconds): 900 / 500 = 1.8. So a
> display that wide with a very short program would only need to be
> updated every 2 seconds to have a very precise progress bar.  A one hour
> long program with a 200 pixel display needs an update only every 18
> seconds. Of course you could do this calculation for each program but
> that's overkill, let's just say that updating once a second is more than
> enough for the lcd IMO.

So if I change the 250 in my patch to a 1000 and remove the secsTo() stuff it 
would scale nicely as it would be updated less if the load is high.

Thanks,
Kenneth