Processing 1.0 - Processing Discourse - applet loading in browsers

ZakG

applet loading in browsers
May 28^th, 2010, 11:51pm

I have asked several questions in here already pertaining to my Degree Project -- http://www.oracloud.net, which is now finished (yay!). I'm really eager to spread the word and allow the project to be in "beta," but there's one issue in particular I want to address.

I'm using millis() to show a title for the first 5 seconds. Then, between 5 and 9 seconds, I'm animating the position of an image that serves as an info button. It starts off in the center of the screen under the title, then moves to the bottom right corner. I wanted to draw attention to it in the beginning, but let the "cloud" become the focal point. What seems to be happening is you'll see the animation if you reload and the applet is already cached, but otherwise it just moves past it and you miss the whole thing, or most of it. I wondered if setup() was taking a long time, and had my millis() variable (m) add a variable called setupTime, which measures how long it takes for setup() to run. Yet this always ends up being around 70 ms, so clearly what's happening is setup() has run but the applet does not show up until well after draw() has started running.

I was looking a lot at http://wefeelfine.org during the course of this project, and he seems to be able to circumvent this problem somehow. When you first load the applet it displays the text "Looking for feelings...," and when finished, the balls eminate from the center of the screen. I suppose he could have achieved this by just making the "Looking" screen excessively long. I could go that route. But if anyone can shed some light on why this is happening I'd be really pleased to know.

Also, in Firefox Mac there are some other weird problems. One is the screen starts off black and then turns white before the applet loads. The <object> has a background-color param set to black, and the CSS defines a black background-color as well. I even used <body bgcolor> just to cover all my bases.

Here is the code: http://oracloud.net/sketch14.pde

ben_hem

Re: applet loading in browsers
Reply #1 - May 29^th, 2010, 3:24pm

setup() doesn't render anything until the first draw call. One way to have a loading screen is to move all your setup stuff to draw(). It needs to run just once, so you could have a "loading" boolean that starts out true, and set it to false once you've finished setting everything up. If you have a static loading screen, it can be substituted for the default "loading.gif" (and should be the same size as your applet). This will display on most systems until the first draw() call, at which point you could display the same screen seamlessly (if (loading) image(loading.gif,0,0)). For a progress bar, you could use an integer between 0 and 100 to represent the % of load completion, and draw a rectangle to size each frame. The integer would be incremented in your load section, which would need to function incrementally (not all in one frame) or in a separate thread. Incrementing it within draw() is easier -- it just entails making loop counters into global vars.

ZakG YaBB Newbies Offline Posts: 16	Re: applet loading in browsers Reply #2 - May 30^th, 2010, 1:00pm Yes, but as I said the time it takes setup() to complete is not the issue here. My intro animation is all within draw(), and often the applet skips it.

blindfish

Re: applet loading in browsers
Reply #3 - May 30^th, 2010, 1:53pm

ZakG wrote on May 30^th, 2010, 1:00pm:

Yes, but as I said the time it takes setup() to complete is not the issue here. My intro animation is all within draw(), and often the applet skips it.

Quote:

I wondered if setup() was taking a long time, and had my millis() variable (m) add a variable called setupTime, which measures how long it takes for setup() to run. Yet this always ends up being around 70 ms, so clearly what's happening is setup() has run but the applet does not show up until well after draw() has started running.

When does it take 70ms When you test it locally or online Looking at your source you assign "m = millis();" before a bunch of loadImage() calls. It's not inconceivable that when you test locally, when presumably the images are being loaded from a local source, this happens very quickly; but that when the images are being loaded online it takes much longer...

Have you tried just assigning "setupTime = millis();" at the end of setup and seeing how it behaves online Alternatively you could use a boolean to assign millis() to setupTime at the beginning of draw when it is first run... i.e.:

Code:

void draw() {
  if(firstRun) {
    setupTime = millis(); 
    firstRun = false;
  }
  // your code here...
}

On an unrelated note. I notice you declare and assign a bunch of variables at the beginning of draw. This isn't particularly efficient as they appear to be constants based on width/height. You should declare the variables before setup, to make them global, and then assign the values from within setup:

Code:

float smscale = 0.10;

  float smwidth;
  float smheight;
  int transposX;
  int transposY;

