Mailing List Archive

[PATCH] Limit the updates for nonexisting LCD
Hi,

I've attached a patch which limits the number of updates my lcd (that does not
exist) receives to max 4/s. This was really flodding the traffic between
frontend and backend. If someone who knows the lcd code could fix the TODO
item in this patch I would be very pleased, but this fixes my immediate
problem.

Kenneth
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Thu, 7 Oct 2004 01:34:37 +0200, Kenneth Aafløy
<lists@kenneth.aafloy.net> wrote:
> Hi,
>
> I've attached a patch which limits the number of updates my lcd (that does not
> exist) receives to max 4/s. This was really flodding the traffic between
If the LCD doesn't exist, then why not update your settings.pro file
and comment out the LCD stuff and recompile?

-dan
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
Dan Morphis wrote:

>On Thu, 7 Oct 2004 01:34:37 +0200, Kenneth Aafløy
><lists@kenneth.aafloy.net> wrote:
>
>
>>Hi,
>>
>>I've attached a patch which limits the number of updates my lcd (that does not
>>exist) receives to max 4/s. This was really flodding the traffic between
>>
>>
>If the LCD doesn't exist, then why not update your settings.pro file
>and comment out the LCD stuff and recompile?
>
>
>
>
He could do that but that doesn't change the fact that it should work,
maybe not with a hasLCD() function but using the frontend settings where
you can decide which info to show on the display. You should at least be
able to disable the LCD by unchecking all those items.

Strange thing is that I wrote most of that code and I thought that when
Isaac checked it in he had changed it to make it update a lot less
often, my original code would update it every second. Obviously I was wrong.

Cheers,
-Tako
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Wed, Oct 06, 2004 at 03:54:37PM -0800, Dan Morphis wrote:
> On Thu, 7 Oct 2004 01:34:37 +0200, Kenneth Aafløy
> <lists@kenneth.aafloy.net> wrote:
> > Hi,
> >
> > I've attached a patch which limits the number of updates my lcd (that does not
> > exist) receives to max 4/s. This was really flodding the traffic between
> If the LCD doesn't exist, then why not update your settings.pro file
> and comment out the LCD stuff and recompile?

That's not a good fix for binary distributions, which should generally
have all the compile-time options enabled.

Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Thursday 07 October 2004 14:15, Tako Schotanus wrote:
> Dan Morphis wrote:
> >On Thu, 7 Oct 2004 01:34:37 +0200, Kenneth Aafløy
> >
> ><lists@kenneth.aafloy.net> wrote:
> >>Hi,
> >>
> >>I've attached a patch which limits the number of updates my lcd (that
> >> does not exist) receives to max 4/s. This was really flodding the
> >> traffic between
> >
> >If the LCD doesn't exist, then why not update your settings.pro file
> >and comment out the LCD stuff and recompile?

That approach would not work, because then it still would be broken for those
that really use the LCD..also the code in question is not covered by the LCD
compile time configurable, did you read the patch and sorrounding code?

> He could do that but that doesn't change the fact that it should work,
> maybe not with a hasLCD() function but using the frontend settings where
> you can decide which info to show on the display. You should at least be
> able to disable the LCD by unchecking all those items.

It still won't disable the code in question.

> Strange thing is that I wrote most of that code and I thought that when
> Isaac checked it in he had changed it to make it update a lot less
> often, my original code would update it every second. Obviously I was
> wrong.

The original loop goes something like this:

while (runMainLoop)
{
- if queued, handle state change
- sleep 1/1000s
- if recording info is queued, fetch it
- if playback, process any queued keys
- if playback and player stopped, change state
- if playback about to exit, handle exiting playback
- if ++updatecheck >= 20
- update osd
- reset updatecheck
- if a channel is queued and the osd is avail, commit it
- check if it's 60s since last time
- show lcd info
- reset timer
- pull lcd info from backend
- set channel progress on the lcd
}

So essentially this code is not only flodding the backend, but it's
essentially also blocking user interaction.

The updates could abviously potentially reach 1000 times per second, however
it will not ever reach this amount, both because the usleep will certainly
sleep more than a 1/1000s on most architechtures, but it will always strive
for the most updates possible.

