New openGL() mode identifier

Announcements
1

We’ve seen in recent months that graphic intensive plugins cause glitches in Reaper on Windows. The audio thread is not affected, but the VU meters and scrubber often stutter a little. To combat this I’ve added a new openGL() identifier for the form widget. It will cause plugin graphics to be rendered using the GPU instead of the CPU software renderer. It is off by default. In plugins that are constantly updating GUIs it can lead to better UI performance and in some cases better CPU.

I can’t say whether performance will always be better, it really depends on what you are doing. But it is worth testing before you share your plugins. It’s available to test in v2.7.7 which is currently being built in Azure.

2

The openGL thing is great and essential. I have tried it and the response is very agile.
Like the recent PDC form code, which is now adjustable, would it be possible to select the openGL mode handle, active or not?
I think it would be very comfortable for the end user.

It’s a luxury Rory, to have these improvements. :+1:

3

I’m not sure how easy it might be to do, but it’s worth a shot :wink:

4

I’ve just added this now. The following instrument will let you toggle between openGL and the software renderer.

<Cabbage>
form caption("Untitled") size(400, 300), guiMode("queue") colour(58, 110, 182), pluginId("def1")
checkbox bounds(10, 10, 100, 20), channel("openGL"), text("OpenGL")
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d --midi-key=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
; Initialize the global variables. 
ksmps = 32
nchnls = 2
0dbfs = 1

instr 1
   kOpenGL, kTrig cabbageGetValue "openGL"
   cabbageSet kTrig, "form", "openGL", kOpenGL
endin

</CsInstruments>
<CsScore>
i1 0 z
</CsScore>
</CsoundSynthesizer>
5

I wonder, how would the openGL-mode work on old and/or weak computers/laptops compared to the normal mode? Laptop GPUs are often pretty weak right?

6

What a surprise! :wink:
I will do the tests in a project that I am finishing and I will tell you how it goes.
Thanks Rory! :+1:

7

If the laptop is old enough it might not work at all. I think giving users the option is a good idea.

8

OpenGL works fine, but the font thickness changes when activated.

9

Is this with custom fonts or just the default font? I will need to test in a plugin. In the IDE it doesn’t seem to cause any difference.

10

I just tested with a plugin now and I see the issue. I just pushed a fix for this. Let me know how it works out.

11

Tomorrow I will try again with the background image, because I get stripes and the zoom to 200% gives some problems with the mouse coordinates :face_with_monocle:

12

I just did these tests:

Cababge 2.7.8_1 (openGL in form):

  • Resizing to 200% there is coordinate deviation
  • The black lines do not appear because it is always active

Cababge 2.7.8_2 (openGL on-off):

  • Resizing to 200% there is coordinate deviation
  • Black lines appear when deactivating.

Disabling openGL, everything is fine.

13

Hmm :thinking: Perhaps I should try disabling and renabled openGL mode when resizing the plugin? I’ll try that now and let you know..

14

@Gerbo, I think this is fixed now. It seems openGL works best with power of 2 textures sizes. Can you try it out and let me know? Thanks God for the JUCE forum in moments like these, I know so little about graphics rendering, I would never have thought of that :rofl:

15

OpenGL test build 2.7.8 (3fc69c4)

  • REAPER:
    VST3: 200% zoom, gives down coordinate error. Black lines in all percentages except 100% an 200%

    VST: zoom 200%, gives error of coordinates down (no black lines).

    AU: 200% zoom, gives down coordinate error (black lines in less quantity).

  • LOGIC:
    Zoom 200% OK, (black lines in less quantity) at 100% and 200%, no appear.

  • CUBASE:
    VST3: 200% OK. Black lines in all percentages except 100% and 200%

    VST: 200% OK, (no black lines)

  • STUDIO ONE / ABLETON LIVE
    VST3: 200% OK. Black lines in all percentages except 100% and 200%

    VST: 200% OK, (no black lines)
    AU: 200% OK, (black lines in less quantity) at 100% and 200%, no appear.

In summary, VST3 generates black lines with openGL active, in greater quantity than the other formats and REAPER does not support that 200% with large plugins in any of the formats.
VST, seems to work better.

This is the file I’m testing with:
openGL-Resize.zip (107.8 KB)

16

Tanks @Gerbo once again for your keen eye! I’ll test here. In my simple tests it was working fine for VST, but I didn’t check other formats. I’ll keep you posted.

17

Especially by the eye :rofl:

18

In case it helps; With openGL () on the form, the black lines do not appear, but the problem remains with the 200% zoom in REAPER :face_with_monocle:

19

No issues here with VST2? Perhaps it’s a GPU issue? Also, note that the mouse coordinate also seem to scale accordingly. Are you testing your own build of the public beta version? I pushed a second one last night that added the flag. Maybe you used the second last one by accident?

20

VST2 does not give me black line problems either, but the 200% zoom does.

I have re-downloaded, both from azure, and built since the last beta. I have checked AppConfig.h, and the flags appear.
VST3, is the most problematic in my tests.
AU, a little less and similar to VST2

So I want to know if it is my GPU that gives these errors. Anyway I am using openGL applications, even audio plugins with this option and everything seems to be going well.


You already tell me what crafts you have scheduled this summer … :wink: