Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Feature Requests

Reply
 
Thread Tools Display Modes
Old 04-02-2019, 01:28 PM   #1
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default GPU graphic acceleration

I heard that Reaper does not utilize graphics acceleration to render the user interface. Is this true?

In the sprit of Reaper's preformance, I would assume that even on cheaper video cards, having the GPU process as much of Reaper's GUI and video playback instead of the CPU would equal quite a large preformance boost.

I experience very slow gui redraw rates compared to some of the other DAW I've worked in and it would be so great if I could get the GUI to be a bit snappier on my expensive Nvidia card.

Is there any stability or resource reason why Reaper does not utilize Graphics acceleration.
srdmusic is offline   Reply With Quote
Old 04-17-2019, 08:42 AM   #2
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Huge +1 for this.

In a large template, the GUI lag is well, terrible. Save your project? Video stops playing entirely. Scroll down in your template? Sometimes it freezes for several seconds and then finally moves. The list goes on and on. Resizing tracks, refreshing windows, etc.

I know cpu efficiency has been a high priority for the developers. Do yourself a huge favor here and leverage the GPU for hardware acceleration. It is sorely needed and truly necessary for Reaper's growth moving forward.

Yes, CPUs keep getting faster. But the demands placed on the CPU keep getting higher and higher and usually keep pace or even outpace CPU advancement. I don't see any way Reaper is going to maintain a satisfactory GUI response with all that is being asked of the CPU without making use of hardware acceleration.

And for those of you thinking maybe I should update my computer, here are my specs.

Xeon E5-2697A v4 x2 (32 cores at 3.1 GHz)
256GB of DDR4 Memory (running in quad channel at 2800 MHz)
Nvidia P4000 Graphics Card
Samsung 960 Pro 2TB NVMe drive for OS
4x Intel P3500 2TB NVMe drives in RAID0 for Samples

That's nothing to sneeze at. And I'm REALLY struggling with the GUI at high track count and I'm guessing most Reaper users don't have these kind of specs. Yes, there is faster stuff available (at frightening cost) and I'm sure Threadripper 3 will be a beast but really, a machine like the above shouldn't have issues with major GUI lag. That it does really points to the need for hardware acceleration in Reaper.
Klangfarben is offline   Reply With Quote
Old 04-17-2019, 09:06 AM   #3
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

Yep, so +1, Reaper is ultra fast in every aspect, but just not in terms of GUI,
especially with a lot of tracks.
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 04-17-2019, 11:15 AM   #4
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
Default

This would explain a lot of things I've been noticing with Reaper on bigger projects.

Big +1 here.
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 • Catalina • Mac Mini 2020 6 core i7 • 64GB RAM • OS: Catalina • 4K monitor • RME RayDAT card with Sync Card and extended Light Pipe.
Thonex is offline   Reply With Quote
Old 04-17-2019, 11:46 AM   #5
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,238
Default

I see many Track Inspector VIP users here
please tell me it is not Track Inspector causing this...
Because it should work the same independently of the number of tracks.
I guess this only affects soundtracks composers that use hundreds and hundreds of tracks. I also see notable performance hit when using many tracks. But I still don't have enough libraries to become a bad situation
heda is offline   Reply With Quote
Old 04-20-2019, 01:14 PM   #6
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by Klangfarben View Post
Huge +1 for this.

In a large template, the GUI lag is well, terrible. Save your project? Video stops playing entirely. Scroll down in your template? Sometimes it freezes for several seconds and then finally moves. The list goes on and on. Resizing tracks, refreshing windows, etc.

I know cpu efficiency has been a high priority for the developers. Do yourself a huge favor here and leverage the GPU for hardware acceleration. It is sorely needed and truly necessary for Reaper's growth moving forward.

Yes, CPUs keep getting faster. But the demands placed on the CPU keep getting higher and higher and usually keep pace or even outpace CPU advancement. I don't see any way Reaper is going to maintain a satisfactory GUI response with all that is being asked of the CPU without making use of hardware acceleration.

And for those of you thinking maybe I should update my computer, here are my specs.

Xeon E5-2697A v4 x2 (32 cores at 3.1 GHz)
256GB of DDR4 Memory (running in quad channel at 2800 MHz)
Nvidia P4000 Graphics Card
Samsung 960 Pro 2TB NVMe drive for OS
4x Intel P3500 2TB NVMe drives in RAID0 for Samples

