LICE extreme lag on Windows

[ferropop]

Breaking out from sockmonkey72's MIDI Razor Edits thread

Originally Posted by sockmonkey72

MIDI Razor Edits
WINDOWS USERS: there are "special considerations" with how REAPER draws on Windows via the JS_ReascriptAPI. The script flickers on Windows and is not nearly as performant as on macOS or Linux, and for that I do apologize, although it's not my fault per se. I recommend contacting support@cockos.com if you want a less flickery, generally more performant experience drawing with LICE on the Windows platform.

Just a quick aside to emphasize what sockmonkey72 is saying here.


https://www.youtube.com/watch?v=S1_KqMdfWHw

This is a 60FPS 4k capture, on Windows, Intel i9-10900k, RTX3060, 64gigs ram.

The same project on MacOS, same zooms/scrolls, on a less performant system, is 100% buttery smooth 120FPS.

The drawing API being used on Windows feels drastically worse than on MacOS/Linux, to the point that this above project is almost not possible to navigate. Keystrokes are processed with huge latency, everything is bogged down, it's nearing unusable.

I would urge anyone else experiencing this on Windows (along with the flickering in sockmonkey72's incredible Razor Edit script!!!) to email support@cockos.com and stress how bad this can get on Windows.

[ferropop]

Quoting relevant follow up:

Originally Posted by sockmonkey72

I don't have any particular insight into the way REAPER is drawing on Windows beyond what I can read in the WDL/SWELL/LICE source code, but I think the outcomes speak for themselves.

If LICE_GDI is in fact using GDI as its backend, which seems to be the case, that probably explains at least a large part of the difference between it and macOS/Linux 2D drawing backends, which use backbuffering to manage updates to screen, handled automatically by the OS. The macOS/Linux backends also provide some amount of automatic GPU support.

I don't want to talk out of turn, and I am sure that the devs know all of this. Using GDI ensures that pre-Win7 users can also run REAPER. And it works, and it's done and well-tested. So it's not all downsides.

[ferropop]

Just want to mention that yes this is a busy production project, but the same project on macOS runs at lightspeed.

Often I'll drag in 30-50 tracks for a mixing session, zero plugins, and zooming/scrolling is almost identical to the video above.

I'll add that Melodyne follows suit -- perfect 120FPS on macOS no matter the busyness of the project. On Windows, the window needs to be 1/4 the size of the screen for it to even approach 60FPS. Not to muddy the waters, but clearly there's some relationship here as it's the exact same result.

Thank you so much if there's interest by the devs at getting this looked at! It's something people have even noticed and commented on in sessions, despite the beefy setup. And apologies if I'm using incorrect terminlogy etc I'm just commenting on this very frustrating reality. <3

[schwa]

AFAICT the quoted post in the OP is talking about display performance by extensions that are using the REAPER API, not display performance in general, right?

[Sexan]

That flicker was always there (the same thing was (still is) happening in Area51 Selection (aka native razor edits) or any script does drawing with JS_API and reaper is updating its UI (via playback,resize windows,moving arrange timeline etc.).

The problem is when reaper needs to update its UI it causes visible flicker on that drawing extension.
This does not happen in linux, maybe it is but in very very small degree its almost unnoticeable (not sure about what happens internally).
Not sure whats the situation on Mac.

[ferropop]

Originally Posted by schwa

AFAICT the quoted post in the OP is talking about display performance by extensions that are using the REAPER API, not display performance in general, right?

I hesitated to link the Script discussion because it's just an example of the more general lag issues plaguing Reaper in Windows.

My video is running no script, it's just a project and me navigating through it.

And yeah like I mentioned above, this happens even in a completely fresh session, no plugins but just lots of audio files dragged in. You can visibly see the redraw, everything slows to a crawl, notable input lag.

Resizing the Reaper window down results in an increase in FPS/responsiveness. Even pulling up a docked Mixer results in the Arrange View area suddenly being higher FPS/responsive.

Thank you! Just throwing out observations.

[schwa]

There is no script running in the background? I suspect there is something particular to this project in this setup that is causing slow display performance.

The first thing I would try is uninstalling extensions completely to see if that makes a difference. You could do this by moving the contents of AppData\Roaming\REAPER\UserPlugins\ to another directory temporarily, and restarting REAPER.

[ferropop]

Originally Posted by schwa

There is no script running in the background? I suspect there is something particular to this project in this setup that is causing slow display performance.

The first thing I would try is uninstalling extensions completely to see if that makes a difference. You could do this by moving the contents of AppData\Roaming\REAPER\UserPlugins\ to another directory temporarily, and restarting REAPER.

Thanks Schwa, here's what I've done so far:


https://youtu.be/ZwA5UZ2XCyI

1. Rendered all folders to WAV, and muted those folders -- so no plugins are running
2. Closed all running scripts, to ensure nothing is running
3. Zoom/scroll through the project

With all the plugins disabled I do get better performance, but it's still sluggish and latent to keypresses, and you can see the peaks redrawing at a low FPS.

Same project as the original video.

[mozart999uk]

Originally Posted by ferropop

Thanks Schwa, here's what I've done so far:


https://youtu.be/ZwA5UZ2XCyI

1. Rendered all folders to WAV, and muted those folders -- so no plugins are running
2. Closed all running scripts, to ensure nothing is running
3. Zoom/scroll through the project

With all the plugins disabled I do get better performance, but it's still sluggish and latent to keypresses, and you can see the peaks redrawing at a low FPS.

Same project as the original video.

Is it possible to send me that project so that I can try?

EDIT: Can you post a video of the same project in Mac to show the difference?

[sockmonkey72]

Originally Posted by ferropop

Thanks Schwa, here's what I've done so far:

1. Rendered all folders to WAV, and muted those folders -- so no plugins are running
2. Closed all running scripts, to ensure nothing is running
3. Zoom/scroll through the project

With all the plugins disabled I do get better performance, but it's still sluggish and latent to keypresses, and you can see the peaks redrawing at a low FPS.

Same project as the original video.

You also need to empty out the UserPlugins folder (or move it somewhere else), as schwa suggested -- there may be extensions loaded and running without any obvious indication of that.

[7thresonance]

Also have similar FPS issues using Adaptive Grid, and roboface Scripts.

[LetsGoBrandon]

I'm not 100% sure, but what it looks like is happening has to do with how windows, mac, and linux differ in their bitmap computation. Reaper uses their WDL library, which itself contains 3 important library systems that reaper uses extensively: lice, swell, and wingui (virtwnd). Much of the MCP, TCP, and other reaper windows use the wingui virtwnd system, which is a completely custom window rendering system (NOT related to Windows OS) that handles mouse and keyboard input, and those elements use LICE bitmaps. Basically, in the mixer and track control panels, they are rendering virtwnd derived objects with their own onPaint method overrides. In turn, those overrides are calling LICE bitmap functions which draw with the potential for openGL acceleration. On Windows OS, these LICE bitmaps are blit and pushed to the screen using BitBlt and EndPaint/ReleaseDC, and from what I can tell windows built reaper bypasses the openGL acceleration. Thus, on Windows OS, reaper objects are getting drawn using a lot of CPU, and finally getting blit with BitBlt at the end of a paint (https://learn.microsoft.com/en-us/wi...-wingdi-bitblt). SWELL is an fast performing emulation layer for many Win32 functions, including BitBlt. On Linux, SWELL uses Cairo; Cairo functions are used to blit and push to the screen by utilizing SWELL. On mac, it appears to use Metal in SWELL. None of those by default utilize the OpenGL extended acceleration either.

So it appears that the diverging behavior of utilizing Cairo and Metal greatly improves the performance of Reaper, and the Linux and Apple compilations of Reaper. Or alternatively, there is something involved with using SWELL and LICE that leads to better performance, perhaps even a bug in the windows build.

Oddly enough, win32 GDI is supposed to perform better than Cairo. So I believe it is the alternative. Just recently, I discovered a bug on my build (again, Windows) where pushing UI updates after calling api functions that set the mixer volume completely lags out the repainting of the main window if a tracks height (in the track panel) is fully expanded, even though the mixer is in a separate window. Meanwhile, the mixer is totally fine, and is painting normally. Suspiciously the function that pushes the UI updates takes longer than normal to complete, but is not freezing the execution of the actual main thread. So there is some real graphical wonkiness in reaper, at least on Windows.

[7thresonance]

Originally Posted by LetsGoBrandon

I'm not 100% sure, but what it looks like is happening has to do with how windows, mac, and linux differ in their bitmap computation. Reaper uses their WDL library, which itself contains 3 important library systems that reaper uses extensively: lice, swell, and wingui (virtwnd). Much of the MCP, TCP, and other reaper windows use the wingui virtwnd system, which is a completely custom window rendering system (NOT related to Windows OS) that handles mouse and keyboard input, and those elements use LICE bitmaps. Basically, in the mixer and track control panels, they are rendering virtwnd derived objects with their own onPaint method overrides. In turn, those overrides are calling LICE bitmap functions which draw with the potential for openGL acceleration. On Windows OS, these LICE bitmaps are blit and pushed to the screen using BitBlt and EndPaint/ReleaseDC, and from what I can tell windows built reaper bypasses the openGL acceleration. Thus, on Windows OS, reaper objects are getting drawn using a lot of CPU, and finally getting blit with BitBlt at the end of a paint (https://learn.microsoft.com/en-us/wi...-wingdi-bitblt). SWELL is an fast performing emulation layer for many Win32 functions, including BitBlt. On Linux, SWELL uses Cairo; Cairo functions are used to blit and push to the screen by utilizing SWELL. On mac, it appears to use Metal in SWELL. None of those by default utilize the OpenGL extended acceleration either.

So it appears that the diverging behavior of utilizing Cairo and Metal greatly improves the performance of Reaper, and the Linux and Apple compilations of Reaper. Or alternatively, there is something involved with using SWELL and LICE that leads to better performance, perhaps even a bug in the windows build.

Oddly enough, win32 GDI is supposed to perform better than Cairo. So I believe it is the alternative. Just recently, I discovered a bug on my build (again, Windows) where pushing UI updates after calling api functions that set the mixer volume completely lags out the repainting of the main window if a tracks height (in the track panel) is fully expanded, even though the mixer is in a separate window. Meanwhile, the mixer is totally fine, and is painting normally. Suspiciously the function that pushes the UI updates takes longer than normal to complete, but is not freezing the execution of the actual main thread. So there is some real graphical wonkiness in reaper, at least on Windows.

Damn. thats insane.

What I dont understand is, why do adding extensions or other elements on screen reduce FPS when there is only one track in the project? sure its a Kontakt instance, but its barely doing anything.

Perhaps one day we get a rewrite of the GUI and maybe GPU acceleration.

[ferropop]

I can't claim to understand much of the above but am super glad someone does -- and I wonder if it's somehow mixed in with CPU scheduling/priority dependent on Anticipative FX and all the tweakables in the Buffering preference pane. I can play with these settings on the above session and see if anything changes.

[schwa]

Originally Posted by schwa

The first thing I would try is uninstalling extensions completely to see if that makes a difference. You could do this by moving the contents of AppData\Roaming\REAPER\UserPlugins\ to another directory temporarily, and restarting REAPER.

Did you try this?

Sharing the project and media would be a lot more productive than trying to figure out how REAPER works under the hood, fwiw.

[ferropop]

Originally Posted by schwa

Did you try this?

Sharing the project and media would be a lot more productive than trying to figure out how REAPER works under the hood, fwiw.

Thanks schwa, just working on something t.s. and can't risk messing with my install until the weekend.

I will say though, I did a portable install, opened the same project offline so no plugins running at all, and while it was a bit zippier (which I'd expect) you can still see the redrawing of peaks when zooming, just smoother than my extreme case above.

It's not just this project though, it's usually when importing a reasonable number of stems (maybe 50+?), again with zero plugins, it's just laggy while things get drawn to screen in relative slowmo vs macOS.

The best way I can put it is, it's like the difference between (not) using PreventUIRefresh in a script.

Will try removing the userplugins folder asap! Thank you for spending time looking at this.

[LetsGoBrandon]

Originally Posted by 7thresonance

Damn. thats insane.

What I dont understand is, why do adding extensions or other elements on screen reduce FPS when there is only one track in the project? sure its a Kontakt instance, but its barely doing anything.

Perhaps one day we get a rewrite of the GUI and maybe GPU acceleration.

IMO, Reaper does not need a rewrite of the GUI. At a basic level, its doing what pretty much all 2d renders do. I could be wrong on this, but I do not think it should be too difficult to get OpenGL acceleration working for all the virtwnd content. It might be an intermediate task though, and if its stable and performing enough already, why waste time on making that happen? I think there is more to the story on this as a bug, because Linux and Apple builds are performing much better as you and others have stated.

I think other extension developers need to start experimenting with multi-threaded or multi-process transparent window overlays. They can still use SWELL to provide cross-platform support, but it isn't required and you could use OpenGL in your own overlay window (it would just be more difficult). The idea is maybe (for example in Window OS) that the DWM will handle blending faster and better than drawing and blending directly in the REAPER client window. It would also be more flexible, so if the target applications window changed its rendering scheme and as long as it was a window using the DWM (which is the default for windowed applications), the extension will still appear to draw over the window below it.

So lets see if bug fix can be found, while we extension developers find better ways to draw.

[ferropop]

Fresh portable install of Reaper (latest pre). No scripts, no changes.

Alright I dragged audio files into this session, literally no plugins or anything else. Spectral peaks are however enabled.



While this isn't awful, it's unquestionably laggy and not smooth. I'll remind that there are zero plugins -- the moment plugins starts taxing the CPU this gets progressively worse.

Resizing the Reaper window to 1/4 results in what feels like 4x the smoothness/responsiveness.

I can open and screen-record this same project on macOS when I get home, but it will inevitably be buttery-smooth as always.

[schwa]

I appreciate that you have an issue you are trying to improve, but please understand that posting a video of how something behaves on your computer is not useful for anyone else's understanding. If you are able to share a project, including media, with no fx, and your reaper.ini file, so that others can reproduce your exact setup, that would be useful.

[ferropop]

Originally Posted by schwa

I appreciate that you have an issue you are trying to improve, but please understand that posting a video of how something behaves on your computer is not useful for anyone else's understanding. If you are able to share a project, including media, with no fx, and your reaper.ini file, so that others can reproduce your exact setup, that would be useful.

Of course schwa, I just wanted to get this to the point of exhibiting the behaviour on a portable install - just to take out every single variable and not have it be something specific to my system. Just posting the results here, I'm in the process of blanking out the audio files because I can't share the project as-is currently.

[mozart999uk]

Very happy to test, when you are at that point Ferro :-)

[ferropop]

Finally created a sluggish project even on Stock portable install, and NO plugins. Just wave files. Been searching a long time for the perfect thing to send, so hopefully this is it.

Devs I'm sorry it's a few gigs in size, I've really tried to pare down to as small as possible but this perfectly communicates the issue, so I hope you can look past the size if it's helpful in fixing this.

Sent to support@c

Windows 10 (and 11)
64GB RAM
RTX3060
running at 3840x2160 60Hz over HDMI

Thank you!

[mozart999uk]

Originally Posted by ferropop

Finally created a sluggish project even on Stock portable install, and NO plugins. Just wave files. Been searching a long time for the perfect thing to be send, so hopefully this is it.

Devs I'm sorry it's a few gigs in size, I've really tried to pare down to as small as possible but this perfectly communicates the issue, so I hope you can look past the size if it's helpful in fixing this.

Sent to support@c

Windows 10 (and 11)
64GB RAM
RTX3060

Thank you!

Have you got a link you could PM me?

[ferropop]

Originally Posted by mozart999uk

Have you got a link you could PM me?

Sent!

[schwa]

Thanks for sending the project. I'm sorry to say it seems to play back normally here, and navigation/zoom/scroll is responsive while playing back.

I do notice that there are about 20 third-party plugins in the project, which you can see if you open the project bay. I don't have any of the plugins installed.

[ferropop]

Originally Posted by schwa

Thanks for sending the project. I'm sorry to say it seems to play back normally here, and navigation/zoom/scroll is responsive while playing back.

I do notice that there are about 20 third-party plugins in the project, which you can see if you open the project bay. I don't have any of the plugins installed.

Thank you Schwa,

my bad for leaving the plugins in, but yeah on Portable fresh install the plugins are missing but I still get the same laggyness here.

I'm at 3840x2160, HDMI to 4k TV. is that the same res you're testing?

I noticed that 3840x2160 at 300% Scaling shows an improvement in smoothness vs 100%, which maybe implies its based less on resolution and more on how many Peaks/Waveforms/Items are on screen at a time? Bigger res -> more things displayed and more pixels. Bigger res + 300% Scaling -> more pixels displayed but less "things".

A test I just thought of : loading in a bunch of WAV files, set the grid to 1/128 or somethign absurd, select all items and "Split all items to grid" - and then comparing performance... just to stress test this? More items more overhead?

Also noticed when Horizontal Zooming, if you go super zoomed out, there's some linear relationship there with smoothness because it's less laggy as the items become smaller. Does that maybe reinfornce # of peaks/items being drawn is a factor?


Just trying to put everything out there, hoping others can chime in with their experiences! I'll just share that it's beyond nitpick at this point, the unscrambled test project is something I've been working on for a bit in my normal install. What I sent was the stems rendered from that original project, and while those are laggy here even in Portable fresh, the actual project itself with the plugins was nearing unusable near the end. So yeah if there's any energy willing to be spent here, I'm sure it would be of great great benefit to many users!



Here I show me flicking the mousewheel and the resulting latency + lag on screen.

[7thresonance]

So, I use a laptop with 120 hz screen. So meters are set to that frequency.

Using scripts, having midi editor open, opening plugin windows all slow down the meters, play cursor follow scroll, zoom performance.

One could argue that my laptop is not strong enough, but other DAWs dont slow the more elements on screen (other DAWs only slow down when there is heavy CPU processes going on)


Let me see if I can make a blank project which can show these lags.

[Sexan]

Can confirm some mentioned issues.

I've experienced that lag Ferro is mentioning in post #26 when zooming but it starts at specific zoom level. But when in that "broken" zoom range lag fiesta is happening as you can see bellow (this is his project):

https://imgur.com/LvxcKDs

I'm on linux and fast text rendering is enabled (because of reasons mentioned here: https://forum.cockos.com/showthread.php?t=299224).

So can anyone else on Windows confirm this (who has access to his project)?

1. Zoom in
2. Scroll around
3. Repeat until it breaks

[mozart999uk]

Originally Posted by Sexan

Can confirm some mentioned issues.

I've experienced that lag Ferro is mentioning in post #26 when zooming but it starts at specific zoom level. But when in that "broken" zoom range lag fiesta is happening as you can see bellow (this is his project):

https://imgur.com/LvxcKDs

I'm on linux and fast text rendering is enabled (because of reasons mentioned here: https://forum.cockos.com/showthread.php?t=299224).

So can anyone else on Windows confirm this (who has access to his project)?

1. Zoom in
2. Scroll around
3. Repeat until it breaks

Do you get this if you use the hand scroll in the ruler / timeline?

I can't get my hand scroll (arrange view) to work for some reason - I've obvs done something with my mouse modifiers that overides it.....

[7thresonance]

Tried to make a project, it lags as more processing is going on. thats just about it.

[Sexan]

I'm currently firing up my laptop to test on windows. I've also removed all leftover fx from every track that has it so no FX/processing going on. Even changed sample rate to match items SR.
And no I did not tested handscroll on ruler just in arrange:

Edit: It seems it happens only if arrange is fully covered with items (width). Also happens with ruler scroll.
https://imgur.com/j6A8NZr
(I'm already in the broken zoom range and still on Linux)

EDIT2: Removed almost all tracks still happens but when on last 10 tracks is not as noticable as 20-30+ but it can still be seen to lag/stutter (still on linux)

Edit3: Confirming same thing on windows

[Seventh Sam]

Originally Posted by Sexan

So can anyone else on Windows confirm this

On Windows 11, don't have access to Ferro's project but can confirm/reproduce in a new project on both my current install and a portable install (latest release). No extra processing, just tracks and media items. EDIT: 2560x1440 resolution, 100% scaling.

At roughly 30+ tracks at the smallest vertical zoom levels and the horizontal zoom level pictured below (use the ruler for reference), the UI began to lag *considerably* when hand scrolling using both the mousewheel and the ruler. This only seemed to happen in a notice-able way when, as Sexan pointed out, the media items took up the full width of the arrange view.

[ferropop]

If its possible can we be sharing the resolution, scale %. Both those things drastically affect my situation. Hopefully some commonality jumps out and is helpful!

[Sexan]

Just try to reproduce the problem as I do in gif #28 and be sure that items cover whole arrange #31.

Dont think anything else matters since I've reproduced the problem on two totally separate machines with different os, components, resolutions etc

[Justin]

Originally Posted by Seventh Sam

On Windows 11, don't have access to Ferro's project but can confirm/reproduce in a new project on both my current install and a portable install (latest release). No extra processing, just tracks and media items. EDIT: 2560x1440 resolution, 100% scaling.

At roughly 30+ tracks at the smallest vertical zoom levels and the horizontal zoom level pictured below (use the ruler for reference), the UI began to lag *considerably* when hand scrolling using both the mousewheel and the ruler. This only seemed to happen in a notice-able way when, as Sexan pointed out, the media items took up the full width of the arrange view.

If you go to preferences/appearance/peaks, and uncheck "Display peaks", does it still get slow?

If it is faster-- re-enable peaks.

It looks like your zoom level is about 700 pixels per second, which is above the default peak cache resolution of 300 samples per second. If you zoom out by about 2.5x, does that speed things up? If you change the peak cache resolution to 1000 (preferences/media/peak generation, then rebuild all peaks) does that speed it up at the 700 pixels/second view?

Also - what is the media type? Is it stored locally or on a network?

At a certain point if you're zoomed in past the peak cache resolution and you have 30 files in view and you need to calculate ~5 seconds worth of audio on each in order to draw a frame, then yes it will take some time. There's some caching happening internally, perhaps some combination of view is causing unneeded invalidations...

[Seventh Sam]

The following tests done on a new project on a portable install, no FX, extensions, etc.

Originally Posted by Justin

If you go to preferences/appearance/peaks, and uncheck "Display peaks", does it still get slow?

Nope, when "Display peaks" is disabled, it runs perfectly smooth.

Originally Posted by Justin

If it is faster-- re-enable peaks.

Re-enabling reverts to the same amount of laggy performance.

Originally Posted by Justin

It looks like your zoom level is about 700 pixels per second, which is above the default peak cache resolution of 300 samples per second. If you zoom out by about 2.5x, does that speed things up?

Zooming out (horizontally) by 2.5x from 700 pixels per second does increase performance, although it's not as smooth as when the arrange view isn't completely horizontally occupied by peak-enabled media items.

Originally Posted by Justin

If you change the peak cache resolution to 1000 (preferences/media/peak generation, then rebuild all peaks) does that speed it up at the 700 pixels/second view?

Yep! After changing the cache to 1000 and running the "Rebuild peaks" action, performance at 700 pixels/second went from laggy to completely smooth.

However, when I horizontal zoom out to the level indicated by the ruler here (is there a more precise way for me to indicate horizontal zoom level than by screenshot?)...



...performance at that horizontal zoom level (with peak cache resolution set to 1000) becomes very laggy, just like before. Is that to be expected, given the higher peak cache resolution?

Originally Posted by Justin

Also - what is the media type? Is it stored locally or on a network?

The media is an MP3 file and it's stored locally.

[Justin]

Originally Posted by Seventh Sam

However, when I horizontal zoom out to the level indicated by the ruler here (is there a more precise way for me to indicate horizontal zoom level than by screenshot?)...



...performance at that horizontal zoom level (with peak cache resolution set to 1000) becomes very laggy, just like before. Is that to be expected, given the higher peak cache resolution?

Does it differ when peaks were built at 1000 vs 700 at that zoom level? In either case, that zoom level is a separate code path (.reapeaks, 10-100 pixels per second etc).

The media is an MP3 file and it's stored locally.

mp3 will definitely be slower to calculate peaks in the original post, since it needs to decode the mp3. Using a .wav file should be significantly faster.

As a side note, we have done some testing and might have some improvements that will help this in the next +dev cycle. Additionally, we've added some helpful benchmarking code you can run and give us the output of, which might help diagnose why it gets particularly slow in certain cases.

[7thresonance]

Made a project. with TDR Kotelnikov. (free compressor)

Meter refresh rate is 120Hz.
MIDI Editor fullscreen.
Continuous scroll
5 Track. (+1 empty midi track)
Portable install

oversampled to 16x.

The more FX is on, laggier the Meters, auto scroll, MIDI Editor.

On my machine CPU usage is at around 40%. RT CPU is close to 50%
256/48K Asio

Basically, the more scripts, FX and processing is going on, the slower the UI becomes.


Link to project: https://od.lk/f/MThfNTU3OTgxODJf

[sockmonkey72]

Originally Posted by 7thresonance

Made a project. with TDR Kotelnikov. (free compressor)

Meter refresh rate is 120Hz.
MIDI Editor fullscreen.
Continuous scroll
5 Track. (+1 empty midi track)
Portable install

oversampled to 16x.

The more FX is on, laggier the Meters, auto scroll, MIDI Editor.

On my machine CPU usage is at around 40%. RT CPU is close to 50%
256/48K Asio

Basically, the more scripts, FX and processing is going on, the slower the UI becomes.


Link to project: https://od.lk/f/MThfNTU3OTgxODJf

I think that's expected and logical (UI lag when DSP overhead is high).

What's not necessarily expected is UI lag due just to drawing of UI elements at different zoom levels.

[7thresonance]

Originally Posted by sockmonkey72

I think that's expected and logical (UI lag when DSP overhead is high).

What's not necessarily expected is UI lag due just to drawing of UI elements at different zoom levels.

its not going above 50% RT CPU though? I dont think thats logical.

There are left over CPU which can draw stuff at full frames rate. (or there should be)

Someone else mentioned that the GUI thread is on the same as the audio thread and GUI is not prioritised.

If thats true, then any script/FX will keep on slowing it down.

Other DAWs dont do this AFAIK. Studio one was smooth until it reaches 90%+ CPU.