The backend only has a few threads (5 iirc) to do processing for the client
sockets, so it's bound to be busy most of the time. Imagine this with a few
clients connected to a backend at a time, or even worse, if the thread
limitations was somehow solved, horrible.

Cheers,
Kenneth
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
Kenneth Aafløy wrote:

>On Thursday 07 October 2004 14:15, Tako Schotanus wrote:
>
>
>>Dan Morphis wrote:
>>
>>
>>>On Thu, 7 Oct 2004 01:34:37 +0200, Kenneth Aafløy
>>>
>>><lists@kenneth.aafloy.net> wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I've attached a patch which limits the number of updates my lcd (that
>>>>does not exist) receives to max 4/s. This was really flodding the
>>>>traffic between
>>>>
>>>>
>>>If the LCD doesn't exist, then why not update your settings.pro file
>>>and comment out the LCD stuff and recompile?
>>>
>>>
>
>That approach would not work, because then it still would be broken for those
>that really use the LCD..also the code in question is not covered by the LCD
>compile time configurable, did you read the patch and sorrounding code?
>
>
You're now responding to two people at the same time :-)
I agree with you that this is not enough.

>
>
>>He could do that but that doesn't change the fact that it should work,
>>maybe not with a hasLCD() function but using the frontend settings where
>>you can decide which info to show on the display. You should at least be
>>able to disable the LCD by unchecking all those items.
>>
>>
>
>It still won't disable the code in question.
>
>
True, what I meant with "should" is, that it "should have been
implemented because the options to enable/disable it exist".

>
>
>>Strange thing is that I wrote most of that code and I thought that when
>>Isaac checked it in he had changed it to make it update a lot less
>>often, my original code would update it every second. Obviously I was
>>wrong.
>>
>>
>
>The original loop goes something like this:
>
>while (runMainLoop)
>{
> - if queued, handle state change
> - sleep 1/1000s
> - if recording info is queued, fetch it
> - if playback, process any queued keys
> - if playback and player stopped, change state
> - if playback about to exit, handle exiting playback
> - if ++updatecheck >= 20
> - update osd
> - reset updatecheck
> - if a channel is queued and the osd is avail, commit it
> - check if it's 60s since last time
> - show lcd info
> - reset timer
> - pull lcd info from backend
> - set channel progress on the lcd
>}
>
>So essentially this code is not only flodding the backend, but it's
>essentially also blocking user interaction.
>
>
The "pull lcd info from backend" part I don't understand, why do you
think the backend is involved here? It shouldn't be if I understand and
remember correctly. It's just a pointer to the local lcd device on the
frontend as far as I know. And the info about the currently playing
program was already available so calculating the position should not
take any (extra) time.

That doesn't mean you are right in limiting the number of updates. I
even think you haven't limited it enough because how much can the
progress bar change in 1/4 of a second anyway? So as far as I'm
concerned you can lower the frequency to once a second or even less.

>The updates could abviously potentially reach 1000 times per second, however
>it will not ever reach this amount, both because the usleep will certainly
>sleep more than a 1/1000s on most architechtures, but it will always strive
>for the most updates possible.
>
>The backend only has a few threads (5 iirc) to do processing for the client
>sockets, so it's bound to be busy most of the time. Imagine this with a few
>clients connected to a backend at a time, or even worse, if the thread
>limitations was somehow solved, horrible.
>
>
Right.

>Cheers,
>Kenneth
>
>
>
-Tako

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Thursday 07 October 2004 16:59, Tako Schotanus wrote:
> Kenneth Aafløy wrote:
> > On Thursday 07 October 2004 14:15, Tako Schotanus wrote:
> > > Dan Morphis wrote:
> > > > If the LCD doesn't exist, then why not update your settings.pro
> > > > file and comment out the LCD stuff and recompile?
> >
> > That approach would not work, because then it still would be broken for
> > those that really use the LCD..also the code in question is not covered
> > by the LCD compile time configurable, did you read the patch and
> > sorrounding code?
>
> You're now responding to two people at the same time :-)
> I agree with you that this is not enough.

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?

> > > He could do that but that doesn't change the fact that it should work,
> > > maybe not with a hasLCD() function but using the frontend settings where
> > > you can decide which info to show on the display. You should at least be
> > > able to disable the LCD by unchecking all those items.
> >
> >It still won't disable the code in question.
>
> True, what I meant with "should" is, that it "should have been
> implemented because the options to enable/disable it exist".

I would like to propose removing the LCD_DEVICE compile time option and also
adding a master enable/disable switch for the lcddevice on the globalsettings
screen, just in case a user have another daemon running on the port the
lcdproc server is running on. 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.

> > > Strange thing is that I wrote most of that code and I thought that when
> > > Isaac checked it in he had changed it to make it update a lot less
> > > often, my original code would update it every second. Obviously I was
> > > wrong.
> >
> >The original loop goes something like this:
<snip>
> >So essentially this code is not only flodding the backend, but it's
> >essentially also blocking user interaction.
>
> The "pull lcd info from backend" part I don't understand, why do you
> think the backend is involved here?
>
> It shouldn't be if I understand and remember correctly. It's just a pointer
> to the local lcd device on the frontend as far as I know. And the info about
> the currently playing program was already available so calculating the
> position should not take any (extra) time.

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.

> That doesn't mean you are right in limiting the number of updates. I
> even think you haven't limited it enough because how much can the
> progress bar change in 1/4 of a second anyway?

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.

> So as far as I'm concerned you can lower the frequency to once a second or
> even less.

Excelent, could just merge both the checks into a single check here then.

Kenneth
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
Kenneth Aafløy wrote:

>On Thursday 07 October 2004 16:59, Tako Schotanus wrote:
>
>
>>Kenneth Aafløy wrote:
>>
>>
>>>On Thursday 07 October 2004 14:15, Tako Schotanus wrote:
>>>
>>>
>>>>Dan Morphis wrote:
>>>>
>>>>
>>>>>If the LCD doesn't exist, then why not update your settings.pro
>>>>>file and comment out the LCD stuff and recompile?
>>>>>
>>>>>
>>>That approach would not work, because then it still would be broken for
>>>those that really use the LCD..also the code in question is not covered
>>>by the LCD compile time configurable, did you read the patch and
>>>sorrounding code?
>>>
>>>
>>You're now responding to two people at the same time :-)
>>I agree with you that this is not enough.
>>
>>
>
>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.

>
>
>>>>He could do that but that doesn't change the fact that it should work,
>>>>maybe not with a hasLCD() function but using the frontend settings where
>>>>you can decide which info to show on the display. You should at least be
>>>>able to disable the LCD by unchecking all those items.
>>>>
>>>>
>>>It still won't disable the code in question.
>>>
>>>
>>True, what I meant with "should" is, that it "should have been
>>implemented because the options to enable/disable it exist".
>>
>>
>
>I would like to propose removing the LCD_DEVICE compile time option and also
>adding a master enable/disable switch for the lcddevice on the globalsettings
>screen, just in case a user have another daemon running on the port the
>lcdproc server is running on.
>
Seems like a sound idea.

> 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?

>
>
>>>>Strange thing is that I wrote most of that code and I thought that when
>>>>Isaac checked it in he had changed it to make it update a lot less
>>>>often, my original code would update it every second. Obviously I was
>>>>wrong.
>>>>
>>>>
>>>The original loop goes something like this:
>>>
>>>
><snip>
>
>
>>>So essentially this code is not only flodding the backend, but it's
>>>essentially also blocking user interaction.
>>>
>>>
>>The "pull lcd info from backend" part I don't understand, why do you
>>think the backend is involved here?
>>
>>It shouldn't be if I understand and remember correctly. It's just a pointer
>>to the local lcd device on the frontend as far as I know. And the info about
>>the currently playing program was already available so calculating the
>>position should not take any (extra) time.
>>
>>
>
>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?

>
>
>>That doesn't mean you are right in limiting the number of updates. I
>>even think you haven't limited it enough because how much can the
>>progress bar change in 1/4 of a second anyway?
>>
>>
>
>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 as far as I'm concerned you can lower the frequency to once a second or
>>even less.
>>
>>
>
>Excelent, could just merge both the checks into a single check here then.
>
>Kenneth
>
>
>
-Tako

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Friday 08 October 2004 03:33 pm, Kenneth Aafløy wrote:
> 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?

Not really - I think the current stuff could be done better, in that all the
code in the various modules (eg, mythmusic) generally does a lot of extra
work that it wouldn't have to if the lcd weren't present. As long as there's
no additional dependencies, I don't have a problem getting rid of it being a
compile-time option.

> 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?

That makes sense.

> 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.

I would just move the calcSliderPos bit into the existing code that makes it
only check once a second, personally.

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Friday 08 October 2004 21:52, Isaac Richards wrote:
> On Friday 08 October 2004 03:33 pm, Kenneth Aafløy wrote:
> > 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?
>
> Not really - I think the current stuff could be done better, in that all
> the code in the various modules (eg, mythmusic) generally does a lot of
> extra work that it wouldn't have to if the lcd weren't present. As long as
> there's no additional dependencies, I don't have a problem getting rid of
> it being a compile-time option.

So I'll start making patches like:
if ( (LvdDevice *dev = gContext->GetLcdDevice()) )
{
....
}
which would not affect the current behavior at all, and then in the end send
the patch which really does not create and/or deletes the lcd object if it's
unable to connect to it's server.

> > 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.
>
> I would just move the calcSliderPos bit into the existing code that makes
> it only check once a second, personally.

I was thinking why calculate time x is over y, z times a second for such a
minute task as updating the lcd display, which could live well with a bit of
a delay on very high load.

Kenneth
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Friday 08 October 2004 06:12 pm, Kenneth Aafløy wrote:
> So I'll start making patches like:
> if ( (LvdDevice *dev = gContext->GetLcdDevice()) )
> {
> ....
> }
> which would not affect the current behavior at all, and then in the end
> send the patch which really does not create and/or deletes the lcd object
> if it's unable to connect to it's server.

Cool, that'd be great - though, it'd probably make sense to make the lcd
object a singleton, and remove it from the context object completely.

> > > 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.
> >
> > I would just move the calcSliderPos bit into the existing code that makes
> > it only check once a second, personally.
>
> I was thinking why calculate time x is over y, z times a second for such a
> minute task as updating the lcd display, which could live well with a bit
> of a delay on very high load.

True, that works..

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
>Not really - I think the current stuff could be done better, in that all the
>code in the various modules (eg, mythmusic) generally does a lot of extra
>work that it wouldn't have to if the lcd weren't present. As long as there's
>no additional dependencies, I don't have a problem getting rid of it being a
>compile-time option.
>
>

I have been thinking recently about introducing a kind of "status"
object into each module. The LCD code, or anything else interested in
current module state, would then read off the status object and format
it appropriately. This would also make it possible to build palm pilot
or web type status monitors and perhaps remote controls as well

The status object would probably fire an event when the main code made a
change, so that interested receivers could do their updates (like the
LCD screen).

Any thoughts on how to do a generic status object which is then
subclassed for each specific module? How does this sound for an
approach generally?

Ed W
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On 8 Oct 2004, at 6:12 PM, Kenneth Aafløy wrote:

> So I'll start making patches like:
> if ( (LvdDevice *dev = gContext->GetLcdDevice()) )
> {
> ....
> }
> which would not affect the current behavior at all, and then in the
> end send
> the patch which really does not create and/or deletes the lcd object
> if it's
> unable to connect to it's server.

As a data point, I'm currently profiling the Mac OS X build, and nearly
15% of the time is spent in the LCD update code (running
calcSliderPos() and the lastLcdUpdate calculation). So, I'm all for
conditionalizing the LCD, as I'm paying a huge penalty for a feature I
don't use.

- Jeremiah

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [PATCH] Limit the updates for nonexisting LCD [ In reply to ]
On Saturday 16 October 2004 15:08, Jeremiah Morris wrote:
> As a data point, I'm currently profiling the Mac OS X build, and nearly
> 15% of the time is spent in the LCD update code (running
> calcSliderPos() and the lastLcdUpdate calculation). So, I'm all for
> conditionalizing the LCD, as I'm paying a huge penalty for a feature I
> don't use.

I've attached patches for mythtv, mythmusic and mythvideo. I've not had the
time to look at the other plugins yet, but will do if this looks okay.

Kenneth