From the original SynthMaker forum (2004–2014), with its members’ names and dates.
MichaelBenjamin ·
even if you have some tiny area animated on your gui you can be sure that one cpu core will be quite occupied redrawing these pixels. theres nothing you really can do about it other than limiting redraws to like 1 every minute. i dont know but i think to make use of all the gfx capability that sm has that graphics engine needs to be faster and more efficient.
even for personal use, a simple and tiny 8x24 pixel midi key vector graphics uses up to 7% cpu when clicked fast with the mouse. if you play some midi file with 4-8 poly one of my cores is just processing that gui keyboard. and i already made sure that no useless retriggering occurs.
ontop of that it makes all other gui updates sluggish as hell. so if you want to move a knob while that keyboard is displaying, its a slideshow. and its neither really much pixels, nor transparent and layered gfx.
and that with a 2.2 ghz processor.
> the current gui redraw system renders every non static graphics pretty much unusable, no matter if for personal or commercial use.
aliasant ·
I would have agreed with you before but I have learned that the gui can be fast as long as programmed ok.
I have plugins with lots of graphics not using more then max 1% if even that. Not really measurable.
Would be nice if SM did this for us though. Making it easier for developers.
MichaelBenjamin ·
then do us a favor and put up some basic dos and donts tutorial. i am quite a shithead when it comes to that green gfx things. area redraw? trigger limiting? yes yes, but dont make bold statements and say your completely animated stuff runs with 1% cpu without giving some tips. jeez.
MichaelBenjamin ·
yes that came off a bit harsh but thats because everytime i want to animate something it turns into a slideshow too fast and i cant even use it myself so i am a bit pissed off. dont take it personal.
aliasant ·
MichaelBenjamin wrote: then do us a favor and put up some basic dos and donts tutorial. i am quite a shithead when it comes to that green gfx things. area redraw? trigger limiting? yes yes, but dont make bold statements and say your completely animated stuff runs with 1% cpu without giving some tips. jeez.
lol!
Ask Mwvdlee.
You could say that a big part is about drawing bitmaps instead of rerendering pixels.
Only draw what is actually moving and only when needed.
Theres a lot of work getting it to draw fast and it takes time to understand. I still have a long way to go but atleast I can make some graphics that wont eat my cpu and still look great.
aliasant ·
MichaelBenjamin wrote: yes that came off a bit harsh but thats because everytime i want to animate something it turns into a slideshow too fast and i cant even use it myself so i am a bit pissed off. dont take it personal.
I know exactly how you feel.
I have poored my frustrations all over Malc several times..... and he has been patient with me.
Now I know its not his fault 😉
MichaelBenjamin ·
so i have to use that cached thing to make it work?
now i found out that that the graphics alone doesnt do much to the cpu, but if its displayed one level higher in another window together with some static text png the cpu goes up again like mad as if it would redraw the new window with the text in hires. but that V linking to the redraw is inside the animated part only, and the text has no redraw at all. i dont understand this.
aliasant ·
MichaelBenjamin wrote: so i have to use that cached thing to make it work?
now i found out that that the graphics alone doesnt do much to the cpu, but if its displayed one level higher in another window together with some static text png the cpu goes up again like mad as if it would redraw the new window with the text in hires. but that V linking to the redraw is inside the animated part only, and the text has no redraw at all. i dont understand this.
If you send me an osm I might be able to help. Not tonight. Off to bed now but I might have some time tomorrow while doing my laundry 🙂
MichaelBenjamin ·
yes, thank you, i take another try and if it does not work i will take your help.
infuzion ·
I posted a trigger redraw limiter around Xmas.
aliasant ·
MichaelBenjamin wrote: yes, thank you, i take another try and if it does not work i will take your help.
Lemme know how it goes.
MichaelBenjamin ·
infuzions redraw limiter has further reduced the amount of cpu - thanks for this, i only used the stock trigger limiter before. now its somewhat usable. i have to look if i can tweak it some more.
aliasant ·
MichaelBenjamin wrote: infuzions redraw limiter has further reduced the amount of cpu - thanks for this, i only used the stock trigger limiter before. now its somewhat usable. i have to look if i can tweak it some more.
Your getting closer I guess 🙂
Making a fast gui takes a lot of time. Not at all as easy as it looks.
infuzion ·
MichaelBenjamin wrote: infuzions redraw limiter has further reduced the amount of cpu - thanks for this, i only used the stock trigger limiter before. now its somewhat usable. i have to look if i can tweak it some more.
Welcome.
SM's Redraw Limiter only limits to to "redraw rate" which is 100 Frames Per Second IIRC. Animation generally is 30-15FPS, sometimes you can get away with 12FPS. Sometimes merging a section into a single View/Redraw improves CPU% also.
trogluddite ·
infuzion wrote: Sometimes merging a section into a single View/Redraw improves CPU% also.
Yup,this has worked really well for me in my latest project - I put all my animations in the same area of the front panel - took the redraws out of the individual animations - then overlayed that area of front panel with an empty GUI box containing just an MGUI, ticker, and Redraw Area. CPU is not much higher than having just one of the smaller animations active, but it updates all of them. It's surprising how big an area you can redraw economically this way.
Also, don't trigger redraws from the prameter input to an animated module - for example, with an animated bitmap, take the triggers from an 'integer changed' (in the Developers Toolkit) connected to the frame number, so there's only a trigger if the input value has changed far enough that you'd actually see the difference. Likewise with vectors - try to check how far the nodes have moved - if it's less than say 1/2 a pixel, there's no need to redraw.
infuzion ·
trogluddite wrote: Also, don't trigger redraws from the prameter input to an animated module - for example, with an animated bitmap, take the triggers from an 'integer changed' (in the Developers Toolkit) connected to the frame number, so there's only a trigger if the input value has changed far enough that you'd actually see the difference. Likewise with vectors - try to check how far the nodes have moved - if it's less than say 1/2 a pixel, there's no need to redraw.
That's a good idea! I am a bit afraid that very slow & minor automation over a long time might never be updated though?
trogluddite ·
Sorry, I didn't describe the vector method so well there.
Basically what you do is to put a quantiser just before the vector GUI modules - quantising the co-ordinates at 1/8 or 1/16 of a grid intervals, and then use a 'float changed' just after it to generate the triggers - so it's not so diffeent to the bitmap method really - all the bits you need are in the toolkits on the forum. I 've added a trigger output to the 'changed' modules (from the trigger switch) for this purpose in my tookit.
P.S. Thinking about it, I think the 'integer changed' isn't actually there in the dev.toolkit, but it's easy to make by copying the 'float changed' using integer primitives rather than float, if you need an integer version.
infuzion ·
trogluddite wrote: P.S. Thinking about it, I think the 'integer changed' isn't actually there in the dev.toolkit, but it's easy to make by copying the 'float changed' using integer primitives rather than float, if you need an integer version.
I know Sample & Hold on Change isn't in the dev.toolkit, because I'm the one who originally designed it 3-4 years ago! I think I know what you're talking about; rounding off the value before evaluating to send a trigger. I built a module like that also; Sample & Hold within Tolerance, but I think the green triggering system has been tweaked since then, so it doesn't work.
Could you post what you built please?
infuzion ·
infuzion wrote: Could you post what you built please?
Ok, I think I figured out a way, though it is rather simple & perhaps not flexible enough.
Float Trigger on Step Change [old link]
I also think I inadvertently found other ways to reduce CPU & redraws in the knobs.
trogluddite ·
infuzion wrote: I'm the one who originally designed
Your modules there have been a godsend - taught me loads 😀 Just that I always try to post with all the info that less informed readers will need to get up and running - saves lots of repeat noob questions being posted all over.
I'll dig out some bits and bobs and get them posted (no internet on my main SM machine) - this thread has a good title that's easy to search for.
EDIT: New thread 'Lower GUI CPU Load' started in Registered Users forum - can't post attachments here.
sunsynth ·
Yippie Luddite...
will have a look at ur schematics... in my K-Meter mod i used the first time a 'hole front only' redraw
I think it even helps minimizing flickering
Walter
nix ·
One way to reduce graphic cpu is to divide the trigger connected to redraw. I have now 8 fps and cpu is lower than Image Line's similar product. There is the primitive 'trigger divide'.
🙂
infuzion ·
nix wrote: One way to reduce graphic cpu is to divide the trigger connected to redraw. I have now 8 fps and cpu is lower than Image Line's similar product. There is the primitive 'trigger divide'.
IMHO; that is a bad idea for somethings like knobs that you need precise viewing; you will have only a 1 in 8 chance that you will see the last update! Turning with a mouse usually is not a big deal, but turning with a MIDI knob or worse using automation this will simply not work well. Best bets: [old link]
Thanks for the idea though.
nix ·
MyCo has tried to teach me area unions. I'll try again soon.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker