Basvlk

I've tried to avoid UI objects as much as possible since I started patching -expecting my patches to grow to a point where I'm pushing performance limits at some stage.

But I'm creating a lot of subpatchers and abstractions that need options to be set, and it would be great if they could have userinterface elements which may be made visible (by using bpatcher) or hidden when they are pre-set with arguments.

My question is: when a UI object is hidden in an abstraction, is it still costing more CPU time than a non-UI object?

is it different whether it is a subpatcher or an abstraction/

I've tried to avoid UI objects as much as possible since I started patching -expecting my patches to grow to a point where I'm pushing performance limits at some stage. 

My question is: when a UI object is hidden in an abstraction, is it still costing more CPU time than a non-UI object?
is it different whether it is a subpatcher or an abstraction/

ui-objects-and-efficient-coding

In most GUI environment, a graphical object is sent an event when it should redraw itself. This will happen when the visibility of the object change to "show", or if it was partially covered and then uncovered. If the visible aspects of the object itself are changed programmatically, then it will be "invalidated" which will then cause a redraw event to be triggered. However, that redraw should not happen while the object is not visible. If max objects behave this way, then there should be little or no impact on the system when the objects are hidden.

The other factor that affects this is when the work gets done so that the object knows what has to be drawn. If update data is just stored when it changes and the calculations for redrawing don't happen until the object actually redraws itself, then the impact of hidden GUI objects should be negligible.

In most GUI environment, a graphical object is sent an event when it should redraw itself. This will happen when the visibility of the object change to "show", or if it was partially covered and then uncovered. If the visible aspects of the object itself are changed programmatically, then it will be "invalidated" which will then cause a redraw event to be triggered. However, that redraw should not happen while the object is not visible. If max objects behave this way, then there should be little or no impact on the system when the objects are hidden.
The other factor that affects this is when the work gets done so that the object knows what has to be drawn. If update data is just stored when it changes and the calculations for redrawing don't happen until the object actually redraws itself, then the impact of hidden GUI objects should be negligible.


Thanks dhjdhjdhj, I think you are saying 'it shouldn't matter al long as the UI object is not in any open window' right?

IF they implemented UI objects this way THEN it shouldn't matter.

Turn on the metro and look at CPU use in Task Manager or Activity Monitor with the patch below.

Nuff said! Thanks Andrew, that is superclear.

by the way Andrew, is there no way to have a look at Max's non audio object cpu utilization from within MaxMSP ? If not, is there a specific reason as to why ?

UI objects and efficient coding