[Qt-interest] real time strip chart

[Atlant Schmidt]

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.


> 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 a black-and-white (bitonal) trace, there's no
  problem; a pixel is either foreground or background no matter how
  many traces contributed to it; just make sure you do all the erasures
  (from all channels) first followed by all the pixel-setting operations.

  In a multicolor trace, you can choose to draw traces in a specific
  Z-order.

  Or you can do something fancier where traces overlap one-another,
  but that can get hard for the human to understand whereas we
  implicitly understand Z-ordered traces.


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

                                   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<https://www.mailcontrol.com/sr/mOxk29R2gEbTndxI!oX7UlFqrXJaieUT1zaiqvTf0AHYBXVwgslnAYu67!VmIzccRGtQFgjBKrAakVWf!6zCig==> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110523/32f9a432/attachment.html