MozillaZine

18.0b2 and UI.submenuDelay

Discussion about official Mozilla Firefox builds
soulek
 
Posts: 74
Joined: November 7th, 2005, 4:18 am

Post Posted November 30th, 2012, 10:48 am

First in FF 18.0b1, and now in FF 18.0b2, I've noticed a very substantial (and annoying) lag in the display of bookmark sub-menus (compared to 17.0 and all preceding releases). I have 17 top-level BM folders, many, many subfolders, and a total of 2,933 bookmarks.

I verified my experience on a clean profile, without any add-ons or plugins.

I've added the preference "user_pref("ui.submenuDelay", 0);", to no effect.

Bug? Has "ui.submenuDelay" been disabled or replaced?

Thanks

OS: Win7, x64, fully patched

marty60
 
Posts: 315
Joined: March 21st, 2012, 7:09 am

Post Posted November 30th, 2012, 12:13 pm

This behavior was occurring with 17.0 as well that I noticed but when it went into Aurora it was fixed. It usually starts happening after FF has been open a while. Someone mentioned that in the nightlies there is a temporary enabling regarding frames (don't know the exact config entry) that causes a lag in the browser's overall performance.

soulek
 
Posts: 74
Joined: November 7th, 2005, 4:18 am

Post Posted November 30th, 2012, 12:19 pm

It definitely gets worse when FF has been open for awhile, but it is present when FF first starts. Would like to know the config entry, of course.

soulek
 
Posts: 74
Joined: November 7th, 2005, 4:18 am

Post Posted December 6th, 2012, 12:58 pm

Hmmm ... 284 "reads" of this thread as I post this, and only one reply. This sent me back to do more testing.

WITH 4 TABS OPEN:

I find that there is NO delay in the speed of the bookmark submenus if I start FF (now 18.0b3) in Safe Mode (whether I access the bookmarks menu from the FF Button, or from an icon on the navigation toolbar).

OTOH, I find that if I disable ALL of my Add-ons (one by one, using the Add-ons Manager), then there is still a bookmark submenu delay. I don't understand why there is a difference in behavior between (i) Safe Mode and (ii) all Add-ons disabled, and hopefully someone can explain it to me. I assume it is an architecture issue. If I better understand the architecture, I may be able to better diagnose the issue.

When there IS a bookmark menu delay, accessing the bookmarks menu from the FF Button results in NO delay; accessing the bookmarks menu from an icon on the Navigation Toolbar results in a delay.

When there IS a bookmark submenu delay, FF "response" is also slower on other items, such as closing tabs by middle-clicking on the tab.

WITH 20 TABS OPEN:

Even in Safe Mode, there is a significant bookmark submenu delay, both for the Bookmarks menu/submenu on the FF Button, and for the one accessed via the icon on the Navigation Toolbar.

Seems as though this is at least partially a memory issue. My system has plenty of memory (6GB). There is still 3250 MB of "available" physical memory, and firefox.exe is reporting 267,700K (w/4 tabs open) + 2% CPU usage; ~525,000K (w/20 tabs open) + an unexplainable 13% CPU usage + 261,080K Flash. The CPU usage (both the 2% and the 13%) is highly unusual (i920), and inconsistent with my experience with prior versions of FF.

Perhaps the MemShrink project is responsible for some of this.

FF 17.0.1 has no delays anywhere, at any time.

soulek
 
Posts: 74
Joined: November 7th, 2005, 4:18 am

Post Posted December 31st, 2012, 1:29 pm

This problem continues, without change, in FF 18.0b6.

mattcoz
 
Posts: 994
Joined: November 7th, 2002, 11:15 pm

Post Posted December 31st, 2012, 4:47 pm

I've found that the problem goes away with hardware acceleration disabled. This is obviously not an acceptable solution though.

soulek
 
Posts: 74
Joined: November 7th, 2005, 4:18 am

Post Posted January 5th, 2013, 10:40 pm

Yes, it is much better with hardware acceleration disabled (obviously some sort of architecture error). But even then I notice that there is more of a bookmark submenu delay when I access the bookmarks from an icon on the navigation bar, than when I access them from a menu item in the FF start button.

Further, with hardware acceleration disabled, I notice that the bookmark submenus (accessed from an icon on the navigation toolbar) are snappy at first, but become slower and slower the longer the browser is used. The bookmark submenus accessed via the FF start button remain snappy (though my testing wasn't exhaustive).

Surely some developer knows what they changed in FF 18 to effect this radical degradation of performance.

gourdo_1
 
Posts: 20
Joined: October 30th, 2004, 2:35 pm

Post Posted January 9th, 2013, 2:58 pm

This is frustrating. Not sure why this was allowed into the final 18.0 release. Couple of related bugs here to keep on eye on:
https://bugzilla.mozilla.org/show_bug.cgi?id=794246
https://bugzilla.mozilla.org/show_bug.cgi?id=807581

As discussed in the 807581 thread, if you right-click the toolbar and hit "Customize..." then simply close that window, it alleviates the problem. For me, this only helps temporarily though as the delay crops up again after some time.

marty60
 
Posts: 315
Joined: March 21st, 2012, 7:09 am

Post Posted January 10th, 2013, 7:29 pm

gourdo_1 wrote:As discussed in the 807581 thread, if you right-click the toolbar and hit "Customize..." then simply close that window, it alleviates the problem. For me, this only helps temporarily though as the delay crops up again after some time.


Another way to get around it is open another window then close the old one.

Or if you have the restart button from the Toolbar button pack just use that and it automatically restores all your tabs.

patrickjdempsey

User avatar
 
Posts: 22758
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted January 10th, 2013, 8:16 pm

mattcoz wrote:I've found that the problem goes away with hardware acceleration disabled. This is obviously not an acceptable solution though.


How is this not an acceptable solution? If you are encountering one problem because of HWA, then you likely are having other HWA-related problems that are more subtle and difficult to notice. Which means that any benefit you expect to gain from having it enabled you quite likely are not. Only 30% of Firefox users can use HWA without experiencing related crashes and performance problems. Since Mozilla continues to push for more and more HWA integration, a symptom of a minor problem could expose itself as a big problem later down the road.

If you are worried about fonts, you can force Firefox to use fancy fonts while HWA is disabled by this setting: gfx.font_rendering.cleartype.always_use_for_content
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

mattcoz
 
Posts: 994
Joined: November 7th, 2002, 11:15 pm

Post Posted January 11th, 2013, 7:18 pm

patrickjdempsey wrote:
mattcoz wrote:I've found that the problem goes away with hardware acceleration disabled. This is obviously not an acceptable solution though.


How is this not an acceptable solution? If you are encountering one problem because of HWA, then you likely are having other HWA-related problems that are more subtle and difficult to notice. Which means that any benefit you expect to gain from having it enabled you quite likely are not. Only 30% of Firefox users can use HWA without experiencing related crashes and performance problems. Since Mozilla continues to push for more and more HWA integration, a symptom of a minor problem could expose itself as a big problem later down the road.

If you are worried about fonts, you can force Firefox to use fancy fonts while HWA is disabled by this setting: gfx.font_rendering.cleartype.always_use_for_content

It's not acceptable because it's ignoring the problem. An acceptable solution would be to FIX it. :roll:

patrickjdempsey

User avatar
 
Posts: 22758
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted January 11th, 2013, 7:36 pm

Yes. Obviously... or just not worry about all that broken HWA mess and leave well enough alone. Which is what I do... disable all of it and magically I don't have any HWA-related problems ever. Personally, I like to simplify my life.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

mattcoz
 
Posts: 994
Joined: November 7th, 2002, 11:15 pm

Post Posted January 11th, 2013, 8:42 pm

patrickjdempsey wrote:Yes. Obviously... or just not worry about all that broken HWA mess and leave well enough alone. Which is what I do... disable all of it and magically I don't have any HWA-related problems ever. Personally, I like to simplify my life.

Well yeah, that's what I've done, but it's a workaround and not a solution, which is what I was saying. Luckily it looks like they have a fix based on that bug report, hopefully it lands soon.

_Alexander

User avatar
 
Posts: 1197
Joined: April 1st, 2010, 2:24 pm
Location: Your augmented reality

Post Posted January 11th, 2013, 9:25 pm

Hardware acceleration has the opposite of intended effect in Firefox. It is actually an ancient problem (my netbook was new when HWA was introduced).
The development of a solution, which before took the faux form of DLBI and Azure, is slow and nameless.
Lets hope this gets solved soon.
http://magneticpudding.com/ <- My Blog
i5 3570k @ 4.5 Ghz / NV 660 / 32GB DDR3 / 1080p LCD / SSD (120 + 180) / W8 ||| Atom N270 / NV ION / 3GB DDR3 / SSD / 1366x768 / W8

Omega X

User avatar
 
Posts: 7418
Joined: October 18th, 2007, 2:38 pm
Location: A Parallel Dimension...

Post Posted January 12th, 2013, 1:27 am

Patrick's complaint is two fold. 70% unable to use HWA is due to 1) Drivers, and 2) The 4K rule where everything except for most Intel GPU chips can handle 4K textures. Based on those rules alone shut out a lot of the marketshare. But it isn't because they can't its because the current system in place was slower and had more issues without 4k textures. Then there's Cairo which adds more overhead because of the translation from stateful to stateless. it doesn't pay for them to continue to optimize a method that's going to die in the future when that effort goes into Azure and OMTC.

Display List Based Invalidation where the layout engine creates lists of objects and makes decisions on what/how to display things incrementally has no direct connection to HWA.
Latest: Firefox/39.0 *ESR/38.1.0 - Mobile/39.0 - Thunderbird/38.1.0 - SeaMonkey/2.33.1
Nightly: Nightly/42.0 - Mobile/42.0 - Daily/42.0 - SeaMonkey/2.35a1

Return to Firefox Builds


Who is online

Users browsing this forum: No registered users and 6 guests