void setup() {
  // fit <object> to size of browser window
  int w = int(param("width")); 
  // int() will return 0 if param("width") doesn't exist
  if (w <= 0)
    w = 960;
 
  int h = int(param("height"));
  if (h <= 0)
  h = 720;

  size(w, h); // BTW this looks a little suspect to me - certainly goes against the advice that size() should ALWAYS be the first call in setup()...

  // Anyway, now width/height are defined you can assign the values to these variables
  smwidth = width*smscale;
  smheight = height*smscale;
  transposX = round(width);
  transposY = round((height-navheight + navheight/6) / smscale);
}

Where is the what if the what is in why?

ZakG YaBB Newbies Offline Posts: 16	Re: applet loading in browsers Reply #4 - May 31^st, 2010, 9:02am The 70 ms was from testing locally, but the images are loading from the web, since I specified URLs. The applet takes up 100% of the browser window. The variables based on height and width change on draw so a user can resize the window.

blindfish

Re: applet loading in browsers
Reply #5 - May 31^st, 2010, 3:27pm

Well I just ran your code locally from within Processing (with hard-coded size). If I leave the code unchanged your title appears for a more or less random amount of time (or not at all) and doesn't fade as you want.

If I put setupTime = millis() at the end of setup I get a consitent result: title appears for a consistent amount of time, then fades out. Did you even bother to test the suggested solution? I.e.:

Quote:

Have you tried just assigning "setupTime = millis();" at the end of setup and seeing how it behaves online?

Or did you base your 70ms figure on a single test that just happened to go right? On my machine it's averaging around 2200ms...

Point taken on the resize variables...

Where is the what if the what is in why?

blindfish

Re: applet loading in browsers
Reply #6 - Jun 1^st, 2010, 1:33am

blindfish wrote on May 31^st, 2010, 3:27pm:

Point taken on the resize variables...

Actually I think my point still stands as regards declaring them each frame. That may create a slight processing overhead; though admittedly this is probably imperceptible. Still, there's no reason not to declare them globally and just assign the values each frame. And in an ideal world you'd have an event that triggers when the window is resized and then assigns the values only when necessary...

Where is the what if the what is in why?

PhiLho

Re: applet loading in browsers
Reply #7 - Jun 1^st, 2010, 2:04am

A little remark: blindfish, you are not wrong, but don't forget the saying about premature optimization...
As you guessed, the impact of computing these on each frame is minimal, and even if there might be better solutions in terms of theoretical computing science, it is OK here.
Likewise, the late size() is understandable as the size of the applet is determined by the browser itself, because it is defined in the HTML as a percentage of the browser display area.
Just to be aware that code before setup() can be run twice, for some reason...

To the issue, I ran the applet (in Firefox/WinXP), and briefly saw the title, even less on reloads... Not sure what is the problem if the title shows correctly on desktop.
Actually, I am not sure how the 'state' variable is changed. Apparently it changes only on mouse click.
Are you sure the drawing you do after drawing the title (checknav, infodraw...) doesn't overwrite the title? (shooting in the dark by simple look at the source) Again, not sure why there would be a difference between desktop and browser (beside potentially a slower loading of images/data).

blindfish

Re: applet loading in browsers
Reply #8 - Jun 1^st, 2010, 6:48am

PhiLho - points taken on premature optimisation. I guess it's just that I'd normally try and avoid that sort of thing as I don't particularly enjoy going over code to optimise after the fact...

PhiLho wrote on Jun 1^st, 2010, 2:04am:

Not sure what is the problem if the title shows correctly on desktop.

As I said before - setting the 'setupTime' after all the loadImage calls have completed in setup resolves the issue when tested on the desktop; as I suspected it would. But I don't get the impression that Mr Greene bothered to actually test my suggestion...

I also just noticed that the 70ms quoted is actually the time setup actually launched; NOT the length of time it took to run:

Code:

void setup() {
  // <snip />

  // record time since program started
  m = millis();
  
  // <snip>lots of stuff including several loadImage calls... </snip>

  // how long setup() took
  setupTime = m;
  println(setupTime);

Instead try:

Code:

void setup() {
  // <snip />

  // record time since program started
  m = millis();
  
  // <snip>lots of stuff including several loadImage calls... </snip>

  setupTime = millis();
  // how long setup() took
  println(setupTime-m);

Where is the what if the what is in why?

ZakG

Re: applet loading in browsers
Reply #9 - Jun 1^st, 2010, 7:10pm

blindfish - I didn't test your solution because I didn't understand how what you were suggesting was any different than what I had. What you suggested was exactly what I meant to do, but for some reason it didn't occur to me that I wasn't updating the variable m where I should have, at the end of setup(). I hadn't intended to write off your advice -- thank you for pointing out my error! This seemed to solve the problem.