Significant performance regression in MacOS Safari 14.1.2

[delfrrr]

Description

I've notice significant performance regression while using dekart.xyz (open source data-analytics built on top of deck.gl); Presumably it happens after minor MacOs update. In a same time (same OS and same hardware) Chrome performance is not affected. To reproduce the issue I've created example with H3HexagonLayer (22k rows of data) based on deck.gl provided examples to make sure problem is with deck.gl and not something else. I've added stats.js to show FPS drop

Link to example https://github.com/dekart-xyz/deck.gl/tree/slow-safari/examples/get-started/pure-js/slow-safari

In Safari FPS drops to below 10 when zooming in/out

In Chrome FPS is not affected when zoom in/out

PLEASE NOTE: Safari is 18% worldwide and 35% in US. Currently all deck.gl visualisations are not usable in Safari! I was able to reproduce this issues on 3 different MacBooks

Expected Behavior

No FPS drops when zooming in and zooming out

Repro Steps

• Open Codepen example in Safari 14.1.2
• Zoom in and Zoom out: FPS drop below 10
• A sample of dataset https://raw.githubusercontent.com/dekart-xyz/deck.gl/slow-safari/examples/get-started/pure-js/slow-safari/berlin-pop-density-22k.csv

Environment

• Framework Version: deck.gl@8.5.5
• Browser Version: Safari Version 14.1.2 (16611.3.10.1.6)
• OS: macOS Big Sur 11.5.2 (20G95)
• Hardware : MacBook Pro (16-inch, 2019); 2.6 GHz 6-Core Intel Core i7; 16 GB 2667 MHz DDR4; AMD Radeon Pro 5300M 4 GB; Intel UHD Graphics 630 1536 MB

Logs

Nothing special in logs

[Pessimistress]

When you say "regression", are you comparing to earlier versions of deck.gl, or earlier versions of Safari?

Although Safari is not as good as Chrome in WebGL compatibility and performance, it's not that far off. Something you should try are:

• Make sure experimental WebGL features in Safari are turned off.
• When viewing the deck.gl page, your Mac is using its discrete GPU instead of the integrated one. You can use https://gfx.io/ for this information, and manually force it to use one or another.
• Add the following option to Deck constructor and see if it forces using the discrete GPU:

glOptions: {powerPreference: 'high-performance'}

Safari is 18% worldwide and 35% in US

I do not think so: https://browserslist.dev/?q=PjElIGluIHVz Majority of the Safari traffic is from iOS. The desktop version in particular, share is less than FF and no where near Chrome.

[delfrrr]

@Pessimistress hey thank you for reply

As I said I use app build on top of deck.gl on daily basis, performance in Safari was great. Somewhere mid summer after time off I realised that everything become very slow; I think it's regression after updating to Safari 14.1.1 or 14.1.2 which came with automatic update. I did simple example with deck.gl to localise problem, see links above.

It's does nor reproduce on iOS but does reproduce on 2 other Mac Books I could access to try.

Used browser share from here https://gs.statcounter.com/browser-market-share you are right about mobile, but there is still 18% (second most popular browser)

I will try suggested solution and update here

[delfrrr]

Tried suggested solutions:

• used https://gfx.io/ to witch between Deseret and Integrated card; has no visible effect
• Added glOptions: {powerPreference: 'high-performance'}; Activity Monitor in macOs shows that Safari requires Graphic Card, no impact on performance, see Codepen https://codepen.io/delfrrr/pen/qBjONom
• Only glOptions which has impact is antialias: false

[Pessimistress]

Removing the bug label since this is a not a breakage in our code base. We make our best effort to follow WebGL best practice but the outcome is always bound by the performance of the browser itself. Regarding Safari, it's always been a bit of a moving target, with its lagging-behind support for WebGL specs, and hardware-specific shader compilation bugs as Macs cruised through various chip providers.

I do not have a MacBook myself and I am unable to reproduce the reported issue on my desktop. If a localized performance bottleneck in Safari could be identified, we would patch it as long as the impact to other platforms is low. I suspect it's not worth the effort to investigate given that Safari 15 is coming in a few weeks with a reengineered WebGL engine.

Thank you for bringing this to our attention but I do not see a clear action item at this moment.

[Pessimistress]

Actually, can you share the information that you see in https://webglreport.com/?v=1 in Safari?

[delfrrr]

Results from https://webglreport.com/?v=1

Platform: | MacIntel
-- | --
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Safari/605.1.15
webgl
WebGL 1.0
WebGL GLSL ES 1.0 (1.0)
WebKit
WebKit WebGL
Apple Inc.
Apple GPU
Available
No
No

