Add back the "loading" image to the Overlay in a way that does not kill performance

Here is my original comment on how to add back the throbber:

To fix this we need to dynamically add a class to the overlay container when the iframe is loaded.

From
<div id="overlay-container" class="ui-dialog-content ui-widget-content" [...]>

To
<div id="overlay-container" class="ui-dialog-content ui-widget-content loaded" [...]>

Once the "loaded" class is added in the "overlay-container", we could then override the loading image properly through CSS.

.overlay #overlay-container.loaded {background-image: none;}

I guess we need a jQuery pro here to add the "loaded" class when the page have finished loading.

We could then reapply the original loading line. ;-)

Slight variation on the way xmacinfo describes it, but not that much :).

Great! I'll test it with the same environment I used to test out the old "loading" image performance. :-)

@Kiphaas7: Thank you. Now we can have back the "loading" image and not cause performance issue by letting it run in the background.

I tried this patch and commented the

.overlay-loaded #overlay-container {

line and my CPU jumped to 50% usage with Firefox. And using this patch as is, the CPU spiked at loading page and resumed at 5%. Which is expected on my old computer. I also checked for the loading image with Firebug to see if the image was still active, which is not.

This patch properly disable the "loading" image when the iframe is loaded. So I mark this as RTBC.

Please note that other performance issues with the overlay must have their own issues.

+1 to both the patch and the approach. When I tested it, I got the same results as xmacinfo. I think this is ready to go back in.

Great work! Committed to HEAD.