714058 - Stop painting if browser window completely or partially covered

Status: RESOLVED DUPLICATE of bug 1688997

(Core :: Graphics, defect)

Description

[Phoenix]

Now, if there are a couple of windows with animated images, they consume resources even if window is covered by some other window and user can not see images. I suppose, it worth adding visibility check and "do not draw" if covered.
Explanations, how to do this under Windows, are in this two blog posts
http://blogs.msdn.com/b/oldnewthing/archive/2003/08/29/54728.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2003/09/02/54758.aspx
Also, I suppose, flash drawing may discarded in same way too. If I choose wrong component, please, move bug to appropriate section.

Comment 1

[j.j.]

Isn't this covered by bug 666446? (fixed in Fx11)

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to j.j. from comment #1)
> Isn't this covered by bug 666446? (fixed in Fx11)

Not really (depending on what you mean by "this"). bug 666446 doesn't in any way prevent us from animating images in the foreground tab of covered-up windows. It does coalesce their invalidations, so that multiple animated images in such a window would get repainted simultaneously which saves on resources.  It didn't add any logic for "is this window visible", though, which is what Phoenix seems to be requesting.

Also: I don't think this is really be an animated-image-specific thing. As noted at the end of comment 0 -- if this were useful for animated images, then it'd also be useful for flash (and also for canvas / SVG animation / CSS transitions / anything else requiring frequent repaints).

  --> Genericizing summary a bit, and moving to Core|General

Comment 3

[Daniel Holbert [:dholbert]]

I suspect this may already be handled by the OS somewhat (or if it isn't, it definitely could be).  IIRC, we never proactively paint right now -- we just post invalidations to the OS, and then we wait for *it* to send us a callback (and only then do we paint).

So I'd expect the OS to have some intelligence for "Ok, you invalidated this area -- but I know that another program is covering up that area -- so I won't bother telling you to repaint it yet."  I'm not sure it's worth trying to build that intelligence into Gecko.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> I'm not sure it's worth trying to build that intelligence into Gecko.

so this is wontifx?  or have things evolved to moderate this position?

Comment 5

[Daniel Holbert [:dholbert]]

Kicking needinfo to someone who's better-able to answer that.

Bas, do you know if there's anything useful we can do along these lines? (tl;dr the bug reporter was seeing CPU usage from animations in Firefox, even when the animations were covered up by another window.  Is there anything we can reasonably do to improve there?)

(I'm not sure if there is, as I noted in comment 3.)

Comment 6

[Bas Schouten (:bas.schouten)]

The widget folks and RefreshDriver folks would be in a better position to answer this. Even with OMTC we only paint when the composition thread is being told to paint I believe. So from a graphics perspective I don't think there's much work to be done here. Maybe Avi knows?

Comment 7

[Avi Halachmi (:avih)]

I asked mattwoodrow and benwa, they both think the GPU will indeed render regardless of OS invalidation rects, especially with OMTC.