No subject

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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>
--1425423719.307e0.14332--