mister nuke! thanks for response my motivation to "optimize analog data flow" was to implement an FFT spectrum analyzer for pulseview but i soon gave up that project, since i dont really need it ....
> I feel it getting very glitchy when zooming out on large data. > Does it draw more pixels than it needs? > Does it redraw pixels it already drew? > What can you make to make the program do less work? based on my superficial knowledge on pulseview: pv should repaint all visible datapoints on every zoom step that includes scaling and offsetting every point like y = scale * voltage + offset pulseview/pv/views/trace/analogsignal.cpp void AnalogSignal::paint_trace 1. it should be possible to cache the y values, so at least x-zoom is faster 2. (x, y) values could be averaged on zoom out to reduce the number of pixels to draw 3. the scale-and-offset operations could be moved to the GPU (vectorize....) by using an openGL widget as draw canvas, instead of the QPainter widget for example, see the tool openhantek, which is using openGL instructions https://github.com/OpenHantek/OpenHantek6022/blob/c56c66259ac3b6dfb761bad2a73b296acabd25f3/openhantek/src/glscope.cpp#L323 openhantek is using the "vertex method" to draw pixels, for reasons unknown the "texture method" is recommended for performance here https://stackoverflow.com/questions/4111485/drawing-large-numbers-of-pixels-in-opengl > Check "struct sr_datafeed_analog" thanks, already found that one .... "dear mila, just read the fucking source" 2020-09-29 17:43 GMT+02:00, Alex G <mr.nuke...@gmail.com>: > On 8/2/20 9:08 AM, milan hauth wrote: >> im trying to improve performance of pulseview >> and therefore i need raw values from the libsigrok driver > > I would look if you can optimize the algorithms. I feel it getting very > glitchy when zooming out on large data. > Does it draw more pixels than it needs? > Does it redraw pixels it already drew? > What can you make to make the program do less work? > >> my assumptions are >> * fixed point math / integer arithmetics is faster than float >> * multiplication is faster than division >> ** slow division can be replaced with fast bitshift > > You'll likely find out that floating-point arithmetic is the fastest way > do to things on a processor not in a museum. Organize data structures > such that the compiler can vectorize. You get four or eight calculations > per cycle. Integer hacks are no longer worthwhile IMO. > >> * benefits of float are not needed in my app >> (analog oscilloscope with 8bit vertical resolution, linear data) >> * scale and offset calculations should be done only once >> in the whole data pipeline from sensor to GUI (raw to pixel in just one >> step) >> * smaller data types perform better (memory speed) >> * fourier transform can be optimized to use the raw datatypes, >> like "kiss fft" for 16bit fixed point FFT >> * in a GUI app like pulseview, the real values (voltages) >> are needed much less often than "pixel values" >> so the real values can be calculated on demand >> >> i found this wiki entry >> https://sigrok.org/wiki/High_precision_analog >> #Exact_representation_of_raw_data_and_metadata >> >> with this link >> https://gitorious.org/~mrnuke/sigrok/libsigrok/commits/prec >> "for details of implementation proposal" >> >> .. but the link is broken > > I've given up on the high precision when I got my first 7.5 digit meter, > and realized a 32-bit float just doesn't have enough resolution. > >> https --> SSL_ERROR_RX_RECORD_TOO_LONG >> http --> Not Found >> archive/cache --> not found >> other repos --> not found >> >> so my questions are: >> 1. whats the status of this work? >> 2. is there code i can reuse? >> (where is the "implementation proposal" by mrnuke?) > > Check "struct sr_datafeed_analog" > > Alex > _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
