Software UI rendering?

[70MM13-actual]

Version

26.02

Plugin type

VST3

OS

Windows 10 AND CachyOS Linux

DAW / Host (if applicable)

Reaper

Description

After a few years of occasional tinkering with cardinal to gauge improvements in usability I decided to use cardinal on an upcoming vinyl collector's reissue of one of my early releases from 40 years ago.

I noticed when creating a demanding setup that started to stutter that the situation suddenly improved dramatically when the cardinal gui was closed.

I created a new patch consisting exclusively of many blank panels, and looked at the cpu meter.

Not good. Should be zero. NOTHING BUT BLANK PANELS.

Close the gui, and the cpu usage drops.

Resume gui, reduce frame rate from the cardinal view menu, and cpu usage is slightly improved.

Scroll cardinal window scrollbar to reduce number of visible blank panels, and cpu usage improves accordingly. Evidence mounts.

It looks like the graphics are being generated in software...

Very 1980s, exactly the era of my original vinyl releases!

Tested on windows 10 (VST3) and cachyOS Linux (LV2). Performance was better on Linux, but still abysmal.

Confirmed on several computers running AMD and Nvidia GPUs.

[dromer]

Most of the graphics are rendered on the GPU actually, but when the GUI is open there is always some management required on the host side.

Are you doing everything in a single instance of Cardinal as well? I recommend splitting a patch up into different more minimal patches and let the plugin host handle multi-threading (most modern DAWs do this quite well). This should at least help with some of the CPU load.

[70MM13-actual]

Thanks for the suggestion. I was indeed using one instance. I'll try splitting it up. Hopefully this won't be required in the future! Thanks.

…

On Fri, Mar 6, 2026, 2:59 p.m. dreamer ***@***.***> wrote: *dromer* left a comment (DISTRHO/Cardinal#912) <#912 (comment)> Most of the graphics are rendered on the GPU actually, but when the GUI is open there is always some management required on the host side. Are you doing everything in a single instance of Cardinal as well? I recommend splitting a patch up into different more minimal patches and let the plugin host handle multi-threading (most modern DAWs do this quite well). This should at least help with some of the CPU load. — Reply to this email directly, view it on GitHub <#912 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGXRLINZWNWBQO645HDUHMD4PMU3FAVCNFSM6AAAAACWJYEPY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJTHAZTOOBZHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dromer]

Well it will depend on which modules, the amount of modules and how complex the patch is.

I think the UI thread should be fairly constant load though.

There is likely not many optimizations that can be done here.