Closed Bug 1258440 Opened 4 years ago Closed 4 years ago

tpaint is slowed on Linux and Windows waiting on CompositorParent's mPluginUpdateResponsePending


(Core :: Graphics: Layers, defect)

Not set



Tracking Status
firefox48 --- fixed


(Reporter: mconley, Assigned: jimm)




(1 file)

Here's a profile from a Windows XP machine running tpaint:,%22start%22%3A2691,%22end%22%3A3965%7D,%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A3215,%22end%22%3A3420%7D%5D&selection=0,7776,6,7,7777,7778,4,5,6,7,7777,8,9,10,11,12,13,14,15,16,17,7875,7876,7877,7878,7879,56,57,58,59,60,61,109,110,111,112,113,114,115,116,117,1392,1393,1394,1395,1396,1397,1398,1399,1400,1401,1402,7899,1695,5985,3609,3610,3611,6799

Notice the paint that occurs in the content process around the 3282ms mark.

Now notice the composite that occurs shortly after at around the 3295ms mark.

Then there's this big-ass pause while the content process polls the event loop, and then finally a DidComposite message comes down, and tpaint ends. That DidComposite message seems to be coming from a later composite - probably from the one that occurs around the 3325ms mark.

So the question is:

How come the DidComposite message is not sent / received closer to the 3295ms composite mark?
Okay, looking at when the MozAfterPaint fires in the parent, I think what's going on here is that the content is ready to paint earlier than the parent is, so GeckoMain is waiting for the parent to have painted before it can composite the two together (which makes sense).

So I think this is RESOLVED INVALID.
Closed: 4 years ago
Resolution: --- → INVALID
I'm wrong on this. Looking at the profiles, delayedStartup is being run before the big pause, so the parent _must_ have painted the window. So there's still a mystery here.
Resolution: INVALID → ---
In order to fire the MozAfterPaint event, we need to paint, and we need to composite. The gap that I describe in comment 0 is because the compositor thread is waiting for mPluginUpdateResponsePending to equal to false before it starts compositing again.

AutoResolveRefLayers is returning true for the pluginsUpdatedFlag here:

This is because we're entering this conditional:

And then we return true at the bottom of the UpdatePluginWindowState method, which causes pluginsUpdatedFlag to be set to true, which causes mPluginUpdateResponsePending to set to true, which causes us to bail out early from compositing.

Note that the window that tpaint opens has no plugins loaded. In fact, no plugins should have started at all during any part of this test. looks suspicious. It seems to assume that we had plugins displayed in the past, which is not true in the case of the tpaint window.

Something is clearly wrong here, jimm. Got any idea what the right move is?
Flags: needinfo?(jmathies)
Summary: MozAfterPaint seems to not be fired soon enough after compositing layers from the parent and content → tpaint is slowed on Linux and Windows waiting on CompositorParent's mPluginUpdateResponsePending
Assignee: nobody → jmathies
Flags: needinfo?(jmathies)
Pretty simple fix that avoids the attempt to hide plugins that shouldn't be present. I've confirmed this doesn't regress hiding plugin windows that do exist in tabs the user switches away from.
Comment on attachment 8733597 [details]
MozReview Request: Bug 1258440 - Don't attempt to hide plugin windows when switching trees if the previous remote layer tree didn't contain plugin windows. Fixes a tpaint regression. r?mconley

This looks like the right move to me, though I'm really not a gfx/ reviewer. If you're comfortable with me reviewing this though (and I think I've got a handle on this), r=me.
Attachment #8733597 - Flags: review?(mconley) → review+
Keywords: checkin-needed
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Looks like this helped tabpaint and tpaint. Nice find!
You need to log in before you can comment on or make changes to this bug.