Re: [question/testing] SoundFileView improvements

Here's the PR <https://github.com/supercollider/supercollider/pull/3662/>.

On Tue, Apr 10, 2018 at 4:07 PM, <scott-y6qSm6YX8/[email protected]> wrote:

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