Interpreter doesn't yeld CPU during tight loops

[GoogleCodeExporter]

Some heavy loops cause the browser to freeze. There should be some way for
the interpreter to release execution so that the browser can be responsive
instead of freezing completely.

This happens for example with this code (wave gradient by Ira Greenberg)
that causes the browser to freeze during the 10 seconds or so in which the
drawing is produced:

size(300, 300);
background(300,300,300);
float angle = 0;
float px = 0, py = 0;
float amplitude = 30;
float frequency = 0;
float fillGap = 2.5;
color c;

for (int i =- 75; i < height+75; i++){
  // reset angle to 0, so waves stack properly
  angle = 0;
  // increasing frequency causes more gaps
  frequency+=.006;
  for (float j=0; j < width; j += 0.5)
  {
    py = i+sin(radians(angle))*amplitude;
    angle+=frequency;
    c =  color(abs(py-i)*255/amplitude, 255-abs(py-i)*255/amplitude,
j*(255.0/(width+50)));
    // hack to fill gaps. Raise value of fillGap
    // if you increase frequency
    for (int filler = 0; filler < fillGap; filler++) {
      set(int(j-filler), int(py)-filler, c);
      set(int(j), int(py), c);
      set(int(j+filler), int(py)+filler, c);
    }
  }
} 

Original issue reported on code.google.com by davidedc on 19 Dec 2008 at 11:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

An addendum: although actionscript is single threaded with no yield option, 
there is
a potential workaround done by Alex Harui at
http://blogs.adobe.com/aharui/2008/01/threads_in_actionscript_3.html to enable
simulated threads.

This approach should allow to "break" the interpretation of hard "tight" loops, 
so
that GUI can be
refreshed and hopefully the browser can claim some CPU cycles to behave itself. 
A
couple of demos of the aforementioned threading library show these benefits, so 
it's
worth a try.

The interpreter would need to "break" loops and function calls (because function
calls could be recursive).

Original comment by davidedc on 19 Dec 2008 at 2:54

[GoogleCodeExporter]

Unfortunately, threading the Interpreter would probably be too much of a hack 
to work
properly—it interprets the token chain as a tree, and even if we could break 
out of
this, it would be nigh-on impossible to break back in (unless we linearize the
Interpreter? which could be possible).

Because I'll be scrapping the existing Interpreter and using a byte-code 
generator 
for the next release, I think it wouldn't be worth investing much time in this 
issue.
With any luck, the next release will run at near-native AS3 speeds anyway.

Original comment by timdashryan@gmail.com on 19 Dec 2008 at 11:56

[GoogleCodeExporter]

Original comment by timdashryan@gmail.com on 20 Dec 2008 at 12:04

• Changed state: Accepted