LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: dglaude AT netbrain.be (David Glaude)
  • Subject: [lcdproc] spectrum analyzer? --> Frame per second...
  • Date: Mon, 28 Feb 2000 19:16:32 +0100

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




Archive powered by MHonArc 2.6.18.

Top of page