Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

ReDraw limiter (Ruby)

Post any examples or modules that you want to share here

ReDraw limiter (Ruby)

Postby trogluddite » Mon Nov 26, 2012 10:06 pm

I have fond memories of the many days work, and dozenss of posts that infuzion and me put into the whole problem of getting GUI CPU load down in SM using 'heartbeat' timers and trigger trickery.
And then along comes this new fangled FS3 thingy, and now the same thing, and better, can be done in half an hour with just a few lines of code! Those guys at DSPr are such a bunch of spoilsports sometimes! ;) :lol:

ReDraw Limiter (Ruby).fsm
(126.54 KiB) Downloaded 1624 times

Rapidly changing input events will only update the output at the maximum 'frames per second' set in the dialogue (maxes out at 100fps as a 'safety measure'). There will also only be an output event if the input has actually changed.
This can really help to lower CPU load from screen redraws when you have GUI stuff driven from fast moving data.

The code is generic, and will work for pretty much any kind of data, so long as you set the in and out to be the same data type (there are exceptions - some obscure Ruby objects cannot be 'compared', in which case just delete the testing with the @last value). I've commented the code, so hopefully it will be easy to do a cut-and-paste job if putting it inside your code is more appropriate than a separate module.

There are even some advantages over the old green method...
- Independent frame rate for each event limiter, so different displays can have different degrees of animation 'smoothness'
- No complex reading of system time needed to get an accurate 'heartbeat'
- The first event after a long pause is output immediately without waiting for a 'tick' of the clock
- The clock goes to sleep if there is no input event between 'ticks' - so when input activity stops, there is no processing at all going on at all.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: ReDraw limiter (Ruby)

Postby Walter Sommerfeld » Wed Nov 28, 2012 7:41 pm

Awesome... nothing more 2 saw right now ;-)

4 all vikings here: spoilsports means "Spielverderber" :lol:

btw: Is ruby drawing over GDI+ ???
User avatar
Walter Sommerfeld
 
Posts: 249
Joined: Wed Jul 14, 2010 6:00 pm
Location: HH - Made in Germany

Re: ReDraw limiter (Ruby)

Postby trogluddite » Wed Nov 28, 2012 8:09 pm

Walter Sommerfeld wrote:btw: Is ruby drawing over GDI+ ???

Well, the raw redraws are much the same as far as I can tell - so long as everything else is well optimised the CPU load seems about the same. But that's pretty much what I would expect, as GDI+ is just part of windows, so no-one has any way to make it work faster.
Where I think there is an advantage is that when using Ruby there is much better control over events, so refreshes are simpler to control, and the placing of many GUI items prior to re-fresh seems much more efficient.
For example - the 'Super text box' that I made draws every single "spreadsheet cell" individually for better control of format, text colour etc. - equivalent of nested draw loops and multiple array accesses with dozens of selectors. Yet I can measure little more CPU load than for SM drawing a simple block of text to fill the same area (and I still need to add the redraw limit to that design).
However, you've still got to watch out for excessive screen updates - put 100 value changes per second into an area of that size, and it will still suck CPU - hence writing this little module.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: ReDraw limiter (Ruby)

Postby Walter Sommerfeld » Thu Nov 29, 2012 12:11 pm

Hi trog,

thanks 4 ur well explained Info...

I placed here Big CPU Prob my new GUI test :evil:
User avatar
Walter Sommerfeld
 
Posts: 249
Joined: Wed Jul 14, 2010 6:00 pm
Location: HH - Made in Germany

Re: ReDraw limiter (Ruby)

Postby trogluddite » Thu Nov 29, 2012 9:34 pm

Walter Sommerfeld wrote:I placed here Big CPU Prob my new GUI test

Did I pass the test? ;)
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Suggestion

Postby infuzion » Mon Dec 24, 2012 5:01 pm

trogluddite wrote:I have fond memories of the many days work, and dozenss of posts that infuzion and me put into the whole problem of getting GUI CPU load down in SM using 'heartbeat' timers and trigger trickery.
It didn't take me long to build the "heartbeat"; there already were many examples of gating a trigger with another trigger. What took me 1-2 hours was to test if the Ticker 100 or Time primitives were more accurate.

trogluddite wrote:- Independent frame rate for each event limiter, so different displays can have different degrees of animation 'smoothness'
I wonder if this ideal; if there was a global "heartbeat", would that not save CPU cycles & memory (timer objects) over 50 ReDraw limiters? Perhaps not all 50 would run at the same time, but could be a dozen with parameter automations, wave form & filter displays updating at once. Though running a knob & wave-output at different FPS would be helpful.

Minor Suggestion: If FS-Ruby has an "VST Editor Open" command built-in (like the primitive), that would be better to add. Plus if this is targeted at ReDraws, I would cap at 60FPS; most gamers are happy with that number (I personally would not waste the Ruby Code on the cap; I would hard-wire fix it at __FPS inside the Ruby, but I'm not suggesting that ;) )

:idea: FlowStone Suggestion: Add this in FS's stock modules already please! :ugeek: :D
infuzion
 
Posts: 109
Joined: Tue Jul 13, 2010 11:55 am
Location: Kansas City, USA, Earth, Sol

Re: ReDraw limiter (Ruby)

Postby trogluddite » Mon Dec 24, 2012 6:41 pm

Hi there, thanks for the comments and suggestions.

infuzion wrote:I wonder if this ideal; if there was a global "heartbeat", would that not save CPU cycles & memory (timer objects) over 50 ReDraw limiters? Perhaps not all 50 would run at the same time, but could be a dozen with parameter automations, wave form & filter displays updating at once.

Yes, I am still pondering that questions. I need to get around to setting up a big rig to see what, if any, difference there is between 'synchronised' and 'staggered' redraws. My hunch is that it probably won't make much difference - presumably every redraw is a separate call to GDI+ that will be scheduled however the CPU see fit - but no hard evidence yet!
Like you point out, much could depend on how much automation etc. is used. In the situation where control changes are relatively sparse, this way should be a little better, as 'unused' control have absolutely no activity - and not even a heartbeat running when no controls are being moved.
When many are likely to move at once, I usually opt for the 'shared redraw'area' method - but that technique is a little tricky to make into a single 'general purpose' toolbox module.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: ReDraw limiter (Ruby)

Postby infuzion » Mon Dec 24, 2012 9:33 pm

I'm not too certain which would be better also.

Or is it worth staggering the redraws?
infuzion
 
Posts: 109
Joined: Tue Jul 13, 2010 11:55 am
Location: Kansas City, USA, Earth, Sol


Return to User Examples

Who is online

Users browsing this forum: Google [Bot] and 45 guests

cron