Why should size() call be the first line in setup()?

Lord_of_the_Galaxy

The title says it all.
Most of us here know that size() must be the first call in setup(). @PhiLho also says

... the rule saying that the size() call must be the first one in setup(). For some reason, code before it tends to be run twice, which is annoying when loading a possibly large file.

But why does that occur? Is it because size() internally calls setup() again after setting the size of the sketch, and subsequent calls to size() just skip right through to end?

TfGuy44

Don't question it. Just do it.

But yeah, it's something like that.

Lord_of_the_Galaxy

I have always been doing it, almost like sheep keep following....

But if it is what I thought, then that answers my question.

GoToLoop

Is it because size() internally calls setup() again after setting the size of the sketch, ...

That was the case before Processing 3. And even so, it didn't affect the default renderer: JAVA2D! :-@

Therefore, if we had statements before size() within setup(), and only when not using JAVA2D renderer, we had to worry about whether those statements would crash the sketch if they were re-run. :-SS

For most cases, that'd be innocuous. For example: a file be loaded twice rather than 1. :\">

When I had to at that time, I'd just declare some boolean variable or test a variable for null.

static final String IMAGE_FILE = "some_image.png";
PImage img;

void setup() {
  if (img == null)  img = loadImage(IMAGE_FILE);
  size(img.width, img.height, P3D);
  noLoop();
}

void draw() {
  background(img);
}

As n1 can see in my example above, if img isn't null anymore, it means loadImage() had already happened. :ar!

But even w/o that precaution check, the sketch would work the same, just an annoying double loading. :-\"

And if it was the default JAVA2D, we could get rid of all of those precautions: ;))

static final String IMAGE_FILE = "some_image.png";
PImage img;

void setup() {
  img = loadImage(IMAGE_FILE); // no need for extra precaution here anymore
  size(img.width, img.height); // b/c it's the default renderer JAVA2D now.
  noLoop();
}

void draw() {
  background(img);
}

In short, we should avoid using words like: must, have to, ought to, etc.
B/c in programming, absolute statements can be proven wrong about 99%! :))

Lord_of_the_Galaxy

@GoToLoop So do we need to even worry about it in Processing 3?

GoToLoop

None in P3. And as long it's the default renderer JAVA2D, no glitches for all Processing versions! \m/

But for aesthetically & organizational purposes, we should favor size() as the 1st statement within setup(). :bz

Lord_of_the_Galaxy

OK, thanks!

jeremydouglass

It is also a good habit to always call size() first in order to avoid a very common "gotcha" error -- writing code that defines variables based on width or height in setup and forgetting that those variables are initialized to 100 until they are updated by the size() call. (This is also an error that happens if a sketch uses width or height to define a global variable).

Always keeping size as the first line avoids introducing that category of difficult-to-debug width/height bug into setup later -- especially for newcomers to Processing.

GoToLoop

Always keeping size as the first line avoids introducing that category of difficult-to-debug width/height bug later

As much as possible, as most of the examples I post in this forum for many years already, I place size() as the 1st call within setup().

However, I despise disinformation & censorship being applied to force others to "comply" even to good programming practices. [-(

neilcsmith_net

Given that size() gets moved into settings() and executed before setup() is even called, you can put it wherever the hell you want if you want to confuse yourself. It will always execute before any other code in setup().

Or you could use a real IDE. ;-) I've never understood why these shenanigans are meant to be easier for beginners, but then I learned Java long before touching Processing.

GoToLoop

Well, most Processing programmers don't even know that Processing is merely a Java library! :))

And those shenanigans do make Java easier for beginners! =P~

jeremydouglass

@neilcsmith --

Given that size() gets moved into settings() and executed before setup() is even called you can put it wherever

Good point! That is true in Processing 3 by default. Still, "always put size() first" is simple general advice for both Processing 2 -- where that magic-settings-move is not true -- and for Processing 3 -- where in any sketch choosing to override settings(), e.g. to define smooth(), that magic move does not happen. In that case, you still need to put it first -- although first in settings().

Lord_of_the_Galaxy

Thank you for your answers!

neilcsmith_net

And those shenanigans do make Java easier for beginners!

Processing the API and the tools make it great for beginners, no question. This is something that interests me a lot, even if personally I don't think the tools go far enough (or I wouldn't have built Praxis LIVE :-) )

