Closed Bug 656266 Opened 15 years ago Closed 14 years ago

Google Maps performance regression in Firefox 4+

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: simon.bugzilla, Unassigned)

References

(
URL
)

Details

(Keywords: perf, regression)

Attachments

(1 file)

arty Google Maps in Firefox
353.67 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110510 Firefox/6.0a1 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110510 Firefox/6.0a1 Suffering very poor performance using Google Maps since 4.0 release. Maps are slow to navigate, with choppy movement. Map tiles can take many seconds to load, and sometimes not load at all. CPU usage is also high while tiles load. Safari, Chrome and Opera all work fine. Reproducible: Always
Does the issue still occur if you start Firefox in Safe Mode? https://support.mozilla.com/en-US/kb/Safe+Mode How about with a new, empty profile? https://support.mozilla.com/en-US/kb/Basic+Troubleshooting#w_8-make-a-new-profile
Version: unspecified → 4.0 Branch
WFM on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110522 Firefox/6.0a1
Reporter, do you have anything new to add about this issue?
I have the same problem with Firefox 4 (Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1) as well. Firefox 4 ist generally super fast but when I'm using Google Maps in satellite view it takes ages to load all the tiles of a certain view. When I use Chrome (ok, Google product, I know) it's as fast as desired,
The same behavior is present after following the steps in comment1?
Slightly faster, but not as expected (and not as on my Linux Notebook with the same addons; different computer I know, but still...). It's as fast as Linux in the Virtualbox, which isn't really fast at all. And I wonder by what I got a "bad profile".
If you see improvements, do you still consider this a bug? If not, please change the status of this bug to Resolved WFM, Incomplete. Thx
Same here with FF5 on Nvidia Quadro FX 4500. It takes several seconds for FF to simply load the tiles from the Google tiles server, where FF just sits there with 100% CPU doing nothing before the tiles get loaded/rendered. In Opera or Chrome, zooming or panning is about three times faster with less CPU. I'm pretty sure that it has nothing to do with the zooming animation (actually for some reason I don't get any zooming animation anyway on Google Maps as e.g. on Bing Maps, with either browser). This just seems to be one more of the mystical Gecko "Second's Silence" phenomenons discussed in Bug 490122, where the Developers are totally clueless, even after YEARS!
As the improvements are so marginal by using an empty profile or switching off all add-ons I still consider this a bug. At least for Windows XP, as I don't have that problem on my Linux Notebook (as I said before).
Try turning off hardware acceleration by unchecking "use hardware acceleration when available" option from Firefox > Preferences > Advance Tab > General by.
1st, nobody will want to turn off hardware acceleration, restart the browser, use Google Maps, turn on hardware acceleration, restart the browser, aahh I forgot to look up something, turn off hardware acceleration, restart the browser, use Google Maps again, turn on hardware acceleration, restart the browser etc. 2nd, I just tried it and sure enough turning off hardware acceleration makes things even worse in Google maps. Man how I'd love to switch to another browser for good -- if only they had my favorite extensions already.
Still WFM on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0rc and also on the latest Nightly Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110616 Firefox/7.0a1
haha, you say it. turning hardware acceleration off doesn't improve anything. (you could switch to Linux :-) ) I want to stress again that (for me) it's only the sattelite view that takes ages to load. Map view is as fast as desired.
New Firefox 5 doesn't fix it (Windows XP), but I like the visual effects the problem creates. Takes up to 15 seconds to load "all" (thousands of them ;-) ) the tiles of a sattelite view picture. Really sad if I compare it to Chrome.
I can confirm utter pity performances on Google Maps. And yes, it doesn't change in safe mode (is it a prepackaged answer to every bug users open?). I run last (5.0) FF version on Windows XP. Even Explorer 6.0 is _dramatically_ FASTER than FF 5.0 on Google Maps. I am really amazed seeing Mozilla doing nothing about this since *months*. Google Maps is a very used service among users.
Confirmed, but much, much less serious, on Linux (FF5): 2.6.32-33-generic #68-Ubuntu SMP Fri Jun 17 16:32:25 UTC 2011 x86_64 GNU/Linux With FF 8 nightly it gets slightly better, but still lagging after Chrome.
I think this problem might be OS version dependant (maybe just Windows XP related), while I only have this problem on my XP desktop at work and DON'T have it on the Win7 laptop at work and my Ubuntu Notebooks (kernel 2.6.35 and 2.6.38) at home. So the problem might be the Firefox version for Windows XP or it's Windows XP itself that holds Firefox from rendering Google Maps faster (by bad dependencies maybe). For the XP computer I already tried the Firefox 6 beta version, but it's still slow slow slow.
I was the original reported, I'm on Mac platform. I would like to confirm it is in satellite mode where performance is a problem.
Keywords: perf, regression
OS: Mac OS X → All
Hardware: x86 → All
Summary: Google Maps suffering poor performance in Firefox 4 or newer → Google Maps performance regression in Firefox 4+
Version: 4.0 Branch → Trunk
(In reply to Simon Howes from comment #20) > I was the original reported, I'm on Mac platform. > > I would like to confirm it is in satellite mode where performance is a > problem. but can you reproduce started in safe mode?
Whiteboard: [closeme 2011-10-16]
I'm noticing this too, in particular, I'm developing a custom map overlay that displays divs atop google maps, up to a couple hundred at a time. Dragging the map is in firefox is really choppy, whereas it is snappy on chrome, safari, and even relatively fast on ie8 and ie7. I'm running 6.0.2 on mac osx lion. I also opened up an older copy running 3.6.15 and the performance is snappy, so somewhere between 3.6 and 6.0 seems to be a regression. I tried to reproduce the issue by running google maps with the satellite imagery layer, but that works fine... perhaps I can setup a demo of the map I'm building as a reproducible test case.
Someone experiencing the performance regression who can supply a regression range? A good tool is mozregression: http://harthur.github.com/mozregression/ Otherwise one can do that manually by downloading nightly builds from: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Keywords: regressionwindow-wanted
I already did in bug 636959, which I believe it might be related: https://bugzilla.mozilla.org/show_bug.cgi?id=636959#c13
Still persistent on Firefox 8 (Windows XP). New profile or deactivating all addons doesn't solve the problem. When using the scroll wheel to zoom in several layers it seems like Firefox is loading the tiles of all layers till it "notices" which layer is the right one. In general rendering of maps tiles is very, very slow (I started using Chrome for maps).
I just ran mozregression to narrow down the last good nightly: Last good nightly: 2011-01-02 First bad nightly: 2011-01-03 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a05e91710adb&tochange=c20f34eefa5d To reproduce for yourself, my use case is dragging the map here: http://www.realtimefarms.com/goodsexplorer on a good build, it drags smoothly. on bad builds (since 2011-01-03) dragging is very choppy
I just found that removing the border radius from the divs *or* removing the opacity from the circle divs on the map overlay removes the problem. This makes me think that my particular issue has to do with the performance of (re)drawing divs that have a border radius. I will open a separate issue.
Since my issue seems to be not the same general map performance, I created this separate issue: https://bugzilla.mozilla.org/show_bug.cgi?id=708054
Comment 25 is actually the best description of the problem. A while ago we tried to look at this with the author of AdBlock add-on as I had thought that it was this add-on that caused the problem. We came at the conclusion that there is something wrong with the Google Maps because it is loading a lot of zoom levels while only the one a user has landed on is needed. This explains how it looks, flickering of different levels of zoom or grey tiles. It is strange that nothing like that happens in Google Chrome. It can be somehow connected with how Firefox deals with the scrolling wheel. However, the behaviour is strange even when dragging the zoom level by mouse, not using scroll wheel. Well, who knows what this is and why actually these problems cannot be confirmed or recognised by more than few users…
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2011-10-16]
Sad that this has been ticked as resolved. The problem is persistent and has been there for a few versions. I actually even thought of moving to Chrome because of this. In Chrome the satellite Google Maps are substantially faster.
The comments 22 and on, with regression range etc, have been added since "[closeme 2011-10-16]" got added to the whiteboard so I'm not convinced that the closeme-statement is still valid.
Bing, OSM and Waze are all slow in comparison to other browsers. Waze even states on their web site to use Chrome, as "firefox is too slow and buggy when it comes to maps" is what I was told.
(In reply to Thomas Ahlblom from comment #32) > The comments 22 and on, with regression range etc, those are relevant to bug 708054. If someone is willing to do the same work for other issues, like bugs mentioned in comment 17, that''d be very helpful (In reply to Karel Jára from comment #29) > Comment 25 is actually the best description of the problem. Is this the same as Simon's issue? If not, it deserves a separate bug report.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: