LCDproc development and user support list

Text archives Help


[lcdproc] spectrum analyzer? --> Frame per second...


Chronological Thread 
  • From: linux AT chello.at (Harald Klein)
  • Subject: [lcdproc] spectrum analyzer? --> Frame per second...
  • Date: Mon, 28 Feb 2000 19:13:07 +0000

Hi all!

Maybe ill find the time to implement it.

First, are you guys out there using esd ?

is there a smaller lib than fftlib ?

Harald



David Glaude wrote:
>
> Hello,
> My 0.02$:
> I think the server should have a param for the MAXIMUM number of frame per
> second.
> Also have a default number of frame per second (for client/screen that
> don't know or care).
> Each client/screen should be able to know what is the MAXIMUM
> and to specify the wanted value for display.
> Then it is up to the server/rendering code to display it at proper rate.
>
> That way, we protect CPU time on the server and we allow for limited number
> of
> screen client the option to "fastly display something".
>
> Please remember that there is a little latency to be expected between the
> client (the spectrum analyser) and the server (where the LCD stand).
> I don't know how much time we spend in TCP/IP stack, packet, buffer,
> rendering code, serial cable and such,
> but it is not instantaneous! (anybody to make a nokia-like game based on
> lcdproc)
>
> There is maybe more to do about screen refresh and frame per second.
> I don't remember exactly how the rendering code work, but here are some
> ideas...
> From a logical(software) point of view, the LCD don't need to be refresh.
> And if there are changes on the logical display (the one provided by the
> client),
> then those changes should be made on the LCD.
> I does not always mean that we need to redraw the complet screen...
> Maybe it is possible to maintain in the frame buffer a copy of the old
> screen
> and compare that to the new screen, then evaluate is it is faster(number of
> byte, time to display)
> to rewrite the screen or to modify a few caracter from the screen.
>
> It might sound nice and would be perfect for a spectum analyse display
> where bar are moving
> from one level to another level. Unfortunatly, the rendering code does not
> know every detail
> of the way the driver display graphics. (rember that I wanted a layer
> in-between for common
> graphical caracter use so that MO, Crystal and other reuse the same
> graphical rendering code).
>
> So the nice idea is currently not woorking well for graphical display, but
> could do thing
> for text display. Now because graphic is most of the time custom graphic
> caracter, then,
> why not try.
>
> David GLAUDE
>
> -----Original Message-----
> From: Dirk
> [mailto:dirk AT lemongecko.org]
> Sent: Monday, February 28, 2000 6:21 PM
> To: Scott Scriven
> Cc: D. Stark - EZW; LCDproc list
> Subject: Re: [lcdproc] spectrum analyzer?
>
> Scott Scriven wrote:
>
> > Do you think a command-line parameter for frames-per-second
> > would be adaquate? LCDd could tell clients what speed it is
> > using when they connect.
>
> Probably. I imagine that's something that'd be nice to have down the road.
> Right now I just want to make it work. I've got a good understanding of
> how eXtace pulls its data from esound. But given the work load that just
> got dumped on me (I'm a web programmer) it's going to be rough finding
> time to work on it. If anyone wants to persue this before I get started on
> it, just say so. I really don't have the time to do it, but I
> want the functionality. Catch 22.
>
> Dirk
>
> -----------------------------------------------------------
> To unsubscribe from this list send a blank message to
> lcdproc-unsubscribe AT lists.omnipotent.net
>
> -----------------------------------------------------------
> To unsubscribe from this list send a blank message to
> lcdproc-unsubscribe AT lists.omnipotent.net

--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
pub 1024D/A877CBC6 1999-12-28 Harald Klein _linux@chello.at_
sub 4096g/1577CF5F fp = EE17 F2F0 7986 FDC6 F147 B826 3FA1 452A A877
CBC6


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT lists.omnipotent.net




Archive powered by MHonArc 2.6.18.

Top of page