However, the changes to Java's syntax I'm less sure about - adding a color type that's actually an int that causes confusion and odd bugs, removing the f suffix from floats (don't entirely disagree with doing it, but not like it's done), and primarily moving stuff like size() around so that it doesn't actually execute in the order you've written it and "for some reason" variables don't work.

To me these are minor tweaks - they're not radical enough to really make a difference to beginners, and are otherwise a hindrance - eg. to supporting other API's based on Java 8 syntax that can (if done right) be really intuitive to beginners.

Lord_of_the_Galaxy

@neilcsmith_net You're right, some of the tools help beginners while causing a lot of trouble to anyone trying to use advanced features, while some other features are just a lot of pain. The color problem and the removal of f are both examples of the latter.

And some things like the size() problem are really irritating - we're made to follow stupid rules with no justification. And I can quote @TfGuy44 for it-

Don't question it. Just do it.

GoToLoop

... , removing the f suffix from floats...
... and the removal of f...

PDE's pre-processor doesn't remove f suffixes from fractional literals. It adds it when there's none!

Inside ".pde" tab files, if we wanna force a literal to be double, we've gotta suffix it w/ d. #:-S

It's just the opposite for ".java" tab files: We suffix w/ f to force them to be float. :P

GoToLoop

And you've forgotten to mention that PDE's pre-processor also prefix fields & methods w/ public if there's none there. =P~

There are some Java libraries defaults imports too. L-)

neilcsmith_net

@GoToLoop - note I said the syntax removes the f - the preprocessor obviously adds it back in.

The boilerplate stuff you mention is (mostly) different in that it involves wrapping the code the user has written, not changing it. There are still better ways of doing it in my opinion though - eg. in the editor.

GoToLoop

note I said the syntax removes the f...

I still didn't get it. b-( Maybe you've meant? :-/

note I said the syntax removes the need of f...

• In Java, all fractional literals are of type double.
• But Processing decided to use float for its API instead.
• W/o pre-processor's f suffix auto-insertion, sketches wouldn't compile if we passed fractional literals to Processing's functions. :-&

neilcsmith_net

Yes, but you don't need to make weird syntax changes just to support that - you just use double everywhere. :-)

Lord_of_the_Galaxy

That's what I meant too.

Also note that adding syntax where required only makes it a little confusing for any beginner who also has a small knowledge of Java. In fact, some even get confused to the point that they think Processing is a different programming language altogether.

interstar

None of this resolves my problem though.

I want to load a background image into my sketch. Then set the size of the window according to the size of the image.

Forcing me to do size() first means that I can't do that.

TfGuy44

Unless you are picking an image to use as the background at random (and thus the dimensions are random), you can know how large your image is before you load it.

If you are picking a random image and thus a random size... let us know.

kfrajer

@interstar One way to set the size of the sketch at the beginning isdoing it this way:

PImage img;
void settings(){
  img=loadImage("afile.jpg");
  size(img.width.img.height);
}

void setup(){
   ...
}

void draw(){
   ...
}

On the other hand, dynamic loading will require to use resize().

Kf

quark

I've never understood why these shenanigans are meant to be easier for beginners

Processing was never designed to be a programmers IDE it was designed for non-programmers wishing to experiment with computational graphics/graphical design.

The developers chose Java because it _was _the best solution for cross platform programming and the ability of users to share their sketches on the web with Applets.

They created the Processing IDE so that users could program in Java without having to learn OOP in the same way that many people started with BASIC.