My question for devs is: considering HiDPI support and the need to calculate more and more pixels for bigger and bigger monitors... how about introducing GPU acceleration to Reaper, so that running a project with 100s of tracks doesn't become impossible to use because GUI becomes way too sluggish because it's calculated by the CPU?

My question for the devs is: considering HiDPI support and the need to calculate more and more pixels for bigger and bigger monitors... how about introducing GPU acceleration to Reaper, so that running a project with 100s of tracks doesn't become impossible to use because GUI becomes way too sluggish because it's calculated by the CPU?

How about some optimizations in that direction?

This build actually improves the Retina-mode GUI sluggishness I've been experiencing for many many releases now on my iMac Pro. I've been forced to run Reaper in Low Res mode to get the UI to not be unusably sluggish, but this build is a huge improvement in Retina mode.

My question for devs is: considering HiDPI support and the need to calculate more and more pixels for bigger and bigger monitors... how about introducing GPU acceleration to Reaper, so that running a project with 100s of tracks doesn't become impossible to use because GUI becomes way too sluggish because it's calculated by the CPU?

This build actually improves the Retina-mode GUI sluggishness I've been experiencing for many many releases now on my iMac Pro. I've been forced to run Reaper in Low Res mode to get the UI to not be unusably sluggish, but this build is a huge improvement in Retina mode.

The issue also happens for non-HiDPI users. Large number of tracks bogs down the response of the UI considerably, sometimes to the point of unusable. GUI accelleration would help here, and relieve the load from the CPU. Both HiDPI and non-HiDPI users would benefit...

The issue also happens for non-HiDPI users. Large number of tracks bogs down the response of the UI considerably, sometimes to the point of unusable. GUI accelleration would help here, and relieve the load from the CPU. Both HiDPI and non-HiDPI users would benefit...

I might be wrong but I don't think rendering of pixels is the expensive part, usually the slowness comes from getting peaks data from disk etc. (a good test would be to try disabling peaks display in the prefs and see how that helps).

I might be wrong but I don't think rendering of pixels is the expensive part, usually the slowness comes from getting peaks data from disk etc. (a good test would be to try disabling peaks display in the prefs and see how that helps).

What I'm mentioning is the case with MIDI-heavy projects, so no audio in the project. Like Kontakt-heavy orchestral templates with 1000-2000 and more tracks, lots of things preloaded, etc.

By the way, I just had to reset my computer after trying to copy-paste empty unarmed tracks in Reaper. I got to around 1500 tracks, then when I pasted the next 512, CPU got around 70% and Reaper unresponsive, I couldn't alt-tab between any programs, just had to reset it...

I know that's a completely different issue (no peaks are at play here), but still... this sort of thing should not happen, right?

Yes but it's important to know what the cause of the slowdown is. Adding GPU acceleration when it would accelerate the part that takes a tiny portion of the time would be useless.

Quote:

By the way, I just had to reset my computer after trying to copy-paste empty unarmed tracks in Reaper. I got to around 1500 tracks, then when I pasted the next 512, CPU got around 70% and Reaper unresponsive, I couldn't alt-tab between any programs, just had to reset it...

I know that's a completely different issue (no peaks are at play here), but still... this sort of thing should not happen, right?

Tried it, got a BSOD now (CLOCK_WATCHDOG_TIMEOUT) when going from 512 to 1024 tracks in a single copy operation. Actually, did you mean the audio processing threads count option in Audio->Buffering, or the one in Advanced UI/system tweaks? I tried the former. Lemme try the latter now. (EDIT: no BSOD but still had to restart.)

I suppose copying 512 tracks in one go is not a good idea. Still, I wouldn't expect a complete system halt.

I notice when copying a larger amount of tracks, the first few tracks show up really fast on the UI (what fits within the viewport), but then Reaper is probably filling the out-of-screen buffer (if there is any, I suppose there is?) with all those other tracks, and THIS is what makes things severely unresponsive with larger track copying actions.

I suppose copying 512 tracks in one go is not a good idea. Still, I wouldn't expect a complete system halt.

Your case is pretty extreme... but it does show a trend or a risk of some sorts regarding the code that runs the UI etc... I hope it'll get looked into even if very few would go to those extremes when using the software it would make it much more stable and might reveal some issues that only show heir heads in those extreme cases

