EDIT by Phrogz: This appears to be a problem with the framerate of jQuery animation when this particular complex CSS is applied. See the video at the bottom for an example of the problem.
I think is hard to copy and paste the whole code here. So I've create a fiddle for this.
To be honest, CSS is not so important on this (I putted it for have a decent grid). I also removed many functions from my original version, in fact they aren't so important.
The only one that works is by clicking on the buttons + Tracks (which call addTrack()) that adds a new track/line in the grid. Tested on Chrome, IE, and Firefox < 4 version. There isn't much problem. It's really rapid and fluid.
The problem is on Firefox 4 or 5. It's really slow to add the new track/line. It's fast like a turtle.
What the function done is to clone (copy with handler) an element trackOn, which is already written in a hidden field (tracklistOff) and add it (insertAfter) applying a fade effect. (thats means a new line in the grid).
Why this behaviour on Firefox? Too many elements to browse on the DOM I suppose. I need to get rid about this slow attitude... so what can I do?
EDIT
You can hear the difference about Chrome and Firefox (5, last version) on this video. Try to hear/see the difference between clicking on mouse and add new line (with the effect). It's too frozen (also when I try to add more tracks quicly).
Still a problem for me, any suggestion will be appreciate :)
This is not very slow for me. On my computer running Firefox 5 I can add many tracks in less than a second. What performance are you seeing? ("Fast like a turtle" is not a very quantitative measurement. :)
When you have trouble with JavaScript speed, profile it, using the Developer tools for Chrome/Safari/IE or Firebug for Firefox. Here's what I see when I run the profiler on your JSFiddle and click on the +Track button twice:
From this we can see that most of the time is spent in some set function from a mootools library. Since I don't see this library included in your code, I'm assuming the profile is tainted by JSFiddle.
So, we create a standalone test case without the unnecessary CSS and profile that. Now we see this (for several presses of the +Track button):
Almost all of your time is spent in the clone() function.
So what can you do about it? You could try pre-creating the HTML string (in JS) for a template row, and instead of using 'clone' try creating that with:
$(templateString).hide().insertAfter(...).fadeIn(600);
would it be ok if you get just the last element?
something like:
$('.tracklistOff div:last-of-type')
.clone()
.hide()
.insertAfter(($(param).parents('.trackOn')))
.fadeIn(600);
or you could addClass(last) to the last element to get only one
I just tested your fiddle on the following browsers and they all worked well: FireFox 5, Opera, Google Chrome, Safari & IE9.
There were no speed issues but each browser handled the fade slightly differently however everything else seemed to work fine. Not sure what the problem is here. It could be your computer speed but as you're on this site I presume it's decent.
Related
I made a nice website that does a lot of DOM manipulation. Works very nicely in chrome and firefox. Though the client has requested now that it also works in Internet Explorer. The latest version is good enough to start with (that would be 10.0.9200.16721 in my case).
So the adventure starts, i press F12 and see a set of pretty familiar developer tools (coming from chrome and firebug). As i'm tracking the JS code i notice that the HTML tab (with the DOM) doesn't actually update.
According to the manual here http://msdn.microsoft.com/en-us/library/ie/gg589512(v=vs.85).aspx it's "a good idea to refresh the HTML tab to get the current DOM, especially when you use dynamic elements." (d0h ??) problem is .. i can't find a button to enable automatic update of the HTML tab. So i would have to click the refresh button everytime i step into a new line of JS (never mind of real-time DOM view).
But that's not all ... every time i click the refresh button the whole DOM tree view collapses. And i have to click a bunch of pluses to view the node i'm interested in.
Does anyone have a solution for this? Because what would take days will take weeks this way...
Duplicate of How to inspect elements on dynamically created DOM by using IE developers tools
From doing a little digging aroung, it seems like this is an issue other people have reported too. This thread might be of some interest to you.
The most relevant part of it:
The problem is when you modify the dom (with or without jquery) from a callback which is called by a timeout, which is in a callback bound to an event, IE freaks out and doesn't update the dom tree in the development tool. Subsequent modifications to the changed tag in the dev tool won't have any effect.
According to my tests, it's the combination of that sequence of calls that make this happen. If the dom is modified from a settimeout callback but without being inside of an event callback, it works. If instead of settimeout you directly call a function that modifies the dom, it works.
Here's a working example of what you're saying to compound the issue.
Basically, this is an issue with IE. There is no fix available at the moment. The accepted answer on the other thread seems like a very poor workaround.
I have created a little tooltip framework, which works fine in all modern browsers. There's one thing that really bugs me: in Firefox this seems to disable displaying a regular title (from the title attribute).
I can't find a cause for this. It's not the mouseover handler that I assign for certain elements, because on regular (non handled) elements, titles are not displayed either. Furthermore, I experimented with this (see this JSFiddle, and it was not replicable).
Can this be some known Firefox bug (I searched the Internet for that, but I didn't find anything relevant) or am I doing something wrong in my scripting, HTML, or CSS?
I've put the whole thing in this JSFiddle.
[edit april 2022] This is a very old question. Do disregard it.
title is displayed in my Firefox, and Firefox doesn’t have any bug regarding the same. Try updating your Firefox, or maybe some plugin in your browser may be causing the tooltip to hide.
Let's say I have a large number (> 1000) of DIVs on a page. Each has an id in the format of 'div' + [0-n]
If I then iterate through them and call:
document.getElementById('div'+i).style.display = 'none';
It works extremely efficiently. With 2.5k+ divs, they all disappear almost immediately.
However, if I then iterate through them and call:
document.getElementById('div'+i).style.display = '';
Understandably, it's slower. These items need to be redrawn and placed.
In Explorer 9, and Firefox 9, it works perfectly.
In Chrome 15.0.874.121 it slows down horribly. It works fine up to a around 500 divs, and then essentially breaks.
Does anyone know why this would be the case?
Also, does setting display to 'block' one at a time impact performance? Or is the redrawing done once the JS has completed? (I'm guessing this might be the difference between the browsers). If so, how do I change the display property en-mass?
Regards,
Daz.
You could try adding a setTimeout to consecutive calls to allow the browser to repaint in between and not lock up the entire window. Do them in batches because setTimeout does add a considerable delay: ~10ms per call.
In general it's impossible to control what a browser does. What works in one browser may not work at all in another. In general pick the most simple solution and pray it will be fixed in a successive version.
This does beg the question. Why do you have so many divs on one page? Couldn't you just put them all in one div and show/hide that?
Firstly, thanks to #FritsvanCampen and #Walkerneo. Their suggestions led me to try the following...
Before hiding each element using:
document.getElementById('div'+i).style.display = '';
I do as #Walkerneo suggested and hide the parent div. I then do as #FritsvanCampen suggested, and use a setTimeout before doing anything else. The code is as follows:
document.getElementById('PARENT').style.display = 'none';
setTimeout("showAllTheDivs()",1);
Hence, the problem browser (chrome), will no longer try to place the divs one at a time.
This seems like a bug, as it's not apparent in Explorer or Firefox, however, this workaround seems to work. I would be interested to hear whether people think I'd encouter problems with a timeout of 1ms. Seems good enough for now though!
Thanks again to #FritsvanCampen and #Walkerneo.
I have created a Drupal website that uses Openlayers to display maps. In one of these maps there are some "Filters" which the user can use to dynamically change the data shown in the map. The data are related to countries are shown as bubbles over the countries. The bubbles are drawn using Openlayers' API. A good amount of calculations go behind the scene while filters are selected. I have used setTimeout to avoid long running loops. The filters work fine. However, after a number of filters are clicked (e.g. if 12 filters are clicked), if the user tries to move to another page by clicking a link, in IE7 and IE8 the following error shows -
"Stop running this script?
A script on this page is causing your web browser to run slowly.
If it continues to run, your computer might become unresponsive."
This error does not show in any other browser and does not show in IE7, 8 until a link is clicked. Any pointer in this regard will be highly appreciated.
UPDATE : The problem was in OpenLayers' event cache. OpenLayers's clears the event cache in the window unload event and this was getting stuck in IE7 and IE8 (I am not sure why). So far I have been able to solve the issue when user clicks another link, by calling OpenLayers.Event.unloadCache() on click of normal links.
jQuery can be very resource expensive. The articles linked bellow gives you 10 good advices to perform better your jQuery applications. The most useful for me (I had the same problem a month ago) was to replace $.each() with traditional for lops and to replace extensive DOM construction with jquery templates. Also the use of ID instead of classes and to give a context for the selectors, selector caching, and so on.
This list is ordered using my own criteria of "usefulness" in the advices.
10 ways to instantly increase your jquery performance
improve your jquery 25 excellent tips
10 advanced jquery performance tuning tips from paul irish
8 jquery performance tips
You need to optimize your client script. Please refer to answers here.
I just found out about ie7-js ;
IE7 is a JavaScript library to make
Microsoft Internet Explorer behave
like a standards-compliant browser. It
fixes many HTML and CSS issues and
makes transparent PNG work correctly
under IE5 and IE6.
http://code.google.com/p/ie7-js/
It looks like it's really good, but is it really working (the current issue list looks quite scary)? Have you already worked using this with success?
Another question is how slow the script will make the website in IE ?
In static pages it works pretty well. If you designed a couple of static html pages using modern browsers and standards and want it to be shown correctly in IE6 and 7 this script is gonna help you.
But, and it's a big but, if you add a little javascript to the recipe, this method shows its weaknesses. Anything added later to them DOM or any event triggered afterwards will NOT be affected by this script.
That's it. my one line recommendation is if you have simple and light pages use it. otherwise try solve your problems by looking at the roots!
I think the best answer is: try it on your website and see if it works for your particular code. If it works, and doesn't impact the speed, great, you're done. If it doesn't work, then you're going to have to spend the time to make your site work in IE.