[Qt-interest] real time strip chart

[giovanni drogo]

On Mon, May 23, 2011 at 5:47 PM, Atlant Schmidt
<aschmidt at dekaresearch.com> wrote:
>
> Giovanni:
>
>
>
> > It is too slow. ... Incoming data are faster than one sample for pixel,
>
>   I’m not sure I understood this correctly, but what I think
>   you’re saying here is that each “column” of your strip-chart
>   output can contain multiple samples *FROM EACH CHANNEL*
>   because the overall time that each column represents is longer
>   than the sample interval of the data so you get (say) ten samples
>   from each channel being displayed in the same column.

exactly this way

>
> > Moreover there are problems when the traces cross together
>
>   Well, that depends on how you want to represent intersections between
>   the traces, doesn’t it?
In any case it can be managed
>
> > QT, scaling the time axis and plotting with antialiasing
>
>   I assume you’re not really talking about anti-aliasing per se but rather
>   “envelope display mode” where one draws, for each trace, a line
>   segment that spans from the maximum to the minimum data value
>   recorded for that trace for that column.
That was my old way to plot traces. It is very fast and efficient,
however somebody objected that traces are not
so nice..... with real antialiasing they looks much better (and to
instruct QT to use it,
only one instruction is needed). Today computers may afford the overhead.

In fact my problem is not to draw the traces and scroll the image in main memory
(it takes about 2msec (real time and CPU time)) on the 20msec
available, but to copy it on the screen.

G.Drogo
>
>                                    Atlant
>
>
>
> ________________________________
>
> From: qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com [mailto:qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com] On Behalf Of giovanni drogo
> Sent: Monday, May 23, 2011 11:30
> To: qt-interest at qt.nokia.com
> Subject: Re: [Qt-interest] real time strip chart
>
>
>
> >
>
> >> You might be better off erasing all data points (1 pixel per x) and writing
>
> >> the new one.
>
> >
>
> >  That’s a clever idea and our original questioner should definitely benchmark
>
>
>
> >  that; depending on how many traces are being drawn simultaneously, I
>
> >  wouldn’t be surprised if that’s the winner!
>
> >
>
> >                                       Atlant
>
>
>
> It is too slow. One of the reasons to try to use QT was to have a nice graphic with minimal programming efforts.
>
>
>
> Incoming data are faster than one sample for pixel, but, using QT, scaling the time axis and plotting with antialiasing is very easy.
>
> However CPU usage is reasonable for plotting the few new pixel I scrolled, too high to re-plot two times the whole trace.
>
>
>
>
>
> Moreover there are problems when the traces cross together.
>
>
>
> G.Drogo
>
>
>
> Click here to report this email as spam.
>
> ________________________________
> This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.