If you're looking at a tab, all content on the other tabs ('below' the current one) is invisible. But an animated image migth still be active, and influence the page which lays on the top. In this example, it steals cpu-time, which causes flickering in a quicktime-movie. - open a single window wihtout any tabs (close all other windows and tabs) - go to http://www.thinksecret.com/ : that often contains an animated image more or less in the center of the window (between the header and the news content). Reload a few times if necessary. - open a new tab, and go to http://www.apple.com/hardware/ads/idvd_elope.html in that tab - this is a static image, but it's displayed by the QuickTime plugin. - if the animated image on the previous tab is still looping, you will see a lof of flickering in the image. When the movie is playing it's ofcourse worse. Don't dismisss this as a problem with the QuickTime plugin. That might not be very optimized for a lot of reasons, but the real problem here is the animated image. When a page is completely covered by something else, it shouldn't be consuming any cpu-time at all. I know that optmizing can be very difficult (like only updating the visible parts of a window), but this one should be easy. Tabs which are not the front tab, are by definition invisible, and should spend as little time as possible in all kinds of timer loops (animated images, plugins, JavaScript-timers, ...). The ideal should be that the entire page is frozen, but I don't know if that's possible (JavaScript timers should still function for instance). PS: isn't there already code that does this for 'iconified' ('hidden', 'minimized') windows ?

I imagine background Mozilla browser tabs are treated much like background Mozilla browser windows. I'm sure that whatever means is used to apportion CPU time is the same in both instances, since both may house content that is hidden.

To clarify, there are 2 sides to this bug : - a background tab has no access to the display at all. This was the cause of the flickering, since the animated image caused part of the display to be invalidated, so the quicktime-plugin tried to refresh. - if possible, a background tab should be more or less frozen, animated images shouldn't loop, plugins shouldn't refresh, etc ... The same thing as we would expect for a hidden or minimized window, although I'm not sure if this is actually the case. It won't be a good idea to block everything (a movie should keep playing for instance), we can at least short-circuit the animation part, sicne the window will get a refresh anyway. The plugin should also be optimized for that (a QuickTime player on OS X will consume much less cpu when minimized to the Dock for instance).

Build 2001102411, MacOS 9.2.1 easier test-case : - open resource:///res/samples/test7.html (example 7 from the viewer demos) - open a new tab and go to http://www.apple.com That has currently a large movie (wiht the iPod) and several other graphic buttons While tab 1 (the eyes) is in the background, tab 2 (the apple page) will flicker constantly. When another page (about:blank) is loaded in tab 1, this will stop.

We probably need to add this capability to window, e.g., window.halt/resumeActivity() or some such, so that plugins, timeouts, and animations can all be suspended and resumed.

suspend, not halt (Turing says; antonym to resume in all threading parlance, too). Can we put these on some object other than window? /be

yuck. the reason i like tabbed browser (and more so in some future build) is that pages can load in the background. i don't see why this belongs to window, i'd think it should be in <browser/>

I don't think we should suspend - JavaScript timers will still have to run (auto-reload for instance), plugins will still have to play their movies, etc... The only thing important is that there's no display available, so we could take shortcuts where necessary. The code is probably already doing that, but what I showed here was that an animated image was invalidating its part of the display (without actually displaying something), which caused a reaction in a plugin which was laying on top, in another tab. Since it was a plugin of a movie (even though it was really a static image in the first example), you could see a large flickering in that movie. I haven't seen the same behaviour with images, probably because their data is cached better. But the plugin was flickering, because part of its displsy was constantly being invalidated. I'll try to see if this happens on my PC at work too, with different plugins.

Reassigning to new component owner.

Pavlov, can the image animation code be optimized for this case?

*** This bug has been marked as a duplicate of 120154 ***

verifying