106125 - Background tabs should occupy the CPU less

Status: VERIFIED DUPLICATE of bug 120154

(SeaMonkey :: Tabbed Browser, defect)

Description

[Jo Hermans]

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 ?

Comment 1

[Greg K.]

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.

Comment 2

[Jo Hermans]

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). 

Comment 3

[Jo Hermans]

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.

Comment 4

[David Hyatt]

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.

Comment 5

[Brendan Eich [:brendan]]

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

/be

Comment 6

[timeless]

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/>

Comment 7

[Jo Hermans]

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.

Comment 8

[David Hyatt]

Reassigning to new component owner.

Comment 9

[jag (Peter Annema)]

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

Comment 10

[Jo Hermans]

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

Comment 11

[Sebastian Späth]

verifying