3 ms·
As per the IE performance... I usually feel the inclination to dig deeper and figure out what the cause is, but not this time. It only reared its head because
by sam_in_nyc 18y ago
As per the IE performance... I usually feel the inclination to dig deeper and figure out what the cause is, but not this time. It only reared its head because it was on mousemove, which obviously gets fired a lot. I have a hunch it's in computing the source element in certain cases, like floats or absolutely positioned things.
To get around this, I use my own event normalization that seems to work across all browsers and only normalizes what I need in any given project, for example:
var e = e || window.event;
var fixed_e = {};
fixed_e.pageX = document.all ? e.clientX + truebody.scrollLeft : e.pageX;
fixed_e.pageY = document.all ? e.clientY + truebody.scrollTop : e.pageY;
fixed_e.X = (e.offsetX ? e.offsetX : e.layerX) || 0;
fixed_e.Y = (e.offsetY ? e.offsetY : e.layerY) || 0;
fixed_e.source = e.target ? e.target : e.srcElement;
Another problem with jQuery events is unbinding is tricky.. I don't like how I have to have a reference to the bound function laying around somewhere so that I can unbind it. In my event system, adding an event returns a handle, which allows you to simple call ".detach()" or ".attach()" or ".trigger()" .. it's worked out very well for me.
As per the remove, I added a simple extension that's worked perfectly:
$.fn.rm = function(){
return this.each(
function(){
if (!this.parentNode) return; //already removed.
this.parentNode.removeChild(this);
}
);
}
- jeresig 18y agoYou can take a look at the event fixing code here: http://dev.jquery.com/browser/trunk/jquery/src/event.js#L285 http://dev.jquery.com/browser/trunk/jquery/src/event.js#L285 There's really not much to it - and it's really not much different from the code that you show above. A lot has changed since 1.3 so if you're still having problems, perhaps its not here and with some other aspect of the event handling code. Any more input would definitely be appreciated. "I don't like how I have to have a reference to the bound function laying around somewhere so that I can unbind it." Here are a couple ways to unbind an event handler without needing the original function. $("div").bind("click", function(){}); // Unbind all bound events $("div").unbind(); // Unbind all click events $("div").unbind("click"); $("div").bind("click.tmp", function(){}); // Unbind all click events with the name 'tmp' $("div").unbind("click.tmp"); The last one is probably what you want.
- sam_in_nyc 18y agoSometime today I'll try to reproduce the conditions. It was definitely event fixing (or something in jQuery) that did it, because even if I cleared out the mousemove function, it would still be laggy. But if I didn't bind it, the lag would go away. You're right, the event namespacing was exactly what I was looking for. BTW, is there a list of "reserved" words in jQuery? For example, jQuery has to store this information somewhere... possibly it gets attached to the DOM element itself. Where does ".data()" live? I often directly access the DOM elements, and want to be sure I don't interfere with jQuery.
- sam_in_nyc 18y agoUpdate: I don't see myself having time to set-up a situation where IE lags... I've got so much stuff on my plate -- trying to launch in a week. Sorry John!
- jeresig 18y agoWe maintain all of the element data (including events, etc.) in an internal data store. We attach a single expando to an element - whose name is randomly generated (this allows jQuery to, not only, co-exist with other libraries but also to coexist with other copies of jQuery, since there'll never be a collision with the name). I hope this helps to clear it up.