794246 - Opening (book|feed)mark folder from Bookmarks Toolbar becomes choppy quickly.

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Girish Sharma [:Optimizer]]

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)

Comment 1

[Girish Sharma [:Optimizer]]

Attachment: Screencast with observed choppyness

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.

Comment 2

[(dormant account)]

This actually looks like a D2D issue. Bas?

Comment 3

[Girish Sharma [:Optimizer]]

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.

Comment 4

[Mayank Bansal]

dupe of bug 807581 ?

Comment 5

[Girish Sharma [:Optimizer]]

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.

Comment 6

[Marco Castelluccio [:marco]]

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.

Comment 7

[Mayank Bansal]

disabling HWA solves this bug.

Comment 8

[Girish Sharma [:Optimizer]]

Yes, so it is not a dupe, right ?

Comment 9

[Marco Castelluccio [:marco]]

See also bug 820247.

Comment 10

[Mayank Bansal]

(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.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 12

[Girish Sharma [:Optimizer]]

Even while using the default theme ?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix?

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.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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.

Comment 15

[Girish Sharma [:Optimizer]]

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

Comment 16

[Bas Schouten (:bas.schouten)]

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.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://bugzilla.mozilla.org/show_bug.cgi?id=794246

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8d63c737db57

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8d63c737db57

Comment 20

[Marco Bonardo [:mak]]

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?

Comment 21

[Girish Sharma [:Optimizer]]

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.

Comment 22

[Girish Sharma [:Optimizer]]

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.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 25

[Girish Sharma [:Optimizer]]

(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 26

[Alex Keybl [:akeybl]]

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.

Comment 27

[Marco Bonardo [:mak]]

(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.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3a05f9a9eb77

Comment 29

[Mihai Morar, (:MihaiMorar)]

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)

Comment 30

[Mihai Morar, (:MihaiMorar)]

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