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

VERIFIED FIXED in Firefox 20

Status

()

Core
Graphics
VERIFIED FIXED
6 years ago
5 months ago

People

(Reporter: Optimizer, Assigned: roc)

Tracking

(Depends on: 1 bug)

Trunk
mozilla21
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox20 verified, firefox21 verified)

Details

(Whiteboard: [Snappy])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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)
(Reporter)

Comment 1

6 years ago
Created attachment 664655 [details]
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

6 years ago
This actually looks like a D2D issue. Bas?
Component: Bookmarks & History → Graphics
Product: Firefox → Core
(Reporter)

Comment 3

6 years ago
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

5 years ago
dupe of bug 807581 ?
(Reporter)

Comment 5

5 years ago
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.

Comment 7

5 years ago
disabling HWA solves this bug.
(Reporter)

Comment 8

5 years ago
Yes, so it is not a dupe, right ?

Comment 10

5 years ago
(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.
(Reporter)

Comment 12

5 years ago
Even while using the default theme ?
Created attachment 698600 [details] [diff] [review]
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.
Assignee: nobody → roc
Attachment #698600 - Flags: review?(bas)
(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.
(Reporter)

Comment 15

5 years ago
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.
Attachment #698600 - Flags: review?(bas) → review+
https://hg.mozilla.org/mozilla-central/rev/8d63c737db57
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21

Updated

5 years ago
Blocks: 807581

Updated

5 years ago
Blocks: 820247

Updated

5 years ago
Blocks: 812904

Updated

5 years ago
Blocks: 829563
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?
(Reporter)

Comment 21

5 years ago
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.
(Reporter)

Comment 22

5 years ago
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.
Attachment #698600 - Flags: approval-mozilla-beta?
Attachment #698600 - Flags: approval-mozilla-aurora?
(Reporter)

Comment 25

5 years ago
(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.
(Reporter)

Updated

5 years ago
Depends on: 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.
Attachment #698600 - Flags: approval-mozilla-beta?
Attachment #698600 - Flags: approval-mozilla-beta-
Attachment #698600 - Flags: approval-mozilla-aurora?
Attachment #698600 - Flags: approval-mozilla-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.
https://hg.mozilla.org/releases/mozilla-aurora/rev/3a05f9a9eb77
status-firefox20: --- → fixed
status-firefox21: --- → fixed
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)
status-firefox20: fixed → verified
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
Status: RESOLVED → VERIFIED
status-firefox21: fixed → verified

Updated

5 months ago
Depends on: 1294788
You need to log in before you can comment on or make changes to this bug.