Supported Extensions:
--
  | EXT_blend_minmax
  | EXT_sRGB
  | EXT_frag_depth
  | OES_texture_float
  | OES_texture_float_linear
  | OES_texture_half_float
  | OES_texture_half_float_linear
  | OES_standard_derivatives
  | EXT_shader_texture_lod
  | EXT_texture_compression_rgtc
  | EXT_texture_filter_anisotropic
  | OES_vertex_array_object
  | OES_element_index_uint
  | OES_fbo_render_mipmap
  | WEBGL_lose_context
  | WEBGL_compressed_texture_s3tc
  | WEBGL_compressed_texture_s3tc_srgb
  | WEBGL_depth_texture
  | WEBGL_draw_buffers
  | ANGLE_instanced_arrays
  | WEBGL_debug_shaders
  | WEBGL_debug_renderer_info
  | EXT_color_buffer_half_float
  | EXT_float_blend
  | WEBGL_color_buffer_float
  | KHR_parallel_shader_compile

[delfrrr]

@Pessimistress performance in Safari 15 unfortunately is the same

[Pessimistress]

It seems that the problem applies to all WebGL applications:

https://discourse.threejs.org/t/horrible-3d-three-js-performance-in-latest-safari-on-macos/25940/10

I understand how frustrating this issue is for you, but at this moment it's not clear to me what we can do to make it better. Some steps you can take to narrow in on the problem are:

• Remove Mapbox from your Codepen and test with deck.gl alone
• Run the examples on threejs.org and see which ones show the biggest perf discrepancy between Chrome & Safari. deck.gl particularly utilizes instanced rendering, and that has seen some regression on iPhone 12: https://github.com/visgl/deck.gl/issues/5101

If you can find that e.g. some layers work better than others, or even some other libraries work better, then we may be able to identify a work around. However, if WebGL performance in Safari all across the board is low, then it's not something we can fix in JavaScript, and you should really report it as a bug to WebKit.

[delfrrr]

@Pessimistress

• codepen without Mpabox https://codepen.io/delfrrr/pen/jOwBXxG?editors=0110 (same slow perf)
• also Mapbox and Google Maps work fast on it's own

found one example with same big difference https://threejs.org/examples/#webgl_animation_keyframes when zoom in close to house, fps drop a lot in safari, same as deck.gl vis;

other example seems fine (60 FPS)

I did file a bug to Safari (https://webkit.org/reporting-bugs/ says Safari is not WebKit) 10 days ago; latest WebKit release crashes on my laptop

[Pessimistress]

cc @ibgreen and @alasarr I am unable to reproduce this with either Safari 14.1 or 15.0 TP, though I have a somewhat unusual setup (Mac Mini + eGPU). I find the reported issue a little sus considering it's not even that many instances. I'd be interested to see if anyone else is experiencing the same.

[kylebarron]

I updated my Safari to 14.1.2 and can reproduce with the original codepen (https://codepen.io/delfrrr/pen/oNwgrNw). Safari is quite significantly slower than Chrome when zooming in and out. This persists even when forcing the discrete GPU with gfx.io. (I forgot to test with the previous 14.0.x version of Safari I had installed previously).

Versions:

macOS Big Sur 11.5.2

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro16,1
  Processor Name:   8-Core Intel Core i9
  Processor Speed:  2.3 GHz
  Number of Processors: 1
  Total Number of Cores:    8
  L2 Cache (per Core):  256 KB
  L3 Cache: 16 MB
  Hyper-Threading Technology:   Enabled
  Memory:   16 GB

Graphics cards:

Intel UHD Graphics 630
AMD Radeon Pro 5500M

[Pessimistress]

With your test repo, can you try clearing the lock file and pull the latest @luma.gl/* dependencies (8.5.7)?

The pre-bundled version does not include the latest changes.

[delfrrr]

@Pessimistress tested with @luma 8.5.7; there is no difference

I could localise issue better and understand why I did not observe it before in Safari! Apparently problem was with dataset: after update it has many duplicates (~4 per each H3 index) and for some reason deck.gl is very slow in Safari when there are multiple hexagons with same index:

• Same vis with removed duplicates ~2k points, performance is ok https://codepen.io/delfrrr/pen/MWoQxKJ?editors=0010
• 75k hexagons without duplicates, performance is ok https://play.dekart.xyz/reports/01e8e26e-31c9-491f-9584-8c2c244dccf7 (proves that problem is not with number of hexagons but with multiple hex with same index)

[Pessimistress]

Interesting discovery... could you try adding parameters: {blend: false} to the layer + dataset with duplicates and see if it makes a difference?

[delfrrr]

I would not say blend: false does difference (maybe small one), but

  parameters: {
    blend: false,
    depthTest: false
  },

makes it at least 2-3x faster; still laggy but almost usable

[delfrrr]

also please not that issue reproduced when you zoom in closely and does not when you zoom out

performance ok

Performance not ok