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

Tue Mar 3 19:38:03 PST 2015

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

--- Comment #3 from Nick Dolezal <nick at safecast.org> ---
Hmmm, indeed.  I made a methodological error in my testing.  I confused the DOM styles from Safari's Develop -> User Agent -> Chrome with Chrome.app itself.

The useragent Safari reports for Develop -> User Agent -> Chrome is quite old, so I retested with a custom useragent string for Chrome 41.  ("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36")

Plot twist: Under Chrome 41's user agent, Safari 8's performance was as expected.  Moreover, -webkit-transform *is* getting set here as well, at least on some of the elements.

Further Tests: Firefox

Chrome 8 was set to the current stable Firefox UA ("Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0"), and retested.

Results: Chrome: Low FPS with recent Firefox UA set.  Firefox: 30+ FPS.

The DOM in both Firefox.app and Safari with UA=FF, showed no zero-transforms getting set, nor any apparent analogs.  I did not find a way to show compositing boundaries in Firefox, but the 3D view did show boundaries around the tiles.  Unknown if compositing or just element.

Further Tests: Breaking Zero Transforms For Everyone

To better compare the underlying compositing behavior, it would be useful to disable the useragent-related zero transform hacks.  I very crudely removed all the zero-transforms for both Chrome and Safari UA=Chrome 41.  This was effective in causing both Chrome and Safari to revert to their instinctive layer-squashing behaviors.

Results:

Performance: Decreased performance for both; Chrome: 30-60 FPS, Safari: < 15 FPS and  UI freezing.  Difficult to separate out polling / DOM traversal overhead, but CPU use increased in Chrome to almost 100% across all cores, whereas Safari bottlenecked on a single core at 100%.

Squashing: 
Chrome:  Would not squash further than the cyan gridlines seen in "chrome40.png"; these appeared to be 128x128 point (256x256 px actual) tiles, and were unaligned on a block level with Web Mercator tiles.
Safari:  Went all the way and squashed everything, looking identical to "safari8.png" -- no tile compositing boundaries.

The DOMs appeared similar, with Safari getting the vendor prefix (despite Chrome's UA...), and only transform-origin and transform-matrix were present on container divs I can see.  Those are required for panning the map AFAIK, and I don't think can be reduced further.

Conclusions:
1. Google Maps API v3 is making the zero transform hacks for pretty much everyone who needs them... except Chrome 8 OS X.
2. The zero transform hack has a much more significant effect upon Safari than Chrome, though quantifying that for Chrome is difficult due to the testing performed.
3. Without the hack, both Safari and Chrome squash layers.  Chrome will not squash as extensively as Safari.  This may be related to the logic changes in the linked bugs.
4. A sparsity heuristic may potentially improve Safari's performance here, assuming it is doing so for Chrome.  Unfortunately as long as Gmaps API v3 inserts stuff like this into the DOM for Chrome, the world will never know if the sparsity heuristic improved performance or not because it will never get used:

<img src="http://safecast.media.mit.edu/tilemap/TileGriddata512/9/452/197.png" draggable="false" style="width: 256px; height: 256px; -webkit-user-select: none; border: 0px; padding: 0px; margin: 0px; transform: translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px) translateZ(0px);">

Sidenote: Result of natural behavior in Chrome after panning a while.  Zombies with a Z.  pool.pop() and style += I'm guessing.  That's 1KB as UTF-16.  The map tile .png is 3KB.  This is why hardcoded hacks are bad.

Will attach updated test case with the translateZ removal for Chrome.

-- 
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/20150304/dc45fb83/attachment-0002.html>