High CPU usage on macOS using COffscreenContext

Hi,

I’m trying to diagnose high cpu usage on macOS with vstgui 4.4. My application is standalone using the plugguieditor. The problem seems to be with a COffscreenContext that I’m using as a ring buffer for a scrolling meter. I’m attaching a pic showing the part of the UI with the scrolling meter and some information from instruments. The scrolling meter that uses the COffsreenContext as a ring buffer is outlined in red in the picture.

I’m running the application on a i3 mac mini, but I also see high cpu using on my 2017 MacBook Pro. The same code runs very smoothly on my PC. Any ideas?

Also, would I be better off using a CBitmap as my ring buffer and drawing to it using CBitmapPixelAccess? It seems that if I want to use vstgui 4.5 or greater, this might be my only option as COffscreenContexts work differently from 4.5 and up.

Regards,
Rob

After full days of optimizations and verifying that my UI is only updating the correct views, I’m still making no progress on this.

I’m trying to set a breakpoint in VSTGUI_NSView_drawRect from nsviewframe.mm to see what is actually being drawn by the system, but xcode refuses to break there. Any ideas how I can verify what rectangle the system is actually drawing?

Not sure if it helps, but here is how I’m creating my editor.

    [self.window setFrame:frame display:YES animate:YES];
    
    NSView* view = self.window.contentView;
    CRect r (0, 0, view.bounds.size.width, view.bounds.size.height);

    [[self window] setContentAspectRatio:NSMakeSize(view.bounds.size.width, view.bounds.size.height)];    
    
    editor = new Editor((__bridge void*)view);

Would implementing that view as a COoenGLView help?

I’m going to go ahead and say the OpenGLView is the way to go. I cut and pasted some code from the OpenGLView example in the tests folder, and the 3D pyramid run smoothly on macOS, adding almost no additional CPU load.

Hi,
you can try to put your view with the “scrolling meter” into a CLayeredViewContainer and see if it helps.

Cheers,
Arne

Thank-you. I will try that.

Hi Arne,

Putting the view in a CLayeredViewContainer did not improve performance. I’m seeing significant performance issues when using COffscreenContexts on macOS / iOS in general. Drawing with OGL is by far the most efficient, but even redrawing the entire scrolling view from scratch each time (which is about 300 line segments) is significantly more efficient, at least in terms of CPU, than using a COffscreenContext as a ring buffer.

Regards,
Rob

I am not sure if it will be 100% relevant, but for my vst plugin, I use a COfffScreenContext to generate a bitmap (which is then cached) and the bitmap is drawn into the view. I have no performance problems (on macOS).

Here is the code (source: vst-sam-spl-64/SampleDisplayView.cpp at v1.4.0 · pongasoft/vst-sam-spl-64 · GitHub)

void SampleDisplayView::generateBitmap(SampleData const &iSampleData)
{
  // TODO: optimization: load -> mono -> compute summary at the same time

  auto buffers = iSampleData.load(*fSampleRate);
  if(buffers && buffers->hasSamples())
  {
    //buffers = buffers->toMono();

    auto context = COffscreenContext::create(getFrame(), getWidth(), getHeight(), getFrame()->getScaleFactor());

    fBitmap = Waveform::createBitmap(context,
                                     buffers.get(),
                                     {getWaveformColor(), getWaveformAxisColor(), 2, getMargin()});
  }
  else
    fBitmap = nullptr;
}

The content is pretty complicated because it is the waveform of a sample

Yan

After updating to version 4.9, performance on macOS has improved dramatically.