|
|
|
07-19-2023, 01:04 PM
|
#161
|
Human being with feelings
Join Date: Mar 2021
Posts: 44
|
Quote:
Originally Posted by Phazma
I have used several DAWs which do scroll/zoom smoothly and in none of them I have felt the GUI become noticably more sluggish than Reaper’s under load. But yes, of course this should be an optional preference. Maybe it can also come with an option for it to automatically turn off when the CPU is under such load that the GUI would become sluggish.
|
Great idea about CPU dependent behavior !
|
|
|
07-19-2023, 01:23 PM
|
#162
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,116
|
Gonna ask that age-old question, "how do the other DAWs handle this"?
|
|
|
07-19-2023, 11:25 PM
|
#163
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,687
|
It's a good thing that different DAW providers focus on different aspects of the product - as well CPU efficiency wise as developers' effort wise. Hence the users have a choice.
Last edited by mschnell; 07-20-2023 at 03:04 PM.
|
|
|
07-20-2023, 05:03 AM
|
#164
|
Human being with feelings
Join Date: May 2019
Location: Berlin
Posts: 2,164
|
Quote:
Originally Posted by ferropop
Gonna ask that age-old question, "how do the other DAWs handle this"?
|
I think most them (if not all) make use of the GPU for graphics rendering.
This post about sums it up:
Quote:
Originally Posted by Xenakios
If GUI smoothness is your main pain point about Reaper, it might be a good idea to start looking at other DAW softwares. I don't see the Reaper developers fixing those issues anytime soon. It would be a massive undertaking for example to use GPU acceleration. Almost all of their graphics code is currently based on raster graphics rendered on the CPU, so almost all the graphics code would have to be rewritten. To make the GPU acceleration really worth it, they'd need to implement it separately for all platforms they support, using the best technology options available. (OpenGL is basically obsolete at this point, it isn't worth it trying to use that anymore.)
There may be some low hanging fruits with algorithmic complexity that can be fixed, but fixing those will probably never be enough to fix all the GUI lag issues. Ultimately it comes down to how many pixels on the screen have to updated. For example with 4K or better screens, that is just a lot of pixels to deal with and if the graphics is rendered on the CPU in the GUI thread, response to mouse and keyboard input will inevitably suffer.
Using existing code libraries wouldn't immediately help, those would need to be adapted to work with Reaper's existing code.
|
|
|
|
07-20-2023, 05:43 AM
|
#165
|
Human being with feelings
Join Date: Dec 2017
Posts: 302
|
Quote:
Originally Posted by FeedTheCat
I think most them (if not all) make use of the GPU for graphics rendering.
This post about sums it up:
|
But it worked with metal on macOS, didn't it? Isn't that GPU acceleration on the mac? Or am I confused?
|
|
|
07-20-2023, 06:25 AM
|
#166
|
Human being with feelings
Join Date: May 2019
Location: Berlin
Posts: 2,164
|
Quote:
Originally Posted by nappies
But it worked with metal on macOS, didn't it? Isn't that GPU acceleration on the mac? Or am I confused?
|
Hmm apparently so. My assumption would be that they've made certain MacOS-specific improvements utilizing metal. Most of the computing is probably still done by the CPU. Not sure though. At least on Linux REAPER doesn't seem to use GPU at all.
|
|
|
07-20-2023, 06:55 AM
|
#167
|
Human being with feelings
Join Date: Sep 2021
Location: Berlin
Posts: 1,935
|
Quote:
Originally Posted by FeedTheCat
Hmm apparently so. My assumption would be that they've made certain MacOS-specific improvements utilizing metal. Most of the computing is probably still done by the CPU. Not sure though. At least on Linux REAPER doesn't seem to use GPU at all.
|
I'm pretty sure that all macOS drawing APIs since the deprecation of Quickdraw (Classic Mac OS 9/Carbon) support hardware-accelerated backends to some extent. GDI on Windows claims to, as well, but it's definitely not as effective, or requires specific hardware combinations.
|
|
|
07-20-2023, 03:11 PM
|
#168
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,687
|
Quote:
Originally Posted by FeedTheCat
At least on Linux REAPER doesn't seem to use GPU at all.
|
Define, what you mean by "use GPU" !
AFAIK:
The CPU can't access the display directly at all. This always is done by the GPU.
If the CPU just provides single pixels, this process is a huge obstacle vs. having the CPU access the display refresh memory directly (as in the very old days), No software does this for a large amount of the screen. E.g. text rendering always is done by the GPU.
|
|
|
07-21-2023, 12:24 AM
|
#169
|
Human being with feelings
Join Date: May 2019
Location: Berlin
Posts: 2,164
|
Quote:
Originally Posted by mschnell
Define, what you mean by "use GPU" !
|
Afaict it doesn't make use of the GPU to accelerate its own graphics calculations. I can see a list of applications that occupy GPU memory, and REAPER isn't one of them (unless I open a ReaImgui window).
|
|
|
07-21-2023, 04:48 AM
|
#170
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,116
|
Quote:
Originally Posted by FeedTheCat
Afaict it doesn't make use of the GPU to accelerate its own graphics calculations. I can see a list of applications that occupy GPU memory, and REAPER isn't one of them (unless I open a ReaImgui window).
|
This is confirmed in one of the interviews Justin did last year, he mentions that it's "on the list" of things to do, but by no means has any priority.
|
|
|
07-21-2023, 08:27 AM
|
#171
|
Human being with feelings
Join Date: Dec 2017
Posts: 302
|
Quote:
Originally Posted by ferropop
This is confirmed in one of the interviews Justin did last year, he mentions that it's "on the list" of things to do, but by no means has any priority.
|
It's encouraging, however.
|
|
|
07-21-2023, 09:48 AM
|
#172
|
Human being with feelings
Join Date: Jun 2019
Posts: 2,872
|
Quote:
Originally Posted by nappies
It's encouraging, however.
|
Exactly. If that’s what it takes to implement this FR (and other FRs related to smooth graphics) then let’s hope they decide to take it on some time soon.
|
|
|
07-29-2023, 01:13 PM
|
#173
|
Human being with feelings
Join Date: Jul 2023
Posts: 4
|
Quote:
Originally Posted by Phazma
Please add support for scrolling and zooming pixel-by-pixel without steps.
It helps following visual changes on screen and considerably reduces eye strain.
Here a video demonstration that shows what I mean by comparison of Reaper with several other software.
The lack of support is a pretty big issue specially on Mac, as the majority of people probably are using the first party peripherals like the Apple Magic Mouse or Trackpad which support this on seemingly every app that I have used except for Reaper.
Here an older thread I made in the Mac subforum, which discusses the scrolling/zooming issue in more detail.
|
+
|
|
|
07-30-2023, 04:34 AM
|
#174
|
Human being with feelings
Join Date: Sep 2017
Posts: 30
|
Quote:
Originally Posted by Phazma
Please add support for scrolling and zooming pixel-by-pixel without steps.
It helps following visual changes on screen and considerably reduces eye strain.
Here a video demonstration that shows what I mean by comparison of Reaper with several other software.
The lack of support is a pretty big issue specially on Mac, as the majority of people probably are using the first party peripherals like the Apple Magic Mouse or Trackpad which support this on seemingly every app that I have used except for Reaper.
Here an older thread I made in the Mac subforum, which discusses the scrolling/zooming issue in more detail.
|
We continue to wait and hope. +++
|
|
|
10-07-2023, 08:34 AM
|
#175
|
Human being with feelings
Join Date: Apr 2021
Posts: 32
|
+1
Not sure where things are with this (mostly cos I don't understand a lot of the technical chat) but I would absolutely love smooth Continuous Scrolling when recording as I record a lot to music notation and/or with the MIDI Editor open to follow etc. The way it currently scrolls really gives me a headache when trying to record. I'm a PC user and less bothered about how smooth the scrolling is for editing or whatever.
But yeah, just wanted to give my +1 support for Smooth Continuous Scrolling when recording.
|
|
|
10-07-2023, 10:32 AM
|
#176
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,687
|
Quote:
Originally Posted by FeedTheCat
I can see a list of applications that occupy GPU memory, and REAPER isn't one of them (unless I open a ReaImgui window).
|
I in fact some years ago did write software that allows for "Zoom and Pan" a pixel array. I did this using GPL. So I do understand that it would be possible to write the track view of a large amount of the "from start to end tracks picture" in the not visible GPU memory and scroll it perfectly smoothly. The downside is that you need to create those pixels long before they will be visible and hence use up a lot of CPU performance for stuff that might never be viewed.
|
|
|
10-07-2023, 11:03 AM
|
#177
|
Human being with feelings
Join Date: Jul 2010
Location: Slovakia
Posts: 2,588
|
But the smooth scrolling means it takes some time to scroll to the desired position. It is not instantenious. So that time could be used to fill the buffer. And in this case, only a smaller non-visible area would need to be predrawn in each moment.
Or no? :-)
|
|
|
10-17-2023, 01:09 PM
|
#178
|
Human being with feelings
Join Date: Aug 2020
Posts: 32
|
Yeah
Quote:
Originally Posted by Phazma
Exactly. If that’s what it takes to implement this FR (and other FRs related to smooth graphics) then let’s hope they decide to take it on some time soon.
|
For sure, my friend. Repeat together:
"just an optional toggle in CTRL+P"
Something cool would be if they add also, beside the toggle in the preferences, a simple algorithm that detects when CPU is on load and disable all animations consequently
In the meanwhile, ++1
|
|
|
10-29-2023, 10:21 PM
|
#179
|
Human being with feelings
Join Date: Sep 2023
Posts: 33
|
+!
Tracks area scrolls smoothly while dragging the scroll bars. Why should it be any different while a mouse wheel to do the same thing? It is even hard to understand if the page scrolled backward or forward without reading the bar number at the top. Seriously who cares about efficiency in this case?
|
|
|
10-31-2023, 05:07 PM
|
#180
|
Human being with feelings
Join Date: Sep 2023
Posts: 33
|
Found a temp fix on reddit
https://www.reddit.com/r/Reaper/comm...oth_scrolling/
Created 4 custom actions using the actions referenced in the post. Also see attached images. Linked these to the Mouse wheel actions instead of the default.
This may not be the most efficient but it works for me especially for scrolling while zoomed in.
|
|
|
11-01-2023, 01:45 AM
|
#181
|
Human being with feelings
Join Date: Jul 2010
Location: Slovakia
Posts: 2,588
|
Quote:
Originally Posted by onox
https://www.reddit.com/r/Reaper/comm...oth_scrolling/
Created 4 custom actions using the actions referenced in the post. Also see attached images. Linked these to the Mouse wheel actions instead of the default.
This may not be the most efficient but it works for me especially for scrolling while zoomed in.
|
Looks smart. But isn't there a buffer that needs to be fully executed? Meaning, if you perform this custom action fast in a row several times, does it take its time to exeute all of them?
|
|
|
11-01-2023, 02:16 AM
|
#182
|
Human being with feelings
Join Date: Jul 2010
Location: Slovakia
Posts: 2,588
|
Quote:
Originally Posted by onox
https://www.reddit.com/r/Reaper/comm...oth_scrolling/
Created 4 custom actions using the actions referenced in the post. Also see attached images. Linked these to the Mouse wheel actions instead of the default.
This may not be the most efficient but it works for me especially for scrolling while zoomed in.
|
This actually works well! If you send the scroll to one direction and while the view is scrolling, you scroll to the opposite one, the first animation is stopped (with a bit of lag, but ok usable) and the view scrolls to another direction. That's what we want. With a normal script, this cannot be achieved, the original animation always need to be executed as a whole. With an asynchroniously running script like I made (abandonware by now), this can be achieved, but there is a performace limit baked into the defer() function so it's not so useful.
But this style works fine!
I've tried to do a bit of an accelerating/deccelerating animation, don't know if it makes any real difference though. But nevertheless, I've binded this to my main scrolling key already.
EDIT: Ok, there is a performance degradation with many items as well. So maybe less complexity would be better.
Last edited by bFooz; 11-01-2023 at 02:24 AM.
|
|
|
11-01-2023, 01:31 PM
|
#183
|
Human being with feelings
Join Date: Sep 2023
Posts: 33
|
@bFooz
I didn't try anything fancy with it. The last comment on that thread is all i went with.
"You can just stick a bunch of "Add: Action: Modify MIDI CC/mousewheel: 0.5x" modifier actions before the zoom or scroll action... The more modifiers the more, finer increments there are ... booyah"
I also read somewhere about a limit of somewhere around 5 on the number of repeated actions and I did find some kind of glitch with too many.
And yes, i guess these actions are queued and executed on an asynchronous thread per every flick of the mouse-wheel. But I am sure the edge cases were already thought about and handled by the developers.
Maybe you guys can write a "simple" script using these actions instead and make it available on reapack? With toggles and sliders to control animations, speed etc?
|
|
|
11-01-2023, 03:31 PM
|
#184
|
Human being with feelings
Join Date: Jun 2019
Posts: 2,872
|
I think I have already mentioned the x0.5 action workaround some pages back. And yes it is smoother but the problem is that the scroll distance also shrinks with each modifier action. This factor is static but it needs to be dynamic so that fast physical scroll movements do large scrolls (x1.0 would be ok) and slow physical scroll movements do fine/smooth scrolls (x0.25 scroll speed for example like with 2 modifiers).
|
|
|
11-02-2023, 10:17 AM
|
#185
|
Human being with feelings
Join Date: Sep 2023
Posts: 33
|
Quote:
Originally Posted by Phazma
I think I have already mentioned the x0.5 action workaround some pages back. And yes it is smoother but the problem is that the scroll distance also shrinks with each modifier action. This factor is static but it needs to be dynamic so that fast physical scroll movements do large scrolls (x1.0 would be ok) and slow physical scroll movements do fine/smooth scrolls (x0.25 scroll speed for example like with 2 modifiers).
|
I have to admit I am relatively new here. What you said makes sense. And thanks to everyone for tackling this issue early on.
|
|
|
01-19-2024, 04:05 PM
|
#186
|
Human being with feelings
Join Date: Mar 2020
Posts: 52
|
I am also looking for a way to fine-tune zoom (mainly horizontally). Often difficult to work with and frustrating as is. You'd think there'd be at least a preference to adjust how big or small the increments are, but I can't find one.
|
|
|
01-24-2024, 09:33 AM
|
#187
|
Human being with feelings
Join Date: May 2022
Posts: 198
|
+1
|
|
|
01-29-2024, 07:45 AM
|
#188
|
Human being with feelings
Join Date: Sep 2015
Location: Paris
Posts: 544
|
+1
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 01:22 PM.
|