Bug 237118 – live.com uses a lot of CPU whenever the window loses / gains focus

• Component: Layout and Rendering
• Status: ASSIGNED

[Chris Dumez]

live.com uses a lot of CPU whenever the window loses / gains focus.

[Chris Dumez]

Created attachment 453038 [details]
Patch

[Simon Fraser (smfr)]

I'm concerned that we're optimizing for a one-time paint on window activation/deactivation as opposed to a continual 10% background CPU usage, which we saw on some pages when fixing bug 167997.

[Chris Dumez]

(In reply to Simon Fraser (smfr) from comment #2)
> I'm concerned that we're optimizing for a one-time paint on window
> activation/deactivation as opposed to a continual 10% background CPU usage,
> which we saw on some pages when fixing bug 167997.

I agree it is not ideal.

My thinking was that focusing / unfocusing windows is a lot more common than this corner case where:
1. The Safari window is only partially visible
2. The part that is visible is being repainted BUT doesn't visually changes due to large tiles
3. The page is using a lot of CPU due to timers

I think ideally, we'd make it a lot cheaper to repaint this page. However, this is not something I know how to do, which is why I proposed this as a mitigation.

[Geoffrey Garen]

What if we make the tile size smaller if and only if we are a foreground tab in a non-foreground window and we find ourselves (re-)painting frequently? -- at first glance, that would seem to be the best of both worlds.

[Simon Fraser (smfr)]

Rather than complicate the tiling logic, I'd prefer to just minimize the cost of the blur.

[Geoffrey Garen]

(In reply to Simon Fraser (smfr) from comment #5)
> Rather than complicate the tiling logic, I'd prefer to just minimize the
> cost of the blur.

Do we have a way to do that?

[Simon Fraser (smfr)]

Options:
1. in this particular case only blur the non-clipped part of the content
2. get CoreImage filters working
3. make the blurred element a compositing layer, in which case we'll let CA do the blur (but with possible knock-on effects triggering more compositing layers)

[Geoffrey Garen]

Are we sure that a clipped blur is the only case where we expect painting to be expensive?

[Simon Fraser (smfr)]

Blurs in general are expensive to compute, which we do at paint time (when not composited). Other things are too, but non-composited filters are one of the more common causes of expensive painting.

[Radar WebKit Bug Importer]

<rdar://problem/89717354>

[Brent Fulgham]

This appears to actually be tracked by:
rdar://89029702