XML Feeds

.

[javascript-dev] BUG: javascript can't handle large pattrstorage clientlist when overdrive is enabled

Adam Murray adamjmurray at gmail.com
Tue Mar 25 00:53:24 MDT 2008


I have a patch with 398 pattr objects in it. It's too big to post, but it's quite easy to create this number of pattrs by using a poly~ inside a poly~. 

I need to do some complicated state management and would like to use javascript. But first I need to make my script aware of all the pattr objects. So I'm sending getclientlist to pattrstorage and routing that to my javascript via [route clientlist]

The problem is, inside the javascript a few clientlist messages randomly arrive AFTER the done message! This prevents me from building the list properly.

I tried this test script:

function anything() {
	if(messagename != "done") {
		post(messagename + "
")		
		count++
	}
	else {
		post("done, count = " + count + "
")
		count = 0
	}
}

The count varies between about 390 and 398. It is very rarely the full 398.

In my max patch I can do something like this and the value is correct every time (and "done" always arrives last if I print out the client list).

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 125 193 14 196617 1;
#P newex 98 164 57 196617 route done;
#P number 97 247 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter;
#X flags 0 0;
#P newobj 97 221 66 196617 counter;
#P button 97 193 15 0;
#P newex 98 137 77 196617 route clientlist;
#P message 98 89 64 196617 getclientlist;
#P newex 98 111 67 196617 pattrstorage;
#X client_rect 0 0 640 240;
#X storage_rect 0 0 640 240;
#P objectname u494000118;
#P connect 7 0 4 2;
#P connect 6 0 7 0;
#P connect 6 1 3 0;
#P connect 2 0 6 0;
#P connect 4 0 5 0;
#P connect 3 0 4 0;
#P connect 1 0 0 0;
#P connect 0 0 2 0;
#P window clipboard copycount 8;

I just noticed this only seems to happen when overdrive is enabled. Unfortunately I need overdrive on or my patch does not work correctly. So... what's going on here? I thought overdrive was supposed to make event timing better? I guess the messages arrive faster than the js can process it so some get deferred by the scheduler.

As I finished describing this problem, I realized a solution:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 75 138 17 196617 js;
#P message 18 81 30 196617 done;
#P newex 18 104 50 196617 deferlow;
#P newex 18 58 57 196617 route done;
#P newex 18 31 77 196617 route clientlist;
#P connect 0 0 1 0;
#P connect 1 0 3 0;
#P connect 3 0 2 0;
#P connect 1 1 4 0;
#P connect 2 0 4 0;
#P window clipboard copycount 5;

If anyone else is making patches with hundreds of pattrs, [deferlow] is your best friend. It has also fixed most of my patch's initialization problems (almost every loadbang is firing before the pattrs are ready). 

But these weird timing issues are getting scary, I don't know what else is going to randomly malfunction. Maybe I need to see if I can avoid overdrive...


--
Adam Murray
compusition.com


More information about the javascript-dev mailing list