That's nothing to sneeze at. And I'm REALLY struggling with the GUI at high track count and I'm guessing most Reaper users don't have these kind of specs. Yes, there is faster stuff available (at frightening cost) and I'm sure Threadripper 3 will be a beast but really, a machine like the above shouldn't have issues with major GUI lag. That it does really points to the need for hardware acceleration in Reaper.
Totally agree. We would all benefit. From powerful systems to smaller laptops. It doesn't really make sense to not look at utilizing the graphics card more.
srdmusic is offline   Reply With Quote
Old 04-20-2019, 01:16 PM   #7
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by heda View Post
I see many Track Inspector VIP users here
please tell me it is not Track Inspector causing this...
Because it should work the same independently of the number of tracks.
I guess this only affects soundtracks composers that use hundreds and hundreds of tracks. I also see notable performance hit when using many tracks. But I still don't have enough libraries to become a bad situation
Yes, scripts that use visuals would benefit if reaper utalized the GPU for processing the GUI, video etc.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 01:12 PM   #8
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Hey guys, this seems to be a bigger problem than just video midi editor and track selection lag.

Here's a link to a user that's experiencing massive lag when opening specific Kontakt libraries.

https://forum.cockos.com/showthread.php?t=209303

I too have the same problem opening some Kontakt instruments with lots of GUI bits going on. I also have problems with other plugins and instruments. When I switch tracks it halts the whole Reaper GUI until the plugin interface loads in the FX chain window.

We really need this sort of thing processed on the GPU which on my rig is only running at 1% of it's potential.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 01:44 PM   #9
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by srdmusic View Post
I heard that Reaper does not utilize graphics acceleration to render the user interface. Is this true?
Of course not.
Any Program's GUI Text is rendered by the GPU. The program would have a hard time to prevent that.

-Michael
mschnell is online now   Reply With Quote
Old 04-26-2019, 02:00 PM   #10
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by mschnell View Post
Of course not.
Any Program's GUI Text is rendered by the GPU. The program would have a hard time to prevent that.

-Michael
Hmmmm. I'm actually not sure this is true of Reaper. I believe they are forcing everything to be processed on the CPU so that Reaper can force the audio threads to be the highest priority. I don't have definitive proof other than there is an extreme amount of lag in Reaper's GUI, video and displaying plugin GUI's when compared to some other DAW's like Cubase. Reaper out preforms on the audio thread side and the CPU saturation is much higher on Reaper but the video suffered.

I believe there should be more controls given back to the user to allow the heavy video and GUI aspects of Reaper to be processed on the graphics card instead of the CPU as our graphics cards are not nearly being utilized.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 02:37 PM   #11
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,238
Default

REAPER works fine with plugins that use GPU for the graphics display. The GPU will be used to draw inside the plugin window. Maybe it is a Kontakt issue. I guess the best is to contact Cockos and Native instruments with specific examples and figure it out.
heda is offline   Reply With Quote
Old 04-26-2019, 02:42 PM   #12
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by heda View Post
REAPER works fine with plugins that use GPU for the graphics display. The GPU will be used to draw inside the plugin window. Maybe it is a Kontakt issue. I guess the best is to contact Cockos and Native instruments with specific examples and figure it out.
I believe you are correct with plugins that use 'Open GL'. However, there are several plugins that have problems within the DAW when Open GL is turned on. For example many user complain about Fab Filter plugins causing crashes with Open GL turned on. So much so that Fab Filter released a doc to help users disable Open GL in there plugins.

Reaper, should also allow, video, scripts, the Main GUI and the MIDI editor etc to have the option of running on the GPU instead of the CPU.

There used to be a check box in Reaper prefs to allow for faster GUI redraws. This has since been removed. Not sure what happened with that but I've experienced a lot of lag with Reaper across many aspects of the program.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 02:54 PM   #13
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,238
Default

Maybe there is a way to disable GPU for Kontakt? I have no idea.

of course it would be nice to have GPU... I would totally use GPU acceleration in the scripts if possible.

Maybe the problem is that it would make the entire system less stable. I hope we can experiment with it at least some day.

I think it would help if you can record a small video of the lag you are experiencing and contact Cockos for support. Big lag is not normal and should be fixed.
heda is offline   Reply With Quote
Old 04-26-2019, 03:13 PM   #14
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by heda View Post
Maybe there is a way to disable GPU for Kontakt? I have no idea.
Nope. Also Kontakt AFAIK doesn't use OpenGL, just regular software 2D rendering, not accelerated.
EvilDragon is offline   Reply With Quote
Old 04-26-2019, 03:27 PM   #15
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,238
Default

