delays in __sig__, a good idea?
Alex Russell <[email protected]> Sat, 28 Feb 2004 13:54:36 -0800
| Newsgroups | gmane.comp.windows.devel.netwindows |
|---|---|
| Organization | netWindows.org |
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey all,
so I've run across several situations with quick firing events which
trigger expensive operations, and one of the things I normally wind
up doing in situations like this is to use setTimeout to create a
delayed exection. Here's the example:
__sig__.connect(domNode, "onresize",
null, "somethingExpensiveWithDelay");
function somethingExpensive(){
// our expensive DOM operation happens here
}
var timerRef = null;
function somethingExpensiveWithDelay(delay){
if(!delay){
delay = 100; // sane for fast firing events
}
if(timerRef){
clearTimeout(timerRef);
}
timerRef = setTimeout(function(){
// could create closure. kinda of expensive.
somethingExpensive();
}, __util__.toInt(delay));
}
There are, of course, lots of useful variations on this basic setup,
but you get the idea. Which brings us back to __sig__. It might be
interesting (although I'm not sure if it's wise) to add another
parameter to connect() that would take a delay and induce this
"pre-emption" (for lack of a better word offhand) scenario.
The upside is that these scenarios would be shortened to something
like:
__sig__.connect(callerObj, "callerFunc",
calleeObj, "calleeFunc",
null, /* no default args, see yesterday's checkin notices */
100 /*or some apprpriate delay */);
OTOH, this would induce slight delay into the call path for every
dispatch since another conditional would be put in the fast-path. It
is assumed that delayed functions will benefit enough from the
short-cut ability to make the additional cost of closures and
conditionals worthwhile. Another argument against this is the obtuse
calling behavior (6 arguments to connect() does seem a bit
long-winded).
Thoughts?
Regards
- --
Alex Russell
[email protected] BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFAQQ4goV0dQ6uSmkYRAoQFAJ9wMYqr0IYm5fgIIK99UM9PFw9jjwCdHckQ
UlpV6dyhpJ/BgBssHx4raLM=
=VLMZ
-----END PGP SIGNATURE-----
_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org