live.com uses a lot of CPU whenever the window loses / gains focus.
Created attachment 453038 [details] Patch
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.
(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.
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.
Rather than complicate the tiling logic, I'd prefer to just minimize the cost of the blur.
(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?
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)
Are we sure that a clipped blur is the only case where we expect painting to be expensive?
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.
<rdar://problem/89717354>
This appears to actually be tracked by: rdar://89029702