Sluggish zooming of AudioThumbnail with large files

[maaaaaaark]

Edit: maybe I wasn’t clear enough on how to reproduce this problem:

1. open projucer on an m-series mac
2. from projucer open JUCE/examples/Plugins/SamplerPluginDemo.h
3. click on the xcode generator which opens xcode
4. in xcode change the scheme to Sampler Plugin - Standalone Plugin
5. click run button and the sampler plugin demo will appear with a small file loaded
6. click “load new sample” and open a file > 90 seconds (this will take a long time to load because SamplerPluginDemo.h uses a very small sourceSamplesPerThumbnailSample, but that is not the issue here)
7. click in the ruler and drag up and down to zoom in and out. When I do this I see very bad performance

Edit: ok, good news (I think). Got Visual Studio running on a gaming pc, nothing special, i7-13700h with an nvidia 4060 (which I assume is not being used here due to there being no opengl?) SamplerAudioPlugin has no problem at all zooming in and out of a large waveform, very fast and smooth. I assume this is a problem related to Sequoia.

Greetings, new to JUCE and currently (re)learning c++, having a great time with both! My app will involve manipulating large samples, over 1 minute, maybe up to 5, and with AudioThumbnail zooming in and out, scrolling, and even just moving the plugin window around are extremely sluggish. Video examples are attached.

I have been adapting the JUCE example SamplerAudioPlugin.h for my own uses. Both my adapted code and SamplerAudioPlugin struggle with zooming large files. I’m using the develop branch of JUCE 8.0.4, just pulled yesterday and built with Release on an M1 Mac with Sequoia 15.1. Xcode 16.0, Apple clang version 16.0.0 (clang-1600.0.26.3).

I have tried downsampling a 90 second file from 44.1k to 1k. I have tried sourceSamplesPerThumbnailSample at 512 and 8192. I’ve tried both Debug and Release builds and not noticed a difference. Relevant code section here:

WaveformView (const DataModel& model,
                  const VisibleRangeDataModel& vr)
        : dataModel (model),
          visibleRange (vr),
          thumbnailCache (64), 
          thumbnail (8192, dataModel.getAudioFormatManager(), thumbnailCache)
    {

I’ve spent a lot of time searching through the forum and while I see complaints about the appearance of the waveform, the consensus seems to be that AudioThumbnail is fast. So I’m confused. Is SamplerAudioPlugin not a good example of how to use AudioThumbnail? Am I asking too much of it?

https://youtu.be/MQn-rV9_GRw 90secs 8192samplesPerSample 44.1k SR
https://youtu.be/MEBmctspWM4 90secs-512samplesPerSample-44.1k SR
https://youtu.be/z3ebulzm0jc 90secs 8192samplesPerSample 1k SR
https://youtu.be/djAHik52LiY 90secs 512samplesPerSample 1k SR

[ibisum]

@maaaaaaark

JUCE 8.0.4,

Please try your same testing situation with 7.0.12. JUCE 8.0.x has undergone some significant architecture changes which can impact graphics/drawing performance (which the team are actively engaging on), so it would be important to do the testing on the prior (stable) version of JUCE, see if there is indeed a difference in performance, and then report the details.

See also, JUCE-develop branch, which may already have fixes. Note, there is no such thing as an “8.0.4” develop branch - its either 8.0.4, or its develop:

7ba1107d24afee5318e17f1b27cbf097201d8880 commit	refs/remotes/origin/develop
51d11a2be6d5c97ccf12b4e5e827006e19f0555a commit	refs/remotes/origin/HEAD
51d11a2be6d5c97ccf12b4e5e827006e19f0555a commit	refs/remotes/origin/master
51d11a2be6d5c97ccf12b4e5e827006e19f0555a commit	refs/tags/8.0.4
5179f4e720d8406ebd1b5401c86aea8da6cc83c9 commit	refs/tags/8.0.3
4ada2e1f4db082f5dd803f249f37b3bf9c5f55ef commit	refs/tags/8.0.2
46c2a95905abffe41a7aa002c70fb30bd3b626ef commit	refs/tags/8.0.1
adcdaad34f871bcb96df3748610b85e882420136 commit	refs/heads/develop
61a03097ec9e01693c87ac71935e97b9714cff1a commit	refs/heads/master
61a03097ec9e01693c87ac71935e97b9714cff1a commit	refs/remotes/origin/juce8
61a03097ec9e01693c87ac71935e97b9714cff1a commit	refs/tags/8.0.0
4f43011b96eb0636104cb3e433894cda98243626 commit	refs/tags/7.0.12

[maaaaaaark]

@ibisum

4f43011b96eb0636104cb3e433894cda98243626

I have tested both with 8.0.4 release and develop pulled yesterday.

I tried your suggestion using 7.0.12 and the performance is just as bad. An interesting note: when the waveform is visible, dragging the window around is extremely slow, but when switching to the MPE settings tab the window can be moved around like any window you’d expect on an m1 mac

Edit: Apologies, the above is incorrect. The window could always be dragged around just fine, but resizing is extremely slow and that behavior is the same regardless of the type of window

[maaaaaaark]

For anyone else running into this issue the preprocessor definition JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS=1 has greatly improved the performance on macos 15.1 when zooming a waveform in using AudioThumbnail in the SamplerAudioPlugin example

[aamf]

What exactly do you mean with “greatly improved”? Does it work as expected, that is, as well as it does on Windows?

[maaaaaaark]

I tried the windows version for just a few seconds to confirm that it was possible to get acceptable rendering from the SamplerPluginDemo and then put the machine away, so I can’t compare side by side. But I’d say the windows version was better.

In the first screenshot Xcode shows around 14 fps with JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.

In the second screenshot it shows 0 fps (not sure what that means) without it. The videos in my original post show something that looks like it goes as low as ~1 fps.