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