Re: [question/testing] SoundFileView improvements
scott-y6qSm6YX8/[email protected] Tue, 10 Apr 2018 23:07:26 +0000
| Newsgroups | gmane.comp.audio.supercollider.devel |
|---|---|
| Message-ID | <CANmfHJ-+qdLqYSeb+ibE6ZY2YLuvGmwn4fkKwVNBz5cL77EH2Q@mail.gmail.com> |
Seems reasonable to me if the performance isn't any different - floats make for a much cleaner implementation. On Tue, Apr 10, 2018 at 3:45 PM <[email protected]> wrote: > I figured out how to preserve cache in SHORTs and set the scaling > dynamically when reading the file, reworked everything... and got the same > (slower) result as when I was working with floats. > Turns out I was building in "debug".... > > So after switching to RelWithDebInfo, I'm getting very similar performance > when using cache in SHORTs vs FLOATs. In this case do you think it is > reasonable to just switch to floats? > > Thanks, > Marcin > > On Fri, Apr 6, 2018 at 1:53 PM, Marcin PÄ…czkowski <[email protected]> > wrote: > >> Thanks for the suggestions, Scott. >> >> In further working on this, I came to realize that: >> - we can stick to short_int, since: >> - we can't set the data after loading a soundfile, so setting min/max >> values from the soundfile would fix representation of float soundfiles >> - I'd add maxValue parameter to the allocate and setData methods, to >> provide that control to the user when plotting data from the language >> >> >>> 1. p.drawLine( x + i, min, x + i, max ); >>> p.drawLine( x + i, minRMS[i], x + i, maxRMS[i] ); >>> These might be faster if they were a 1px wide fillRect. >>> >> Maybe I'll try these later in my branch. >> >> 2. compositionMode of the pen should be QPainter::CompositionMode_Source >>> >> Will try... >> >> >>> 3. p.setClipping(true); p.setClipRect( x, -halfChH, x+width, chHeight ); >>> I believe it would be cheaper to guarantee the ranges of our values >>> either when we calculate in displayData, or inline in our inner loop. >>> >> Yeah, I'll remove this clipping. I'll need to ensure data range in >> displayData anyway and my whole point is to be able to draw values outside >> this range. >> >> >>> 4. Drawing vertical lines is bad for cache coherence and eliminates >>> possibilities for vectorization. It MIGHT be worth experimenting with >>> rotating the pixmap 90 degrees and drawing that way (so we have horizontal >>> scanlines), and then rotating back to the correct orientation when we do >>> drawPixmap, in hopes that Qt has either optimized the 90 degree rotation >>> case or vectorized horizontal line drawing. >>> >> I'm not sure I'll get to trying this... but it's an interesting concept. >> >> Anyway, I'll keep working on this and will probably submit a PR once it's >> in a working state. >> >> Marcin >> > >