But regarding the GPU acceleration, I'm kinda with ED on this one, I've had to disable some UI stuff to make sure there's as little CPU cycles put to anything else than rendering the audio. I get spurious buffer under-runs when scrolling around and as such I've disabled the screen following of the play cursor to make sure I don't get one when recording.

Drawing peaks during recording is also something that takes cycles and eats away at those precious precious time slices from interrupts so it's disabled just in case.

If I have large mixer with 20+ tracks with meters visible, that can cause issues as well some times.

In general, having GPU do graphics with little to no load on the processor is a good idea. Though it's a large amount of work (I've done some OpenGL stuff and it's not trivial). But when you get those VBO's (Or are they already using something else these days?) to do the rendering work for you the CPU is basically dead weight in the equation and can do something more suitable ;D

Though, if I recall when reading the VST specification many years ago, each plugin chooses how they render their graphics on their own? They are just child processes that are just run by another program that interacts with them. Thus devs probably can't do much if anything regarding those third party plugins and their UI hogging CPU cycles.

But anyway... it's not a huge issue currently. There are much more... pressing matters to attend to I'm sure

Thank you for constantly developing REAPER, it has taken a really large leap during 5.xxx.

My question for devs is: considering HiDPI support and the need to calculate more and more pixels for bigger and bigger monitors... how about introducing GPU acceleration to Reaper, so that running a project with 100s of tracks doesn't become impossible to use because GUI becomes way too sluggish because it's calculated by the CPU?

Though, if I recall when reading the VST specification many years ago, each plugin chooses how they render their graphics on their own? They are just child processes that are just run by another program that interacts with them. Thus devs probably can't do much if anything regarding those third party plugins and their UI hogging CPU cycles.

Yes, thanks for bringing this up ED!
I'm a composer for media by trait, with my main focus on orchestral productions. I've been using Cubase for many years and for the first got really seriously into REAPER this past month or so.
What can I say, I'm absolutely hooked and would love nothing more than to finally ditch Cubase (we've had a hate-love relationship for many years now ). Unfortunately there are 2 main problems that prevent me from doing so and I think this applies to many other people who do the same stuff that I do:

- Probably the biggest one is that on my 4k display I can't even have a project with ~100 tracks without the UI becoming completely laggy and unresponsive. I just recently posted about this [here.]
- The other big problem is that you can't really build a large template. In my line of work it is completely common to have project templates with 1000s of tracks. For example my main Cubase template has around 2700 tracks. All these tracks are 'deactivated', so they don't use any CPU or RAM whatsoever and can be reactivated for usage at any time you need them.
Unfortunately this isn't really possible in REAPER, because of how every track uses CPU even if it is idle. It would be great if there was a way, to have idle tracks not use any CPU (for example with a native deactivation feature as recently discussed [here]), so that it's possible to build these massive templates.

The 2nd problem is a bit less urgent to me than the first (for people without a 4k display it might be the other way around), since track templates work really well and I've compromised to have an empty template and load stuff in as I go. But as great as track templates work, having everything pre-loaded is still quite a bit faster and preferable for me and most people I know who do similar work.

v5.979+dev0618 has broken the Default 5.0 HiDPI theme and my themes (https://forum.cockos.com/showthread.php?t=217825) based off of the Default 5.0 HiDPI theme (and the JRENG!_METRIC theme). It seems that 'version 5' 'global_scale 2.0' no longer works for me* on Windows 10 x64...

*I'm not using a HiDPI screen (27" 1920x1080 monitor). I was using the HiDPI version for a larger / clearer interface & text, due to my poor vision and my workflow not needing to see a zillion tracks at once...

White Tie warned me that there would be changes and my work may get broken.

Using v5.979+dev0618, if I select: scale UI elements by: 2.00 (under Advanced UI/system Settings), it brings back most elements to the correct size but some text looks grainy and the faders for the native plugins / routing window (and other windows...) remain small / broken.

Currently, with the Default 6.0 Alpha theme, I can select 150% or 200% in the Options / Layouts menu but it doesn't affect the whole interface. Only affects the Transport / ENVCP / MCP / TCP. Not the Toolbars / Timeline / Regions / Markers, etc...

Should I assume that for my needs / specific usage, my themes will no longer work correctly as of REAPER v6?

Just looking for clarification if possible... I realize that my needs are not of the many! B)

i experience much greater lag when using (one midi editor per project / open all midi in project / all midi visible, other tracks at 2 opacity).

