From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Spirited Machine ·
Is there any reason why 13 basic, static objects (8 lines and 5 circles) would cause so much CPU usage? My processor isn't that bad. If I remove those elements, CPU is minimal. Is there a way to make GUI elements more CPU efficient, besides using a bitmap in their place? For future additions to the project, those parts will be needed. (More circles, even... Uh oh)
Thanks in advance.
PS. I really feel like a complainer tonight, and I sure don't mean to be. I guess its just that I've really been getting deeper into this program tonight, and I'm running into things that I think might be able to be fixed if I knew what I was doing a little bit more.
electrogear ·
GUI elements shouldn't affect CPU usage at all as far as I know. If you could send it across to me I could get a better idea.
My email is [email removed].
Cheers,
Mike
rl ·
The key to optimize GUI performance is to minimize redraws. Espc with large screen areas this could create slowdowns. Are you using Ticker 25's ?
Spirited Machine ·
Yeah, the ticker25 was the majority of the problem. Last night I thought about changing it to a redraw on load, then got side tracked and never did. Basically all my GUI elements use that. For animated stuff, what do you guys use for redraw triggers?
electrogear ·
Spirited Machine wrote: For animated stuff, what do you guys use for redraw triggers?
Well it depends what you're doing. If you need some event to happen on a mouse click, then it's pretty simple, you just connect the mouse click trigger to the redraw input, but of course if you have something moving all of the time regardless of user interaction then the only thing you can do is to have a ticker 25... no other way around it.
philter5 ·
i think there´s a module called background renderer @ the wiki.
if the shapes should stay static all the time, you can render all the gui elements
in one background image. just an idea, i havent tested it. 😉
background renderer
Spirited Machine ·
For the elements that are animated at all times, I have no choice but to use the ticker. If I have more than one showing at the same time, their redraw rate goes down dramatically. Its like they are competing for it. I have a universal ticker rather than using one for each animated item. I assumed this would be the most efficient way to handle it, maybe not?
electrogear ·
Spirited Machine wrote: For the elements that are animated at all times, I have no choice but to use the ticker. If I have more than one showing at the same time, their redraw rate goes down dramatically. Its like they are competing for it. I have a universal ticker rather than using one for each animated item. I assumed this would be the most efficient way to handle it, maybe not?
Possibly not although I'm not sure as I've never tried it your way. The problem you'll have is with trigger order. I think if you have separate tickers then each ticker will send a simultaneous trigger every 1/25th second, but if you have one ticker connected to several redraws, then they will apply the triggers in the order that you connect them up in, and obviously there will be a very small delay between each, so the more elements you have connected to the ticker, then the redraw rate will be decreased... at least I think that's what would happen. Try getting rid of the universal ticker and apply a separate one to each GUI element. It won't help your CPU problems, but it might correct the redraw frequency problems.
Mike
Spirited Machine ·
Here is the osm and exe. If you have time to check it out I'd be grateful. Hold down the middle C key (Note 60) on your midi controller to display element 1, and C# (Note 61) to display element 2. You can move them (x,y) with MIDI CC 0,1 and 3,4 for the first and second markers, respectively. Element 1 can also be moved by dragging the mouse.
To get the animation for 2 to work, it must be located within the region circled in the image below. The weird thing is, the CPU usage is the same, whether that animation is active or not. So the computation thats using all that CPU is located somewhere else.
It's unfinished, obviously, so thats why the controls are so confusing, haha. I realize this isnt an average synth, so if you have any questions, please ask.
PS- I've tried a universal ticker and separate ones, doesn't seem to affect CPU at all.
electrogear ·
Spirited Machine wrote: Here is the osm and exe. If you have time to check it out I'd be grateful....
PS- I've tried a universal ticker and separate ones, doesn't seem to affect CPU at all.
Yep I'll take a look. I didn't think it would affect CPU, just thought it might help your redraw frequency problem.
electrogear ·
Having trouble getting the 2nd marker in view - it's off the bottom left of the screen somewhere. Did you say it responds to midi cc 0,1 & 2? It doesn't seem to work for me...
Spirited Machine ·
2nd marker responds to CC 3,4
rl ·
hmm.... you could put the animated circles in it's own module with it's own view (using it's own MGUI module) and have the mouse/midi CC events move the module's view. Thus each redraw needs to draw only the circle's view not the whole spiderweb
Spirited Machine ·
That's a good call. I'll try that out.
electrogear ·
Yeah as rl said you don't want to be redrawing the whole synth it would be much better if each element had it's own view. Also, you want to connect the midi cc outputs to the redraw so they update on midi cc change.
Cheers,
Mike
Spirited Machine ·
Tried making each of the markers their own module with their own MGUI. MIDI changes the MGUI x,y location now, and this is what happened.. Any ideas why?
electrogear ·
Hmmm... maybe you need to redraw the background too, but only on mouse operations or midi cc operations....
Spirited Machine ·
I realized what I was doing wrong. I didn't really understand the concept of redrawing. I had a redraw component connected to the view output of each of my individual gui elements(circle, rect, etc), as opposed to only the view output of the MGUI component. Once I changed this, there was no problem with each component having to 'share' a ticker, instead the entire view is redrawn, so adding gui elements doesn't seem to change the CPU much, if at all. Here's a basic example:
If what I have shown above is still an inefficient way to do it, let me know, but its at least an improvement from what I had before. Thanks for the help. 🙂
sunsynth ·
You can also try this: divide the ticker25 by 2 or 3... 😉
matti ·
Here's an optimized version of it -> link
It's a good example for anyone wanting to make effiecient GUI's.
(i like to run everything at least 50fps btw)
edit: Oh yeah, and i didn't bother to read the instructions on using that interface before playing around with the GUI-elements, so let me know if i left out something important.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker