ReaScript GFX/defer: 60 FPS Refresh Rate

[X-Raym]

Hi !

Current FPS refreshing rate of GFX window are 32/33 fps (hz). Nice for relatively fix graphics (usual GUI).

For smooth display of moving elements, having 60 fps would be nice.

This will make scripts like my ReaTab Hero way smoother and nice to look at.

Of course, if it can go even higher (120hz... ?) it will be even better but the benefit will be less important. 60 FPS allows smooth displacement of shapes on most screen already.

Thanks for listening !

EDIT 2020-01-15
Resume of our dicussion

Originally Posted by tack

So just to aggregate all our ideas into one place (and to cheekily bump the thread at a time when hopefully Justin or schwa are watching):

Proposal: introduce a read-write variable to ReaScriptAPI called gfx.refresh_rate (gfx_refresh_rate for EEL) which controls the script's GFX window updates.

The value MUST affect the frequency of defer() calls in addition to GFX update rate.
The value SHOULD be dynamically adjustable. This allows scripts to temporarily increase refresh rates (e.g. during a transient animation or user interaction) or even to decrease rates as a means of self-throttling.
Negative values MAY imply fractional values, so e.g. -3 means 1/3 (or 1 refresh every 3 seconds). Alternatively, to allow for greater precision, negative values could indicate tenths of a second, so a value of -15 means 10/15 (or 1 refresh every 1.5 seconds).
The value SHOULD have some reasonable upper bound (e.g. 100)


(#3 is a MAY because scripts can already self-throttle easily enough. Yes, defer is still called, but a simple callback that checks current time is so cheap that it's scarcely worth the effort of avoiding.)

[mpl]

See "stretch marker guard", I did smooth GUI changes by constant switch of blitbuffer id nd alpha channel. Sort of workaround.

[X-Raym]

@mpl
Does it allows more than 33Fps ?

Even the most basic GFX loop (simple black window) is 33 Fps...

ReaScripts-Templates/X-Raym_GFX FPS.lua at master · ReaTeam/ReaScripts-Templates

For fast moving elements like ReaTab, 60Fps is the only way to make it smooth, I can see that by comparing with other softwares.

[mpl]

I think it is common limitation of ReaScript made for better performance. So the request maybe is to have ability change refresh rate for defer ().

[X-Raym]

Yep, it is the same for simple defer scripts.

My point is that extending it to 60 fps allows smooth fast movement on GFX interface, which may be a valuable reason to request higher ReaScript speed :P

[lb0]

+1

Scrolling the strips in LBX Stripper is noticeable jerky @ ~30fps. Everytime I move them I wish for a faster refresh (as well as for other non gfx benefits of doing so).

[BirdBird]

Huge +1

Reviving this thread back from the dead. So many windows and hotkeys I use in REAPER are amazing third party defer scripts. It is sad to see them operate at 30 FPS, it feels clunky.

[SubbaseDnB]

i will give this a +1 too

[mschnell]

Originally Posted by X-Raym

My point is that extending it to 60 fps allows smooth fast movement on GFX interface, which may be a valuable reason to request higher ReaScript speed :P

Supposedly not.

As the GUI thread needs to have a lower priority than all audio threads, defining a higher refresh rate in many cases will not be able to be met by the CPU, resulting in stuttering GUI and lower GUI performance.
OTOH higher refresh rate will create more thread switching and hence more "unproductive" CPU overhead and hence hamper the audio performance.

-Michael

[Klangfarben]

Originally Posted by mschnell

Supposedly not.

As the GUI thread needs to have a lower priority than all audio threads, defining a higher refresh rate in many cases will not be able to be met by the CPU, resulting in stuttering GUI and lower GUI performance.
OTOH higher refresh rate will create more thread switching and hence more "unproductive" CPU overhead and hence hamper the audio performance.

Pretty doubtful. Even at 60fps, the script would have to be doing a pretty massive amount of graphic manipulation to have any effect whatsoever on the audio performance. I have yet to see a script that would do that. We're talking about basic things like smoother scrolling here, not video editing or 3D rendering.

[BirdBird]

Originally Posted by mschnell

Supposedly not.

As the GUI thread needs to have a lower priority than all audio threads, defining a higher refresh rate in many cases will not be able to be met by the CPU, resulting in stuttering GUI and lower GUI performance.
OTOH higher refresh rate will create more thread switching and hence more "unproductive" CPU overhead and hence hamper the audio performance.

-Michael

So far no script has even came close to the amount of CPU overhead that basic actions like scrolling/zooming/opening the MIDI editor have for me. My guess is the tiny bit of extra CPU usage from scripts running at a faster rate would be peanuts in comparison.

[mschnell]

You might have hundreds of script active at the same time and you might want to watch their GUI while playback or rendering.

-Michael

[BirdBird]

Originally Posted by mschnell

You might have hundreds of script active at the same time and you might want to watch their GUI while playback or rendering.

-Michael

Like with everything else in REAPER, it would ideally be a setting. If you don't need it, don't use it. I personally keep track of all the background scripts I use and I would only benefit from a faster clock for defer scripts.
I sometimes show cool third party scripts in REAPER to other people and almost always the framerate bothers them, it's 2019, we are all used to smooth 60fps.

[mschnell]

Originally Posted by BirdBird

it's 2019.

No

[X-Raym]

Maybe few scripts needs 60 fps, but for those which need it (especially those with moving graphics), it can be game changer :P

[BirdBird]

Originally Posted by mschnell

No

Ooops

[kf.]

As a new user coming from other DAWs and using scripts to bring in features that I love, it's definitely jarring to have them respond in a slow and jerky way vs all other UI elements.

60fps scripts would be amazing

[Dafarkias]

This new generation doesn't know how good they have it... Complaining about not having 60 cycle-per-second GUI/defer rates for their scripts.

I remember way back when:

I would have to stick my 1 kilobyte floppy-disc into a toaster oven just to play Tetris. 640x480. That $#&@ was fire, too.

[Dafarkias]

Jk!

+1

[Klangfarben]

Yes, I think part of the basic issue is that as a Reaper user, like it or not, you are heavily dependent on scripts. In fact, I'm not sure Reaper would be usable for me without them. So, when they are treated like second class citizens it really affects your entire workflow as several of those scripts are going to be constantly running (Heda's Track Inspector, lb0's LBX Stripper and Smart Knobs, Sexan's Pro Tools Playlists and soon-to-be finished Area Selection, Tack's Reaticulate etc.)

I have a feeling from reading many posts that GUI issues in scripts are just not something the developers are really worried about since not many scripts make use of anything very complicated GUI-wise. But I think it really is hurting the overall development of Reaper, especially when scripters run into things like the GUI not refreshing fast enough. That's just not something that should happen in this day and age with the available tools IMHO.

[_Stevie_]

I second that Klangfarben. I'm pretty much using the same scripts as you do and I would even say that we are not alone here. These scripts augment Reaper by a HUGE amount. I also wouldn't have jumped on the Reaper bandwagon wasn't it for the API and available scripts. They literally enable you to create the DAW for your own needs.

I see it like that: the API was created so that the community can add whatever new functionality is needed. Which is absolutely great, amazing move by Justin and schwa and sooo much appreciated. Also, this makes Reaper really unique. No other DAW features this kind of level of integration.

Long story short: 60 fps would be absolutely fantastic for all gfx needs, like area selection, Julian's MIDI tools, etc...

[Dafarkias]

Not to be a devil's advocate, but isn't it actually already insane the capabilities that the API already possesses? (especially when combined with SWS & JS extension)

To me, it's pretty radical that a DAW software provides its own GUI functions in an API, period.

If a scripter really wanted, they could also program their script as a c++ extension. The refresh rates would (probably?) be better then. But you'd probably have to include a GUI library or build your own.

I'm spit-balling here, this isn't really my area of technical expertise. You get what you pay for, right? The API is pretty good for a software that cost $60.

Maybe the donationware scripters could start a kick-starter campaign for Justin and Schwa to incorporate a list of the most needed improvements to the API.

I'd pitch in another $60

[Klangfarben]

Originally Posted by Dafarkias

Not to be a devil's advocate, but isn't it actually already insane the capabilities that the API already possesses? (especially when combined with SWS & JS extension)

To me, it's pretty radical that a DAW software provides its own GUI functions in an API, period.

If a scripter really wanted, they could also program their script as a c++ extension. The refresh rates would (probably?) be better then. But you'd probably have to include a GUI library or build your own.

I'm spit-balling here, this isn't really my area of technical expertise. You get what you pay for, right? The API is pretty good for a software that cost $60.

Maybe the donationware scripters could start a kick-starter campaign for Justin and Schwa to incorporate a list of the most needed improvements to the API.

Dude, it's a feature request, not a kickstarter. That's not how Reaper works. That's not how any DAW works. The scripters are out there making Reaper a better product, most of them making little or no money off of it. When a bunch of people chime in for a Script or API request it's usually because it is much needed and there aren't suitable workarounds. And if you are concerned about compensation for Justin and Schwa you can always shell out for a commercial license instead

[Dafarkias]

True dat.

Put it in the stack of thousand-odd other amazing feature requests that haven't been reciprocated over the years.

Lol

But for what it's worth, 60-cycle defer would be nice...

[X-Raym]

@Dafarkias
No one is telling reaper or bad or that scripting isnt good in it as it is.

I just faced a simple issue with one of my script.
I cant fix it myself cause it is a limitation so I report.
Theb it is up to dev to evaluate.
Maybe it is a very simple fix with no side effects. Cool, my script will be awesome, and writting this FR would have worth it :P
Maybe it is a complex fix which need rewritting core aspects of the software. In this case, considering the usage amount that it will have, be sure it will be discarded by devs. Thats ok, we have plenty of other things to play with :P

[Xenakios]

It would be useful to benchmark first if the problem is actually because of the defer calls timer frequency.

If the script defer functions do too much work, upping the update speed wouldn't help anything, it would just make things worse, because Reaper would be calling the heavy functions more often.

A resourceful C++ developer could probably figure out the ID of the defer timer and raise the update frequency. My prediction is that it wouldn't help the scripts that have GUI update problems at the moment, but it still would be a useful thing to test.

edit : Looks like the script defer timer is the same one (ID 666) that is used to update the play cursor position etc. It is possible to make an extension plugin that changes the speed of that, but because it is used for other things too besides deferred ReaScripts, it might lead to some complications. So probably not a good idea...Maybe best to just hope the Cockos developers make the ReaScript timer a separate one with a user adjustable speed.

[Meo-Ada Mespotine]

I have thought about that for quite some time and I think it would be nice to have something like the gfx.ext_retina:

   gfx.refresh_rate

which is set to 30 by default and can be set to higher, or even lower.

Means, Reaper could know, how often per second to run the deferred script(even if it's only approximate), and do the scheduling of scripts based on it.

Though I don't know, how often Reaper's Gui itself refreshes. I think, it's only 30fps in the first place, so this would mean big overhaul on that one. Especially, as GPU-support for the GUI-part is an old request.

But nevertheless: the above approach could make it compatible with old scripts while giving new ways of limiting the need for ressources, just to make scripts run as often as needed.
And bringing it up to a refresh-rate needed by the user, maybe even more than 60fps for hardcore power-users.


Edit:
Another thought: negative values mean "run only every x seconds", so I can set it to -3 and it will run the defer-loops only every three seconds.

[Klangfarben]

+1 for Mespotine's suggestion above. That is a really elegant way of handling it if the Devs can do it.

[_Stevie_]

Woah, that's such a brilliant idea Mespo! Totally supporting that one.

This would also mean that we can set scripts, that don't need a high refresh rate, to a lower value and therefore save some CPU.

[tack]

This would be great! And it should be dynamic as well, so e.g. I can bump up the refresh rate during some sort of animation or active user interaction, and lower it when the script is otherwise idle.

[Meo-Ada Mespotine]

Originally Posted by tack

This would be great! And it should be dynamic as well, so e.g. I can bump up the refresh rate during some sort of animation or active user inaction, and lower it when the script is otherwise idle.

Yes, exactly. And if I only need to run my script once per second, it would need only 1/30th of ressources+some overhead on Reaper's side for the scheduling-management.

And an occasional bump possible with this isn't something I have thought about, but it would be awesome as well to have that kind of control

[_Stevie_]

Well, that would be even more brilliant, lol.
Not sure how much housekeeping such a monitoring would need?

[X-Raym]

We know only need an answer from the devs :P

[cool]

Yes! +1

[tack]

So just to aggregate all our ideas into one place (and to cheekily bump the thread at a time when hopefully Justin or schwa are watching):

Proposal: introduce a read-write variable to ReaScriptAPI called gfx.refresh_rate (gfx_refresh_rate for EEL) which controls the script's GFX window updates.

1. The value MUST affect the frequency of defer() calls in addition to GFX update rate.
2. The value SHOULD be dynamically adjustable. This allows scripts to temporarily increase refresh rates (e.g. during a transient animation or user interaction) or even to decrease rates as a means of self-throttling.
3. Negative values MAY imply fractional values, so e.g. -3 means 1/3 (or 1 refresh every 3 seconds). Alternatively, to allow for greater precision, negative values could indicate tenths of a second, so a value of -15 means 10/15 (or 1 refresh every 1.5 seconds).
4. The value SHOULD have some reasonable upper bound (e.g. 100)

(#3 is a MAY because scripts can already self-throttle easily enough. Yes, defer is still called, but a simple callback that checks current time is so cheap that it's scarcely worth the effort of avoiding.)

[X-Raym]

@tack
That sounds good. I ported this resume in first post.

[lb0]

Yes - would still love to be able to have more control over this - even if I break things with it

Tack's breakdown would work for me.

Finally I scraped the cash together to upgrade to v6 (releasing just before Xmas meant I'd have to wait) - nothing in v6 so far to excite me - but wanted to support the devs as it seems like forever ago I paid for v4!

However - I would like my $60 upgrade to go towards this functionality - yeah - i know it doesn't work like this - but worth a try...

[BirdBird]

I really like mespotine's solution as well.



(this is definitely not a bump)

[Meo-Ada Mespotine]

Just for completion: some more thoughts on my idea and what could be potentially problematic with it for scripters.

The current behavior is the following(afaik):
Every deferred-script will be scheduled in the order of being started.
That means, if defer-script1 has been started first and defer-script2 has been started second and defer-script3 as third one, this order will remain.
That means, you can be sure, that every defer-cycle will be:

defer-script1
defer-script2
defer-script3

You can code upon this assumption. So if defer-script1 sets an extstate and defer-script3 reads this extstate, you can be sure that the extstate will be set first and read after that. So communication between defer-script1 and defer-script3 can be designed once and will work.

Now, my attempt could change that order. If you run the defer-script3 twice as often, the order could be:

defer-script1
defer-script3
defer-script2
defer-script3

This can lead to so called "Race Conditions". So if the defer-script3 expects the extstate set before being run, this will not be the case.
In fact, the extstate is set by defer-script1 only once in the example above, because it is run only once per "schedule-cycle".
But if defer-script3 expects it to be updated every time, it will only get a new extstate only every second defer-cycle of defer-script3, as defer-script3 is run twice in the example above.

More on the topic of Race Condition can be found here: https://en.wikipedia.org/wiki/Race_condition

So if the devs add my approach, you need to be very careful if your script is dependent on outputs/extstates/etc of another defer-script running at the same time.

[_Stevie_]

This definitely is a bump