if i instead show only the single track midi, i don't get the same lag.

this rears its head once the rpp grows more complex. for reference, i experience this with ~8 midi tracks containing single channel midi items containing non-outrageous, often monophonic melody lines with the occasional pitchbend/cc movements.

unfortunately, the scenario of a complex project is precisely where seeing all project midi is helpful - but this is when the UI lag occurs. i'm lucky that most of my songs are nearing completion at around the time when this UI lag starts being a problem.

v5.979+dev0618 has broken the Default 5.0 HiDPI theme and my themes (https://forum.cockos.com/showthread.php?t=217825) based off of the Default 5.0 HiDPI theme (and the JRENG!_METRIC theme). It seems that 'version 5' 'global_scale 2.0' no longer works for me* on Windows 10 x64...

*I'm not using a HiDPI screen (27" 1920x1080 monitor). I was using the HiDPI version for a larger / clearer interface & text, due to my poor vision and my workflow not needing to see a zillion tracks at once...

White Tie warned me that there would be changes and my work may get broken.

Using v5.979+dev0618, if I select: scale UI elements by: 2.00 (under Advanced UI/system Settings), it brings back most elements to the correct size but some text looks grainy and the faders for the native plugins / routing window (and other windows...) remain small / broken.

Currently, with the Default 6.0 Alpha theme, I can select 150% or 200% in the Options / Layouts menu but it doesn't affect the whole interface. Only affects the Transport / ENVCP / MCP / TCP. Not the Toolbars / Timeline / Regions / Markers, etc...

Should I assume that for my needs / specific usage, my themes will no longer work correctly as of REAPER v6?

Just looking for clarification if possible... I realize that my needs are not of the many! B)

Hi, in 5.979+dev0618+ if you want the larger themes, you should go to preferences/general/advanced, and check the
"Scaling UI elements of track/mixer panels" box, and set the value next to it to 2.0 (or 1.5, or...).

That, combined with the Default 5.0 HiDPI theme, will give you similar results to 5.979.

With the retina changes & improvements here I'm hopeful the GUI lag situation can be addressed in a major way, here's some observations from my setup:

- On my iMac Pro with Vega 64 graphics (which has tons of power), Reaper has extreme GUI lag. One solution is to run it in Low Res mode, the other solution is to switch the colour profile of the display to sRGB IEC61966-2.1 in System Preferences. The colour profile fix apparently fixes GUI lag in other apps which exhibit similar GUI lag.

Also, Voxengo have been updating their plugins with Retina GUI support, but their older non-Retina versions exhibited the same extreme lag on my iMac Pro, and the new Retina updates seem to have fixed it completely.

- On my MacBook Pro, Reaper is fine. No need to switch to Low Res mode or use a different colour profile, and the non-Retina Voxengo plugins never had an issue.

So there's definitely something specific to iMacs / iMac Pros with 5K screens where somehow GUI lag seems connected to a lack of a full Retina GUI implementation. Just adding that alone seems to fix the problem.

I'm definitely all for GPU acceleration in Reaper too, I guess the question is how to do that in a cross-platform way given OpenGL's deprecation on Mac.

At 1024 tracks the system is using 75% cpu, 41% rt cpu, and once it began to work was largely unresponsive, and certainly not usable. Moving the playhead took on average 10s.

Also, going from 512 to 1024 took around 5 minutes to complete, during which time the program was locked
Deleting the tracks hung the program and I killed it after 5 minutes of waiting.

3rd test, 1024 tracks but with the fx in the chain set to offline

Performance is slightly better here, 60% cpu, 30% rt cpu
Playhead takes around 3s to move after a click, so it's almost usable, not tried any playback though.

4th 1024 tracks fx in the chain offline, tracks muted

Muting the tracks here gives an improvement in cpu to 7%, however rt cpu jumps to 55%, which would kill the playback performance if I were playing anything.

5th 1024 tracks fx in the chain disabled, tracks muted

Here I get 20% cpu, 63% rt cpu

In conclusion, it seems that the problem is not the actual empty tracks which is the problem, but the plugins on them. If you were to create a 5000 track template, you would want there to be plugins on there, or there would be no point in making it. I haven't found a way to do this without incurring some sort of slowdown as a result.
Muting tracks seems to shift the problem into the rt cpu, and setting plugins to offline seems to still have a large impact.

These are not scientific tests, but I hope they can give an indicator of where the problems lie