Quote:
Originally Posted by EvilDragon View Post
Nope. Also Kontakt AFAIK doesn't use OpenGL, just regular software 2D rendering, not accelerated.
If it doesn't use GPU, then the lag must be caused by something else. I would try to change the Run as... option for Kontakt in the FX browser and set it to separate process and see if it makes a difference in lag, and also change/limit the number of CPU threads Kontakt uses to leave some threads for REAPER graphics updates.
heda is offline   Reply With Quote
Old 04-26-2019, 11:55 PM   #16
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by srdmusic View Post
Hmmmm. I'm actually not sure this is true of Reaper.
AFAIK, Reaper uses the open source WDL Library for this. So you would be able to check it out.
-Michael
mschnell is online now   Reply With Quote
Old 04-27-2019, 12:01 AM   #17
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

WDL itself doesn't seem to do OpenGL or any sort of graphics accelleration.
EvilDragon is offline   Reply With Quote
Old 04-27-2019, 06:22 AM   #18
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by EvilDragon View Post
WDL itself doesn't seem to do OpenGL or any sort of graphics accelleration.
There's actually a folder named "gpu" in WDL but that has last been modified in 2015 and the files don't contain anything that would really be used by Reaper. It would seem implementing GPU acceleration for graphics is not a priority for Cockos. The minimal code they have in those files is also using OpenGL, which is a legacy technology which isn't really worth using anymore. Windows has a lacking implementation of it and on macOs it is being phased out entirely.

The custom graphics elements in Reaper are drawn with their Lice library which is entirely CPU based. Some elements are drawn by operating system API calls. (Which may or may not be GPU accelerated but even if they are, the benefit is probably negligible because of all the CPU based rendering Reaper is doing anyway.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 04-27-2019 at 06:27 AM.
Xenakios is offline   Reply With Quote
Old 04-27-2019, 08:06 AM   #19
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Thanks for the info guys. I think I understand why Reaper's dev team wants full control of CPU priority. I think it maybe one of the only ways Reaper can guarantee that the audio threads are always highest priority.

However, CPUs and GPUs have seen some huge inprovements since the start of Reaper, and it's my belief that the GPU is an untapped resource that should be available for users and scripters to access if they want. Almost every other aspect of Reaper is customizable for the knowledgeable user so the GPU should be no different.

If I'm wrong, I hope the devs can shed some light on why giving access to the GPU would be a bad idea.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 08:33 AM   #20
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

Apart from video playback and processing, I don't really see much benefit to using the GPU here. The actual graphics rendering work done by Reaper's UI can be done with a tiny fraction of CPU time on modern processors. I strongly suspect the lag we experience in large projects is related to internal processing (iterating over tracks, crunching through object states, etc.) and not the actual task of graphics rendering.
tack is offline   Reply With Quote
Old 04-27-2019, 08:34 AM   #21
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by srdmusic View Post

If I'm wrong, I hope the devs can shed some light on why giving access to the GPU would be a bad idea.
The problem is that they would need to rewrite all their graphics code to use the GPU. It isn't simply a switch to enable.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 04-27-2019, 08:42 AM   #22
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by tack View Post
The actual graphics rendering work done by Reaper's UI can be done with a tiny fraction of CPU time on modern processors.
It's also worth remembering that Reaper shares the GUI thread with 3rd party plugins. If there is even one plugin active that has difficulties updating its GUI fast enough, it will affect Reaper and other plugins too. (Plugins may also be doing other time consuming things in the GUI thread besides drawing graphics. They really shouldn't do that, but sometimes developers opt to do things that way because it is easier than using separate threads.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 04-27-2019, 08:55 AM   #23
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

Quote:
Originally Posted by Xenakios View Post
It's also worth remembering that Reaper shares the GUI thread with 3rd party plugins. If there is even one plugin active that has difficulties updating its GUI fast enough, it will affect Reaper and other plugins too.
Would bridging such plugins would avoid that situation? By definition they can't share the same thread -- although if Reaper blocks its UI thread waiting for bridged plugins to respond then it would have the same effect (although that'd be kinda lame and probably not too difficult to fix).
tack is offline   Reply With Quote
Old 04-27-2019, 10:55 AM   #24
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by tack View Post
Would bridging such plugins would avoid that situation? By definition they can't share the same thread -- although if Reaper blocks its UI thread waiting for bridged plugins to respond then it would have the same effect (although that'd be kinda lame and probably not too difficult to fix).
The load time on bridged plugins make is pretty unusable for anything other than a few problematic plugs that crash reaper otherwise.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 10:57 AM   #25
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by Xenakios View Post
It's also worth remembering that Reaper shares the GUI thread with 3rd party plugins. If there is even one plugin active that has difficulties updating its GUI fast enough, it will affect Reaper and other plugins too. (Plugins may also be doing other time consuming things in the GUI thread besides drawing graphics. They really shouldn't do that, but sometimes developers opt to do things that way because it is easier than using separate threads.)
This is exactly the problem I'm running into more and more, especially with Kontakt instruments that require a lot of visual overhead.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 11:03 AM   #26
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by srdmusic View Post
This is exactly the problem I'm running into more and more, especially with Kontakt instruments that require a lot of visual overhead.
Right, but there isn't really anything that can be done about it that would work reliably or would be easy to implement.(*) Or are you saying things work somehow differently in other hosts with Kontakt? If that is the case, then it could be a genuine bug with how Reaper handles 3rd party plugin GUIs. But if the GUI lags happen because of Kontakt itself, it should affect other hosts too and there is no obvious fix except to beg Native Instruments to fix it.

(*) Things like handling the host GUI in another thread or using GPU for the graphics rendering are not at all trivial to implement.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 04-27-2019, 11:56 AM   #27
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by tack View Post
Would bridging such plugins would avoid that situation? By definition they can't share the same thread -- although if Reaper blocks its UI thread waiting for bridged plugins to respond then it would have the same effect (although that'd be kinda lame and probably not too difficult to fix).
The load time on bridged plugins make is pretty unusable for anything other than a few problematic plugs that crash reaper otherwise.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 12:45 PM   #28
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Must say I never noticed any difference in loading times between bridged and non-bridged plugins.
EvilDragon is offline   Reply With Quote
Old 04-27-2019, 04:28 PM   #29
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by EvilDragon View Post
Must say I never noticed any difference in loading times between bridged and non-bridged plugins.
It's much more noticable in larger templates as there is a lag for each plugin load. Some plugins also take longer than others. If a user is only working with self made Kontakt instruments then I can see them not noticing a huge difference.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 10:34 PM   #30
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by srdmusic View Post
there is a lag for each plugin load
... when they are in a row ? (When they are in parallel this does not seem likely.)

Is that latency denoted in the PDC (and hence compensated if possible) ?

Regarding multiple bridged Plugins in a row, it might be possible to bridge them as a block, which would at least save CPU resources. (No idea if that does happen.)

("Block bridging" might show up a way for future kind of such "bridging" task discussed elsewhere, such as creating an oversampling environment for a bunch of plugins or a "Wine" bridge for Windows plugins in a Linux installation of Reaper.)

-Michael

Last edited by mschnell; 04-27-2019 at 10:47 PM.
mschnell is online now   Reply With Quote
Old 09-01-2019, 09:42 AM   #31
zigzag312
Human being with feelings
 
Join Date: Sep 2017
Posts: 36
Default

+1 from me
zigzag312 is offline   Reply With Quote
Old 09-01-2019, 11:18 PM   #32
weblordpepe
Human being with feelings
 
Join Date: Jul 2016
Posts: 33
Default

No to GPU rendering. For good reason. It is a pig and is not the solution ya think it is.

It isn't straight forward to utilize GPU rendering and you're only going to get advantages in things like bitmap scaling or anti-aliasing, which I believe is already done by the OS at the lower levels anyway.

You lose a lot of flexibility and deterministic control of your drawing. It is after-all multi-processor rendering. The drawing APIs in Windows are a jungle now anyway.

Your problem is bloaty slow plugins, not reaper.

If you got big bloaty plugins, then fix the big bloaty plugins. The CPU need not to be slow at drawing sophisticated things. If your plugin is doing something like full-frame 1920x1080 box of pastel color shades & shadows then you can use the GPU anyway.

You can't try & mitigate around the failings of poor software plugins because that will be a job that never ends, as plugin vendors get shittier & shittier at performance. And believe me - they will if you let them.
weblordpepe is offline   Reply With Quote
Old 09-02-2019, 01:18 AM   #33
zigzag312
Human being with feelings
 
Join Date: Sep 2017
Posts: 36
Default

Quote:
Originally Posted by weblordpepe View Post
No to GPU rendering. For good reason. It is a pig and is not the solution ya think it is.

It isn't straight forward to utilize GPU rendering and you're only going to get advantages in things like bitmap scaling or anti-aliasing, which I believe is already done by the OS at the lower levels anyway.

You lose a lot of flexibility and deterministic control of your drawing. It is after-all multi-processor rendering. The drawing APIs in Windows are a jungle now anyway.

Your problem is bloaty slow plugins, not reaper.

If you got big bloaty plugins, then fix the big bloaty plugins. The CPU need not to be slow at drawing sophisticated things. If your plugin is doing something like full-frame 1920x1080 box of pastel color shades & shadows then you can use the GPU anyway.

