No subject


Tue Jan 27 15:54:36 PST 2015


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.
--1425423719.307e0.14332
Date: Tue, 3 Mar 2015 15:01:59 -0800
MIME-Version: 1.0
Content-Type: text/html

<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Extremely low performance layer compositing with Google Maps API v3"
   href="https://bugs.webkit.org/show_bug.cgi?id=142238">142238</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Extremely low performance layer compositing with Google Maps API v3
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>WebKit
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>528+ (Nightly build)
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Macintosh Intel
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Mac OS X 10.10
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>Major
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P2
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Layout and Rendering
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>webkit-unassigned&#64;lists.webkit.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>nick&#64;safecast.org
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>simon.fraser&#64;apple.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Created <span class=""><a href="attachment.cgi?id=247800" name="attach_247800" title="Sample project and screenshots demonstrating Safari 8 performance / compositing issues with Google Maps API v3 and CSS fix injector.">attachment 247800</a> <a href="attachment.cgi?id=247800&amp;action=edit" title="Sample project and screenshots demonstrating Safari 8 performance / compositing issues with Google Maps API v3 and CSS fix injector.">[details]</a></span>
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:
&quot;1080p 60fps&quot;.  In other words, performance on par with other browsers and Safari 7.

Actual behavior:
&lt;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 &quot;style:-webkit-transform:translateZ(0px);&quot; 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 -&gt; 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.



More information about the webkit-unassigned mailing list