Here is some sample profile : http://people.mozilla.com/~bgirard/cleopatra/?report=04b1a755e801c1aadc73a0ffd0383b12f44d0d18 The end result is seen in the attached screencast. After restarting the browser, first few folders open quickly, but the soon they start lagging, the painting takes around 500 ms, and in this time, only the border shadow is shown. iirc, this was introduced at around the time when dlbi started landing. (I might be wrong)

Quality has been reduced to make size smaller, but fps is still 30, so what you see is what you get. Notice the delayed painting of folder menu popups.

This actually looks like a D2D issue. Bas?

One more point that this only happens if I use mouse to open these menupopups, if I use keyboard arrow keys to navigate, then there is no lag/delay in painting.

dupe of bug 807581 ?

maybe. I just want this to get fixed. I have *a lot* of bookmarks and feedmarks. Unfortunately I am not familiar with this side of gecko code, so could not help here.

I also filed bug 812904, I think they're all duplicates. In my case, the browser becomes unresponsive when the mouse hovers the bookmarks button. But I can't reproduce with a Nightly build.

disabling HWA solves this bug.

Yes, so it is not a dupe, right ?

See also bug 820247.

(In reply to Girish Sharma [:Optimizer] from comment #8) > Yes, so it is not a dupe, right ? No. bug 807581 is not affected by HWA on or off. I disabled HWA for testing this bug, and the opening of bookmark menu/submenus was so much better. I had forgotten how fast that happened in FF15 and before. It was like using a new browser.

I'm pretty sure this is us drawing a massive number of theme backgrounds for menu items. The increased slowness over time may be due to some memory allocation issues in D3D or GDI.

Even while using the default theme ?

I remember we discussed this at the last work week. As far as I can recall, we didn't come up with a better solution.

(In reply to Girish Sharma [:Optimizer] from comment #12) > Even while using the default theme ? Yes. The problem is that there is not reliable way to determine that the current theme isn't going to draw anything, so we have to do a lot of work to set things up and ask the theme to draw even if it doesn't end up drawing anything.

Ah, so cache upon startup and/or theme change whether the default theme is applied or not ?

Comment on attachment 698600 [details] [diff] [review] fix? Review of attachment 698600 [details] [diff] [review]: ----------------------------------------------------------------- Yes, although we should really be avoiding some -more- drawing than just this, but this should be ok for now and we can try to see if it improves things! ::: dom/media/MediaManager.cpp @@ +1092,5 @@ > nsresult rv = NS_NewISupportsArray(&array); // AddRefs > if (NS_FAILED(rv)) > return rv; > > + // mActiveWindows.EnumerateRead(WindowsHashToArrayFunc, array); I suspect this doesn't belong here.

would it be possible to uplift this to Aurora due to the high number of duplicated bug reports and the fact bookmarks are pretty much often used?

I can still see the following behavior clearly: 1 First the border is painted with the whole popup transparent. 2 Then the popup is painted with the bookmarks/feeds . Although it is much faster than before, and it does not lag with time. IMO, this painting should not be separately visible at all.

If the reason for step 1 and 2 being clearly separately viewable is the time taken to draw the menu items, then there can be a workaround, that when we draw the border of the box, draw the same colored background also. This will make the opening of popups snappier.

I think what we need to do there is to delay showing the widget until we've completed the layer transaction that renders all the contents of the widget. Please file a new bug for that?

Comment on attachment 698600 [details] [diff] [review] fix? [Approval Request Comment] Bug caused by (feature/regressing bug #): none User impact if declined: unresponsive browser when opening very large menus Testing completed (on m-c, etc.): landed Risk to taking this patch (and alternatives if risky): very low risk. Worst that could happen is that on some exotic Windows theme, custom menu item backgrounds for inactive menu items wouldn't be drawn. String or UUID changes made by this patch: none.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #23) > I think what we need to do there is to delay showing the widget until we've > completed the layer transaction that renders all the contents of the widget. > Please file a new bug for that? Filed Bug 830697.

Comment on attachment 698600 [details] [diff] [review] fix? Even though this is low risk, it appears to be a longstanding issue and can therefore ride the trains. Approving for Aurora.

(In reply to Alex Keybl [:akeybl] from comment #26) > Even though this is low risk, it appears to be a longstanding issue The slowdown comments all come from FF18 users, not sure it's longstanding.

Verified Fixed on FF 20RC on Windows 7 x64: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0(20130326150557)

Verified as fixed on FF21b1: Win 7x64, Mac OS 10.8 and Ubuntu 12.10: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0 Builds ID: 20130401192816