You can't try & mitigate around the failings of poor software plugins because that will be a job that never ends, as plugin vendors get shittier & shittier at performance. And believe me - they will if you let them.
Some big assumptions you make there.

Just filtering tracks in the "Track Manager" results in Reaper GUI becoming more responsive. Same project, with the same plugins. It would probably be even worse, if I were running Reaper in 4K.

Yes, plugins are hogging the CPU. That is exactly why there isn't enough CPU power left for Reaper's GUI to render smoothly.

GPU acceleration certainly won't solve everything. It can be even slower than CPU in specific cases, but a good architecture with proper caching will outperform CPU UI rendering by a large margin (especially on 4k and high refresh rate). Older API's in Windows, even though they gained some GPU acceleration, still do it mush less efficiently than the new API's, because backwards compatibility prevents them to rewrite the underlying architecture to be GPU friendly. Yes, GUI programming is a mess. Multi-platform GUI programming is even a bigger mess. Add high dpi support and the real fun begins
zigzag312 is offline   Reply With Quote
Old 11-16-2019, 01:45 AM   #34
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 425
Default

Does anyone actually know if REAPER will ever use GPU rendering? Did developers ever comment on this? It is borderline unusable for me in its current state. At first i thought the GUI issues i am having were only limited to big projects. But even opening the midi editor during playback in small projects or scrolling the arrange view makes the CPU usage jump 15-20%, and slightly bigger projects it crackles or lags. (I have went through every setting that affects threading and performance, it does not change anything, although they do help in some cases)
BirdBird is offline   Reply With Quote
Old 11-16-2019, 02:16 AM   #35
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

I doubt there is a way to make the current GUI much faster by offloading some work on the GPU. The devs could decide to rework the GUI completely by making it (and it's components) smoothly zoomable, and this wouid only require using the GPU for blitting (zoom/pan/place) the widgets. But I suppose the devs do have enough workload to do audio and functionality improvements.

-Michael
mschnell is online now   Reply With Quote
Old 11-16-2019, 02:31 AM   #36
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 425
Default

A setting to keep the GUI thread on a specific CPU core and FX processing out of that core would at least remedy the problem without having to rebuild the entire program from the ground up with hardware acceleration i think. But maybe i am oversimplyifing it and that is not how threading works *shrugs*
BirdBird is offline   Reply With Quote
Old 11-16-2019, 09:23 AM   #37
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by BirdBird View Post
A setting to keep the GUI thread on a specific CPU core and FX processing out of that core would at least remedy the problem without having to rebuild the entire program from the ground up with hardware acceleration i think. But maybe i am oversimplyifing it and that is not how threading works *shrugs*
It's not a bad thought in terms of a temporary fix that doesn't get ugly. One of the big issues is that GUI refresh can get interrupted by anything. Save or render? Video no longer plays. Scroll in the mixer, meters don't refresh. Obviously project size is a factor here, but if GUI could be assigned to a dedicated core(s) that couldn't be interrupted by other tasks that would be a big help for the time being.
Klangfarben is offline   Reply With Quote
Old 11-16-2019, 03:13 PM   #38
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

While we talk about Reaper having GPU acceleration, which i think it could be good at a later point, there are far more important thing that can be fixed without breaking a full list of code that could destroy the all core of Reaper. Stability and performance for audio.
While other companies make eye candy stuff for their users , destroying the audio engine performance, they come out with paid updates to "solve" those performances saying they have some ASIO blablabla technology that makes it faster and etc..Reaper is not about that folks...
pepe44 is offline   Reply With Quote
Old 11-16-2019, 04:12 PM   #39
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Why does everyone always make the argument that x feature request will completely break the Reaper code? Justin and Schwa aren't idiots. How about we give them a little more credit and not assume what they can or can't do. Also, in terms of the last suggestion, assigning a dedicated core or cores to the GUI, how would that "destroy the core of Reaper"?

This isn't about "eye candy". It's about Reaper not getting completely bogged down when executing normal behavior. Users need to see meters when they scroll. Users need to see video when they render. What good is only concentrating on the audio portion of Reaper if you can't actually see what it is doing? Or if the GUI hits the CPU so much the audio does get affected?
Klangfarben is offline   Reply With Quote
Old 11-16-2019, 05:01 PM   #40
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

There are people here with way more knowledge than me to explain why would be hard to change the all graphics in Reaper. But from my understanding they would have to rebuild the all graphical engine from scratch to make it work properly.
pepe44 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:18 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.