[Webkit-unassigned] [Bug 142238] New: Extremely low performance layer compositing with Google Maps API v3

Tue Mar 3 15:02:11 PST 2015

https://bugs.webkit.org/show_bug.cgi?id=142238

            Bug ID: 142238
           Summary: Extremely low performance layer compositing with
                    Google Maps API v3
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Macintosh Intel
                OS: Mac OS X 10.10
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nick at safecast.org
                CC: simon.fraser at apple.com

Created attachment 247800
  --> https://bugs.webkit.org/attachment.cgi?id=247800&action=review
Sample project and screenshots demonstrating Safari 8 performance / compositing issues with Google Maps API v3 and CSS fix injector.

Summary:
Safari 8 (OS X) displays a profound performance regression in comparison to Safari 7 for viewing Google Maps API v3 pages, resulting in an unexpectedly low framerate and UI freezing.

Expected behavior:
"1080p 60fps".  In other words, performance on par with other browsers and Safari 7.

Actual behavior:
<15 FPS (roughly) with frequent UI freezing when multiple raster layers are used.

Steps to Reproduce:
See bottom of this text and attached sample project.

Additional Notes:

Further investigation revealed this is likely due to a layer compositing issue of some kind that affects both Safari 7 and 8, and furthermore that the differentiating factor is a navigator.useragent based workaround from the Google Maps API, which inserts "style:-webkit-transform:translateZ(0px);" to all raster map tile container divs for Safari 7 and Safari 8 Mobile, but *not* Safari 8 OS X.

Testing showed that Safari 7 and 8 performed very similar based entirely on the user agent setting via Developer -> User Agent.  Furthermore, applying a similar workaround as used by the Google Maps API v3 for Safari only restored Safari 8 framerates to Safari 7 levels and resolved excessive UI freezing/stuttering.

Setting the user agent to IE10, Chrome or Firefox resulted in the same behavior as Safari 8; low performance.

>From these results, I believe it can be concluded there is significant layer compositing performance issue that has been present in Safari/WebKit since at least Safari version 7, and that other browsers do not have this issue. It also seems reasonable to conclude this is a known issue, at least to the Google Maps API team, due to the IE6-style workaround fix employed and successful testing results of an analog of that.

Nonetheless, I was unable to find any bug referencing this, nor anything on Google, Stack Overflow, or the Apple Dev Forums.  So I began looking for things that could explain the differences between WebKit and Blink after the err uh, trial separation.

The closest reference I could find was a Chromium bug: https://code.google.com/p/chromium/issues/detail?id=356734&can=1&q=google%20maps%20performance&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

Which describes a process called "layer squashing."  Searching the WebKit bugs for layer squashing showed this bug marked as "won't fix": https://bugs.webkit.org/show_bug.cgi?id=109992 from the same authors of the layer squashing now part of Chrome / Blink.

>From the dates on those bugs, and the fact the behavior can be reproduced in Chrome 7, I am dubious that Safari/WebKit implements "layer squashing" as described in the aborted proposal.  Yet, in the attached screenshots, you can see a similar behavior occurring -- each tile is composited individually when it loads, then is no longer shown by the Safari "show compositing borders".

As this seemed a known issue to the Google Maps API team (the Safari 7 workaround), I contacted the authors of the layer squashing in Blink and the WebKit attempt.  They recommended submitting it as a bug cc:sfr with a sample project.  If there is a bug for this already, I was unable to determine it.

I can only guess as to the cause.  Some ancestral, cave-dwelling missing link of modern layer squashing?  Transfer of GPU textures to RAM after the CSS3 "ease in" forces GPU acceleration?  I'll probably never know.

Attached are screenshots of this behavior and a sample project demonstrating it.  It is 100% reproducible in my experience, and more noticeable with multiple raster tile layers.  Apologies for the zip file but it seems I can only attach a single file.

chrome40.png -- this is the sample project after clicking the button to add the sample "Safecast" layers.  Compositing borders have been enabled in Chrome.

safari8.png -- sample project, Safecast layers, Safari 8.  Taken while panning the map such that you can see borders for tiles as they are initially loaded.

safari8fix.png -- the above, after clicking "Inject Safari 8 Performance Hack Fix".  Note that the tiles have been ascended to their own compositing layers, as is the case for default behavior in Chrome, Firefox, IE, Safari 8 Mobile, and Safari 7, the latter of which is again, merely due to Google Maps employing a similar fix.  This is also more or less how Safari 7 looks.

Steps to Reproduce:
1.  Open sample .html page in Safari 8
2.  Enable compositing borders
3.  Click the button "Add Safecast layers" for the easiest reproduction (multiple raster layers)
4.  Hold down the arrow keys to pan around.  Note the low framerate and UI freezing.
5.  Click the button "Inject Safari 8 Performance Hack Fix".
6.  Note the compositing borders immediately change.
7.  Now hold down the arrow keys again to pan around.  30-60 FPS.

Differential Diagnosis: useragent
1.  Open sample .html page in Safari 8
2.  Enable compositing borders
3.  Click the button "Add Safecast layers" for the easiest reproduction (multiple raster layers)
4.  Hold down the arrow keys to pan around.  Note the low framerate and UI freezing.
5.  Click Developer -> User Agent -> Safari 7
6.  After reload, click "Add Safecast layers" again.
7.  Note the compositing borders now.
8.  Now hold down the arrow keys again to pan around.  30-60 FPS.

Differential Diagnosis: Safari 7 + useragent
1.  Open sample .html page in Safari 7
2.  Enable compositing borders
3.  Click the button "Add Safecast layers" for the easiest reproduction (multiple raster layers)
4.  Hold down the arrow keys to pan around.  Note 30-60 FPS as expected.
5.  Click Developer -> User Agent -> Safari 8
6.  After reload, click "Add Safecast layers" again.
7.  Note the compositing borders now.
8.  Now hold down the arrow keys again to pan around.  Note the low framerate and UI freezing.

NOTE: I am recommending arrow keys over mouse panning to make it more obvious and consistent, but it's also quite easily seen when click-and-dragging the mouse.  Just hold the arrow key down firmly and pretend it's native code.

I was uncertain how to implement an accurate framerate counter in Safari and did not see an option to enable one, thus reproducing this is somewhat manual.  Sorry.

Testing hardware:
MPB, 15", Late 2014, i7 4870HQ (Haswell), 16GB, SSD, dGPU.  OS X 10.10.2, Safari 8.0.3.  Forcibly enabling dGPU made no difference.
MPB, 13", Mid 2011, Core2Duo (meh), 8GB, 7200 RPM, ATI iGPU, OS X 9.latest, Safari 7.latest.

All extensions were disabled, cache cleared, machines rebooted, etc.

Final note (really!):  Google Maps API v3 is the framework you can use as a developer on your own page.  It is to maps.google.com as MKMapKit is to Maps.app.  In other words, maps.google.com is more like version 9003, hates developers, and uses WebGL.  I didn't do much testing on maps.google.com as I can't develop off it.  Safari 8 doesn't have exactly the same problem with UI freezing and useragent Safari 7 did nothing, but it nonetheless seemed to have a lower framerate than Chrome 40's 60 FPS.  Perhaps that warrants further research, but it does not seem to be related to the compositing issue for the v3 API here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150303/21388760/attachment-0001.html>