GUI refresh and CPU usage
Hi everyone:
I have a few questions about GUI refresh and CPU usage, because one of my patchers crashed a few days ago, so i'm looking for the best way to optimize GUI because it was the main cause i think.
I think CPU (or GPU, whatever, i don't know the specific GUI generation method in Max) is refreshing image even when you have an opened patch behind another opened patch, but...what happens when you have a patch minimized on the dock (Mac) or desktop (Windows)? is CPU still busy refreshing image or you will save CPU this way? I guess no, but im not quite sure.
The second thing is about screen...is Max still busy processing image of an entire patch when, lets say, you can only see the 50% of the patch on the screen because it's too large?
The third and last one for the moment...is Max still busy processing image of GUI objects when they aren't in presentation mode or they are behind another object (for example, a number box behind a panel)?
Thank you in advance
Hi !
Ive been testing it some time ago (it was very important aspect during my dev) . GUI is processed/refreshed only while patch/device is visible , its also true to M4L in ableton . im even more sure as ive seen flags for visibility state in the SDK , that could be used for bypassing some of the calculations . Dont know how max is handling it internally (i heard that they improved it further) but its framework (that Max is build upon) works the same way . Im near of beeing sure that 50% of visible patch is treated as a whole , but not 100% sureness here .
Thank you so much. I have a question about what you said.
A visible patcher is just a patcher that you can see in your screen? for example, a patcher behind another patcher (both opened) would count as hidden for GUI purposes?
Or for example, what happens when you have a huge patcher but you manage the window flags to a [thispatcher] to see only a small amount ot the window? Is it different from when you manage window flags AND hide the rest of the objects sending them a presentation 0 message (if im seeing it all in presentation mode of course)? I would use it to make a "minimal view" of a patcher just to trace the important numbers and GUI objects instead of the whole patch but, only if it saves some CPU usage.
Hi !
yes good question . Patcher behind the patcher is not considered as a hidden (at least with my tests) .
If your patcher has some visible area restrictions (like constraining smaller window size) , then only whats visible is refreshed on your screen , thats pretty good feature (so every ui outside visible area is left from redrawing mechanism).
Hiding/removing Ui elements from presentation/edit mode makes them suspended from refreshing for our luck .
I like the idea of "minimal view" , that would help in some situations for sure .
Anyway , is it really hitting the ceiling with the ui refresh within your patcher ? Are you updating your ui constantly at some rate ? Take a note that if u do some fast and frequent updates while ui's are binded to the pattr it will go crazy under the hood . For me pattr updates are more of a problem than ui's itself .
Thank you so much...that's very valuable information for me.
No, i'm not hitting the ceiling with UI refresh, but it's important for me, because i'm managing a mixer with a lot of channels, meters and stuff and they will be more soon for sure.
In my patches i unconsciously left some GUI out of the pattr system (and in most cases they were exactly the ones who are updated periodically) but i think i should double check it in order to save some possibly wasted CPU usage.
I have another question, maybe it's a little offtopic but it's about SVG icons...i want a uniform display using svg icons instead of the ones who are within Max ( i mean uniform because some of the Max internal color and border settings are different between Max 6 and 7 for example, thus changing graphic interface). To do this, i use a live.text object because it allows you to use a custom SVG file, but i'm not shure if it will cost more CPU usage somehow in general, than using the common Max buttons. I think if the icon is heavier it will, but i don't know if it's affected somehow for using icons away from the Max folders.
im enthusiast of uniform interface look as well . The SVG question is not an off topic . Its great that you are taking it under consideration here .
Unfortunately i will only assume here , that rendering TEXT is much heavier than SVG path in Max ,as Text require additional API calls to font and its textpath separately , where additional measurements and conditions are checked in order to display text in a justified form at a appropriate size etc .
With SVG ,its path is handled natively by the drawing API borrowed from its framework , its much straight forward i guess .
Im gonna test this out tomorrow (im actually very curious about it) . It might be that Max handles "what to display" as a graphical baked-layer (prerendered/predrawn) which would mean that it doesnt matter what u display ,it will be safe from unnecessary overhead of redrawing procedure . This is how i had to achieve more efficiency in my heavy UI development .
But those are just assumptions . i have to check it
HI .
ive been doing raw tests on svg vs text (live.text - size 32x15) , and i must say that its hard to spot the difference . More to that , CPU usage is so low that the resources impact wont be really an issue . But of course it depends .
Ive been flashing 22 elements every 100ms , with CPU (non-intel) usage below 3% . it doesnt matter if i use Max svg's or my own .
I have to note here that , only those elements will consume CPU that are currently affected by changing state. Ui's that stays in the idle are not consuming any resources as far as ive noticed .
Not 100 % sure but i think Cycling mentioned that they improved rendering mechanism , so only areas that are changing its apperance will be queued for CPU . Max is a clever beast . Seems like every graphical context is managed separately , and that's amazing .
A bit different matter are knob's and sliders . Updating those require much more work under the hood (constrains , value mapping etc). as well there are more pixels to refresh as usually those elements covers much more space to compute .
Anyway , im not an expert , im just observing the behaviour within the area im aware of .
Ive been creating my own UI's with JSUI and C-SDK now ,so i had to research and test on my own just to understand whats hidden from me , but the results let me just assume that something is more efficient or not .Various circumstances may affect the investigation , it may lead to wrong thesis .
Hey, thank you again!! really useful and valuable information....you stole me the next question i had after reading last message about dynamic GUI (using JSUI or similar tools to create uniform faders and that stuff). I suspected what you said about text objects but i never tested it (because font is needed to render a text, i don't know too what happens when you are using a font that isn't included in other user's library, i think Max should apply some default font type or so, but you were clear enough to me about API resources needed for the render vs SVG files)
Thank you again, because this topic quickly became really really useful...the cherry on the icing would be some Cycling guy explaining what can't be observed easily just watching in front of the drapery