Closed Bug 917746 Opened 11 years ago Closed 3 years ago

Google Maps performance when panning is very very very poor

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Version:
51 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla50

People

(Reporter: tx00824, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [platform-rel-Google][platform-rel-GoogleMaps])

I can't stress enough how poor firefox's performance in regard to google maps is in comparison to Chrome and IE. It is very well known fact around the net. So if you need confirmation of this bug just install yourself newest versions of Chrome, IE and Firefox and then go straight to maps.google.co.uk. Comparing Chrome and Firefox is like night and day. AND if you switch to new version of maps which they are testing at the moment it totally is unusable in FF. I admit it is a tiny bit slower in chrome but in Firefox it just don't work at all. I have posted many times on many forums about this problem and it seems that nobody who deals with Firefox problems cares enough about it. My computer specs are very and this problem were replicated on 5 different computers with different systems Windows XP 32bit, Win 7 32 and 64 bit. Just to be clear I have - Haswell 4770k - Asus Gryphon z87 - 16GB 1600Mhz - Samsung 840 pro SSD - HP ZR30W 2560x1600 resolution (on other machines resolution was much lower and it made no difference it was still super slow, besides Chrome and IE are fine in this resolution) I do care about Firefox and if you don't want to loose comunity as at the moment the numbers are falling in favor to Chrome, have a look yourself (all other browsers are loosing too but it is not the point) you have lost nearly 5% in last year. http://www.w3schools.com/browsers/browsers_stats.asp Firefox excell in customization it is brilliant BUT PERFORMANCE is as the numbers show the most important factor so please FORWARD THIS "bug" to the right people. I realise it might be not a simple matter to sort out, it probably will require some major change in the coding but if you want to stay in the market it has to be done.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (20130925030203) I am definitely seeing a difference in performance compared to Chrome, but the difference is rather small on my machine. Also, the performance on Firefox is not poor for me, it's just not quite as good as for Chrome. I have an Intel Core i5 4@3.2GHz, 8GB RAM, Intel HD 4000 graphics and a 320GB HDD. My screen has only 1680x1050 resolution, so better resolution might after all be a trigger for your issue. I'll try to test on a better screen soon enough.
Severity: blocker → major
(In reply to Ioana Budnar, QA [:ioana] from comment #1) > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 > (20130925030203) > > I am definitely seeing a difference in performance compared to Chrome, but > the difference is rather small on my machine. Also, the performance on > Firefox is not poor for me, it's just not quite as good as for Chrome. > > I have an Intel Core i5 4@3.2GHz, 8GB RAM, Intel HD 4000 graphics and a > 320GB HDD. My screen has only 1680x1050 resolution, so better resolution > might after all be a trigger for your issue. I'll try to test on a better > screen soon enough. Same results on a PC with 1920x1080 resolution. Unfortunately I don't have access to anything better.
Until FF will be updated in regard of speed I have moved to chrome, to be honest not a big deal, you forget old habits instantaneously (extension and customization pros) so I might just stay with chrome anyway from now on until something major changes. I don't understand how would this issue be a google's fault like some people say on other forums. Google maps uses JavaScript, and this is it there is no other hidden language it should work on all browsers the same but clearly FF has some tiny bug somewhere inside that makes it slower in execution of JS and nobody seems to care about it...
I face a huge slowdown when using a site that looks to rely on Google maps (references to maps.gstatic.com): http://quartermaester.info To reproduce the problem, just pan gently the map with the mouse. It takes up to several seconds to display the updated position. Tested with a fresh profile, no history and a fresh build (Nightly 29.0a1 Rev 161826) on Windows 7 x64. The only extension installed is the gecko profiler. With an official build, the display update is faster but still very slow in comparison with Chrome or Internet Explorer. The slowdown does not seem to be related to the drawing. Panning is slow even with a small window. Profiling file: http://people.mozilla.org/~bgirard/cleopatra/#report=5df53ece9ed3fc37920efd02d61bdc6aeb125ae4
I have this problem in Firefox both in Linux and OSX (Mavericks). I'm running 36 or 37 beta 1, but this problem has persisted for many versions. I have removed firebug, but it made no difference. In Chrome or Safari (i.e. webkit backed) it works fine and smoothly, but on FF it is unusable. Any change such as zoom or pan is interminably slow, my entire FF session (i.e. all other tabs) grinds to a halt. I know this is a problem related to a specific, non-Mozilla service, which is probably taxing a specific part of the Gecko engine, but it's a much-used part and I think it needs fixing as a matter of urgency.
I'm using version 41.0a2 and the Google Maps performance is absolutely gruesome, bordering on unusable. It's a sluggish slide show where I have to wait several seconds after every gesture. This is true for both maps.google.com and applications where Google Maps is embedded using the Google Maps Javascript v3 API. Using Chrome and Opera on the same machine (Debian 8 on i7 3770k processor) Google Maps runs perfectly.
Just realised how bad Firefox is at Maps after seeing what it should be like in Chrome. Running decent spec iMac 8GB Ram, Nvidia Geforce GT 755M 1GB, 3.2GHz i5. Even the magic mouse sensitivity is way off.
The performance is due to very carefully selected and somewhat clever use of functions where Firefox performs very poorly but where chrome performs well. Google want Firefox dead, and this is just another weapon to push people off the beleaguered platform. Google have been very clever in ensuring they use functions that perform very badly in Mozilla's java-script engine. If Mozilla do not address this asap, google will engineer Mozilla out of existence.
Component: General → Desktop
Product: Firefox → Tech Evangelism
Version: 27 Branch → Firefox 27
(In reply to John Burges from comment #8) > The performance is due to very carefully selected and somewhat clever use of > functions where Firefox performs very poorly but where chrome performs well. > > Google want Firefox dead, and this is just another weapon to push people off > the beleaguered platform. > > Google have been very clever in ensuring they use functions that perform > very badly in Mozilla's java-script engine. If Mozilla do not address this > asap, google will engineer Mozilla out of existence. To demonstrate how Google are perverting the performance of google maps in Firefox; In Firefox v43.0.4 , change the user agent string to "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko" then browse / use google maps. The performance is significantly better, along with some broken parts of google maps now work. You can install http://chrispederick.com/work/user-agent-switcher to achieve this more conveniently. Select "Browsers - Windows" > "MSIE 11.0 - (Win 8.1 32)"
At first I thought that I, like Ioana, was not seeing *dramatic* differences on my main computer. However, if I "flick" the map a screenful or so left or right in Chrome, street names and other details appear almost instantly, within one second. In Firefox with the default UA, after flicking the map so far most of the screen has no details it takes 5 - 8 seconds, sometimes even more, before the map is truly drawn with full details and names. I can also confirm the observation that with the IE11 UA string the map is redrawn faster in Firefox.
Looking at the server communication I don't really see differences - both for the IE11 UA and the Firefox UA the server sends payloads of binary data with Content-Type: application/vnd.google.octet-stream-compressible; charset=x-user-defined In the browser the data is rendered on a CANVAS.
Hm.. the most noteworthy observation is that Chrome (real Chrome, not just spoofing UA) loads a lot more data than Firefox. The most important parts of Fiddler's statistics panel, first Firefox then Chrome: Firefox: Request Count: 35 Bytes Received: 386 579 (headers:18 291; body:368 288) Sequence (clock) duration: 00:00:17.137 DNS Lookup time: 33ms TCP/IP Connect duration: 262ms HTTPS Handshake duration: 185ms RESPONSE CODES -------------- HTTP/200: 34 RESPONSE BYTES (by Content-Type) -------------- application/vnd.google.octet-stream-compressible: 197 757 application/x-protobuffer: 120 451 Chrome: Request Count: 170 Bytes Received: 2 271 948 (headers:87 243; body:2 184 705) Sequence (clock) duration: 00:00:07.389 TCP/IP Connect duration: 18ms HTTPS Handshake duration: 20ms RESPONSE BYTES (by Content-Type) -------------- application/x-protobuffer: 1 585 275 application/vnd.google.octet-stream-compressible: 545 110 So Chrome sends 4 times more requests, and get back 5 times as much data - in less than half the time..(7 seconds vs 17).
Google is used to send very different version of code based on UA sniffing. If we are **sure** that the version sent to Chrome is working identically on Gecko, we may ask to Google to send us the same version, BUT this comes to the price of extensive testing.
I would like to point out this patch that recently was posted to mesa mailing list: https://patchwork.freedesktop.org/patch/70683/. In the middle of the comment it describes one potential issue with current mesa implementation that in opinion of the patch author may be causing google maps slowness. Note: that patch doesn't fix the problem, it merely states it. Unfortunately I'm not qualified enough to understand to what extent this is related to bug in question, but I hope someone more qualified would be able to have a look and maybe suggest a fix that would resolve the problem. I apologise in advance for possible off-topic. Thanks!
I think that's unrelated (although it may be a different problem worth fixing?) simply because the "below 1fps" speed quoted there would be even worse performance than what this bug describes..
I tested this a few months ago and could see the difference between Chrome and Firefox in performance here. Testing again today in Firefox 50 on a MBP, the differences seem very minor if any at all.
I've just compared 50 with Chromium on Ubuntu 16.04 and different is staggering. I have reasonably fast laptop i7-3520M and in Chromium all pans/zooms are immediate. In FF it takes seconds/10s of seconds for labels to appear/new pieces of maps to download. It seems to be especially bad in densely populated areas with lots of labels.
I have the same experience - running the 4.6 kernel(intel i5-6200U, 20gb ram) with Firefox 47.0 and performance is nearly unusable (versus perfectly smooth in Chromium 50.0). Switching the User-Agent string as suggested above significantly increases performance (to only slightly worse than Chromium).
interesting. Tested this morning on Mac OS X 10.11.6 (15G31) with clean profiles (no addons, no blocker, no tracking protection on, no login) of * Firefox Nightly 50 * Firefox 47.0.1 And I got the same results. aka smooth panning. On Opera 39.0.2256.37 (Blink engine) (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.75 Safari/537.36 OPR/39.0.2256.37 (Edition beta)), the tiles load a bit slower than on Firefox. As a note, the feeling of speed in both browsers change a lot depending on the aera. For example panning and zooming are very different in the center of Paris or in countryside area. (less data to process).
Is there a benchmarking tool that would be appropriate here, rather than gathering qualitative feedback? Intuitively (as someone fairly clueless to browser internals) it should be possible and maybe not so hard to track the change of state (from the coordinate/request start) to when the final state of the screen is rendered.
I did some profiling on Ubuntu and it looks like that ~10% of the time is spent in _mesa_readPixels. I did some digging and it looks like FF is using Basic shared surface that needs the pixels read back from GPU - and this read back takes considerable amount of time (at least on Intel). I looked at it for a bit more and discovered this: /* static */ UniquePtr<SurfaceFactory> GLScreenBuffer::CreateFactory(GLContext* gl, const SurfaceCaps& caps, const RefPtr<layers::CompositableForwarder>& forwarder, const layers::TextureFlags& flags) { return CreateFactory(gl, caps, forwarder, forwarder->GetCompositorBackendType(), flags); } /* static */ UniquePtr<SurfaceFactory> GLScreenBuffer::CreateFactory(GLContext* gl, const SurfaceCaps& caps, const RefPtr<layers::ClientIPCAllocator>& allocator, const mozilla::layers::LayersBackend backend, const layers::TextureFlags& flags) { UniquePtr<SurfaceFactory> factory = nullptr; if (!gfxPrefs::WebGLForceLayersReadback()) { switch (backend) { case mozilla::layers::LayersBackend::LAYERS_OPENGL: { #if defined(XP_MACOSX) factory = SurfaceFactory_IOSurface::Create(gl, caps, allocator, flags); #elif defined(MOZ_WIDGET_GONK) factory = MakeUnique<SurfaceFactory_Gralloc>(gl, caps, allocator, flags); #elif defined(GL_PROVIDER_GLX) if (sGLXLibrary.UseTextureFromPixmap()) factory = SurfaceFactory_GLXDrawable::Create(gl, caps, allocator, flags); #elif defined(MOZ_WIDGET_UIKIT) factory = MakeUnique<SurfaceFactory_GLTexture>(mGLContext, caps, allocator, mFlags); #else if (gl->GetContextType() == GLContextType::EGL) { if (XRE_IsParentProcess()) { factory = SurfaceFactory_EGLImage::Create(gl, caps, allocator, flags); } } #endif break; } As far as I can tell at least for linux we have `GL_PROVIDER_GLX=1`. At the same time there is this in gfxPerfs.h: // Disable surface sharing due to issues with compatible FBConfigs on // NVIDIA drivers as described in bug 1193015. DECL_GFX_PREF(Live, "gfx.use-glx-texture-from-pixmap", UseGLXTextureFromPixmap, bool, false); Bug mentioned in this comment seems to be long fixed. I've tried setting 'gfx.use-glx-texture-from-pixmap' pref to 'true' but unfortunately with that browser crashes on googlemaps - so something else is broken as well.
This doesn't seem a Tech Evangelism bug I will put it in Core Graphics and from there it can come back here when we know what is happening.
Component: Desktop → Graphics: Layers
Product: Tech Evangelism → Core
Target Milestone: --- → mozilla50
Version: Firefox 27 → 51 Branch
platform-rel: --- → ?
Whiteboard: [platform-rel-Google][platform-rel-GoogleMaps]
platform-rel: ? → ---

On windows with a old AMD 7750 GPU, any site with a list of items overlayed spends seconds in the kernel when panning (until the browser is unresponsive until it works though the render list). Without hw acceleration it is fine.

This doesn't affect my macbook.

An example site:
https://www.centris.ca/en/houses~for-sale~montreal-island?view=Map

(In reply to Steve from comment #24)

On windows with a old AMD 7750 GPU, any site with a list of items overlayed spends seconds in the kernel when panning (until the browser is unresponsive until it works though the render list). Without hw acceleration it is fine.

"Without hw acceleration it is fine." reminds me of bug 1562574.

I am confident that this issue is no longer valid, or if it is valid, it could only be hardware-specific or an edge case.

I have tested pretty much all the variations of Operating Systems vs available System Hardware and I compared the performance of Google Maps in Firefox Release v95.0 and Nightly v96.0a1 versus the latest release of Chrome. I have compared how fast it loads and how it feels while aggressive panning, zooming in densely populated areas, especially with the satellite layer, and also tested with hardware acceleration disabled.

Not one considerable performance difference was observed on ANY of the OSes tested, quite the opposite, on the lower-end systems, Firefox was a little faster than Chrome while using GMaps.

Combinations tested:

W10 + AMD 6core + Nvidia GTX 1050

  • performance difference not noticeable to the naked eye
  • When zooming in, the map loads over a black background which makes it look a little unprofessional compared to Chrome, which loads over the stretched-out background it zoomed in on.
    • only occurs on this system, with W10, and layers.accel.disabled=false

W10 64bit + i7-9750H + Intel UHD Graphics 360

  • performance difference not noticeable to the naked eye

U20 + i7-9750H + Intel UHD Graphics 360

  • performance difference not noticeable to the naked eye

W10 64bit + AMD 8core + ATI Radeon 3000 Graphics

  • performance difference not noticeable to the naked eye

W10 32bit + AMD 8core + ATI Radeon 3000 Graphics

  • performance difference not noticeable to the naked eye

W7 64bit + AMD 8core + ATI Radeon 3000 Graphics

  • performance difference not noticeable to the naked eye

MacBook Air 2013, GPU Intel HD Graphics 5000

  • performance difference not noticeable to the naked eye

U20 + i3 + Intel HD Graphics 5500

  • performance difference not noticeable to the naked eye

W10 + i3 + Intel HD Graphics 5500

  • performance difference not noticeable to the naked eye

W10 64 + AMD 8core + NVIDIA GeForce GT 710

  • performance difference not noticeable to the naked eye

W7 64 + AMD 8core + NVIDIA GeForce GT 710

  • performance difference not noticeable to the naked eye

Considering the original issue is no longer reproducing in any of the above combinations, I am feeling confident to close this bug as WORKSFORME. If it reappears or it is found to reproduce on a specific system, please reopen it.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.