Good stuff, Matt. Thanks for sharing it. I think adding an option is
a good idea.
Mike
On Nov 12, 2007 12:32 PM, Matt Kruse <[EMAIL PROTECTED]> wrote:
>
> I just spent a while tracking this down, so I thought I would post it
> here in case anyone is searching the archives in the future.
>
> I use blockUI to block containers while they are getting loaded via
> ajax. I found that in many cases, the call to block was going very
> slow - sometimes taking 5 seconds just to put up the block message!
>
> What I traced it down to is blockUI attaching events to every <a> and
> <input> within the blocked element. In my case, I had a tree structure
> with hundreds or thousands of nodes, each with an anchor in them. The
> binding of 5 events to every element caused the unbearable lag.
>
> My application is an internal webapp, and I didn't need this
> functionality. So I made the change below in the page where it was a
> problem and now the interface responds much quicker. I would recommend
> making this an option in blockUI, perhaps documenting it as a caveat,
> or maybe even consider not doing this kind of action by default.
>
> // Matt - 2007-11-12
> // The "bind" call in BlockUI is extremely inefficient when there are
> large numbers of anchors or inputs within the
> // blocked element. We're going to over-write it here because we don't
> even care about the functionality it is
> // trying to add.
> // bind/unbind the handler
> $.blockUI.impl.bind = function(b, el) {
> var full = el == window;
> // don't bother unbinding if there is nothing to unbind
> if (!b && (full && !this.pageBlock || !full && !el.$blocked))
> return;
> if (!full) el.$blocked = b;
> // var $e = full ? $() : $(el).find('a,:input');
> // $.each(['mousedown','mouseup','keydown','keypress','click'],
> function(i,o) {
> // $e[b?'bind':'unbind'](o, $.blockUI.impl.handler);
> // });
> }
>
>
> Matt Kruse
>
>
