phiol

something I've been wondering for a while. 

In regards to using the [panel] to facilitate UIs,

How much is too much before the behavior is affected. 

The scheduler has to redraw each [panel] everytime. So basically behavior accuracy decreases. right.

Over time I have gotten into the habit of using UI objects a least as possible.

Again, when I get into really big patches I want to save on CPU scheduler etc... as much as possible . So how demanding is the [panel] object.

Should I try avoiding them as I have w. other UI.

something I've been wondering for a while. 
In regards to using the [panel] to facilitate UIs,

How much is too much before the behavior is affected. 
The scheduler has to redraw each [panel] everytime. So basically behavior accuracy decreases. right. 

 Over time I have gotten into the habit of using UI objects a least as possible. 

Again, when I get into really big patches I want to save on CPU scheduler etc... as much as possible . So how demanding is the [panel] object. 

Should I try avoiding them as I have w. other UI. 

simple-panel-question

you are not saying what you are doing, i assume you change the

the main CPU hog here is probably not only the panel drawing 

itself, but the other parts of your patches - for example the

use of messageboxes (bad!) or numberboxes (bad!) to store 

i dont know offhand if [lcd] or a pictureslider would be more 

you are not saying what you are doing, i assume you change the
color of [panel] and/or resize it.

the main CPU hog here is probably not only the panel drawing 
itself, but the other parts of your patches - for example the
use of messageboxes (bad!) or numberboxes (bad!) to store 
values for you panel.

i dont know offhand if [lcd] or a pictureslider would be more 
efficient as i dont know your patch.


>>you are not saying what you are doing, i assume you change the

It is not for a specific patch, just every patch in general.

In my patches, I use it as a light square colored shade behind patch module that have a specific function.

But as you said, UIs take away the juice and since my patches do quite a lot I want to use as little UI objects as possible.

So yesterday while building a patch , I was wondering how heavy panels were.

Does color change anything on CPU? I mean for the computer it's just values. White 1. 1. 1. Black 0. 0. 0.

But the fact that it has something more to draw every cycle,

>>you are not saying what you are doing, i assume you change the
color of [panel] and/or resize it.

It is not for a specific patch, just every patch in general. 

In my patches, I use it as a light square colored shade  behind patch module that have a specific function. 

But as you said, UIs take away the juice and since my patches do quite a lot I want to use as little UI objects as possible. 

So yesterday while building a patch , I was wondering how heavy panels were. 

Does color change anything on CPU? I mean for the computer it's just values. White 1. 1. 1.  Black 0. 0. 0. 

That's all I wanted to know and thanks for the link

phil hughes wrote on Mon, 10 August 2009 19:43

thats true, but in max many things - [panel] for example - 

have to be calculated by the CPU, an not by the graphics 

card, like in some jitteer objects or your favorite ego shooter.

so in fact the computer has to handle "1. 1. 1." for every pixel, 

in a panel of 1000*1000 pixels that makes a million times 

"1. 1. 1." - around 10 mb of data have to be written to a 

register and then read again in order to send them to the 

in some situations things only have to be calculated when 

they are "seen", in some situations things run completely 

on the graphics card. but for [panel] you can be sure your 

and while it is busy with sending "1." to panel via numberbox 

and messagebox no other process (like playing a note in max,

but also like displaying html in safari) can be done.

phil hughes wrote on Mon, 10 August 2009 19:43
Does color change anything on CPU? I mean for the computer it's just values. White 1. 1. 1.  Black 0. 0. 0. 

thats true, but in max many things - [panel] for example - 
have to be calculated by the CPU, an not by the graphics 
card, like in some jitteer objects or your favorite ego shooter.

so in fact the computer has to handle "1. 1. 1." for every pixel, 
in a panel of 1000*1000 pixels that makes a million times 
"1. 1. 1." - around 10 mb of data have to be written to a 
register and then read again in order to send them to the 
video card.

in some situations things only have to be calculated when 
they are "seen", in some situations things run completely 
on the graphics card. but for [panel] you can be sure your 
PC have to handle each byte of it.
and while it is busy with sending "1." to panel via numberbox 
and messagebox no other process (like playing a note in max,
but also like displaying html in safari) can be done.

If I understand what your saying correctly, then there is no difference between black and white. The computer has to write value.

Again, i only use these for background purposes.

If I understand what your saying correctly, then there is no difference between black and white. The computer has to write value. 

Again, i only use these for background purposes. 

As stated before, I wouldn't worry too much with static panels, really (even though I would instead use [bgcolor] for that matter).

Hi Phil.
As stated before, I wouldn't worry too much with static panels, really (even though I would instead use [bgcolor] for that matter).

what is wrong with using messages to store values?

simple [panel] question