> I'm trying to build a system for real-time data monitoring. Basically what I
> need is a XY-plot with time on x-axis and some sort of a ring buffer ( or
> shifting of static buffer) for adding the latest data to the end and removing
> the first data from the beginning.
>
> With just one plot: simple. With more than that?
>
> If I set two plots and once a second update them both, the plots do not
> update properly but occasionally tickmarks, axislabels etc. just flash and
> disappear. This I managed to solve by using fl_set_object_dblbuffer(obj,1)
> (without really understanding what it means. Could someone clarify?)
> The same effect reappeared when I was using fl_freeze_form...
Is that flashing just momentary? I did a quick test and observed a
bit of that when the update rate was fairly high (say faster than
about 250 milliseconds). I expect this is just an artifact of the
speed of your X server more than an XForms problem, per se. A faster
server or a faster connection to that server if you're running over a
network would probably cause most of that to go away. When I get over
into the other lab, I'll try it on our RE2 to see if the problem
persists.
As to what fl_set_object_dblbuffer() does -- it double buffers the
output. By default the display's front frame buffer (the one you're
looking at) is your buffer and that's where XForms draws. Since most
XForms (and, in general, X) applications are relatively static, this
is just dandy. There may be a slight amount of flicker as the Window
is originally drawn but this is only momentary.
In some applications, however, the display is updated a great deal and
this flashing and flicker becomes annoying and distracting, not to
mention aesthetically displeasing. To eliminate this flicker, XForms
can be told to draw all of its objects into an off screen (or back)
buffer and then once it has completed all of its drawing, do a very
fast copy of the pixels in that buffer to the display's frame buffer.
Since most modern display interfaces are pretty good at BITBLT
operations, the update is virtually instantaneous.
This eliminates the flicker.
I'm not sure about the internals of fl_freeze_form() but I'd expect
that all of the drawing instructions are simply bundled up together
and shipped off to the X server at once, as soon as fl_unfreeze_form()
is called. Since you're still effectively seeing the drawing
instructions being executed, you're going to see flicker as the image
is erased and redrawn. Remember, plots are generally pretty
complicated in terms of the number of graphical instructions which are
needed to complete them.
> Next problem: using the same data on both plots I noticed, that occasionally
> one of the plots was a second behind.
> Using fl_redraw_form(form) produced REALLY weird results. About every other
> second either or both of the plots and a button on the form disappeared! (not
> exactly every other second, but randomly). Fortunately updating both plots
> with fl_redraw_object(object) didn't have the same effect, so I could
> continue.
I didn't see that problem in my test code but my test was pretty
stoneaxe and I only had a couple of objects on the form. Again, my
guess is that you're seeing the redraws happening.
My suggestion is to go back and use fl_set_object_dblbuffer(), since
this seems to give the best results.
> The next problem can be put into a single question: WHY FLOAT? Why not
> double, which is more accurate and useful (at least for me :-) )?
Can you actually *see* double precision in a plot? The only place I
can see the need for double precision is in the extended exponent
range. Extra bits of accuracy themselves are simply thrown on the
floor when they're displayed anyhow. I suppose that there are
pathological cases where you might need that extra precision in plots
but I'd be hard pressed to actually come up with a practical situation
where the difference in the least significant bit would be all that
important.
> The natural selection for describing time is of course the unix definition
> (seconds since 00:00:00 UTC Jan 1 1970). Unfortunately (at least in intel
> linux) the mantissa of float is 24 bits long. With 24 bits you can represent
> accurately only 16777216 seconds=194 days which is far too short a time.
> Double's mantissa is (I think) 52 bits which would last for the next 100
> million years...
>
> I know that double takes more memory and in most plots float is more than
> adequate, but at least I have shown one place where a better resolution would
> be needed (I don't need year's plot with one second interval. I need a system
> that can be used anytime...)
I guess I don't completely understand what you're doing.
Do you mean that you're displaying the number of seconds since the
Unix epoch along the abscissa? Does 884011456 (the current number of
seconds since the Unix epoch at the moment I wrote this) tell you
anything meaningful without doing some sort of conversion? It would
seem to me that the interval since some more recent starting point is
more of interest than the absolute time.
However, it's your application, of course.
> The only solution that I came up with was to use a static X-values from zero
> to the width of the plot and use fl_add_xyplot_text/fl_delete_xyplot_text.
> Again: Flashing.
>
> Running out of options...
I think you've hit upon the correct option: Use double buffering.
This will make most of your problems (other than the perceived lack of
precision) go away.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bloch.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/