Agisoft: Larger model in Cesium ion loading slower in Mozilla Firefox than Google Chrome

[muthusampath]

Example: https://cesium.com/ion/stories/viewer/?id=70b05989-eb6a-435b-8a65-021a633c888c

Browser: Firefox 92.0

Operating System: Windows 10 (Intel UHD Graphics 750)

Notes: Observed similar behavior in Firefox under Ubuntu with NVIDIA graphics card

Here are results of the webglreport.com:

Platform: Win32

Browser User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Context Name: webgl

GL Version: WebGL 1.0

Shading Language Version: WebGL GLSL ES 1.0

Vendor: Mozilla

Renderer: ANGLE (Intel(R) HD Graphics 400 Direct3D11 vs_5_0 ps_5_0)

Unmasked Vendor: Google Inc.

Unmasked Renderer: ANGLE (Intel(R) HD Graphics 400 Direct3D11 vs_5_0 ps_5_0)

Antialiasing: Available

ANGLE: Yes, D3D11

Major Performance Caveat: No

Vertex Shader

Max Vertex Attributes: 16

Max Vertex Uniform Vectors: 4096

Max Vertex Texture Image Units: 16

Max Varying Vectors: 30

Best float precision: [-2127, 2127] (23)

Transform Feedback

Coming in WebGL 2

Rasterizer

Aliased Line Width Range: [1, 1]

Aliased Point Size Range: [1, 1024]

Fragment Shader

Max Fragment Uniform Vectors: 1024

Max Texture Image Units: 16

float/int precision: highp/highp

Best float precision: [-2127, 2127] (23)

Framebuffer

Max Color Buffers: 8

RGBA Bits: [8, 8, 8, 8]

Depth / Stencil Bits: [24, 8]

Max Render Buffer Size: 16384

Max Viewport Dimensions: [32767, 32767]

Textures

Max Texture Size: 16384

Max Cube Map Texture Size: 16384

Max Combined Texture Image Units: 32

Max Anisotropy: 16

Uniform Buffers

Coming in WebGL 2

Supported Extensions:

          ANGLE_instanced_arrays

          EXT_blend_minmax

          EXT_color_buffer_half_float

          EXT_float_blend

          EXT_frag_depth

          EXT_shader_texture_lod

          EXT_sRGB

          EXT_texture_compression_bptc

          EXT_texture_compression_rgtc

          EXT_texture_filter_anisotropic

          OES_element_index_uint

          OES_fbo_render_mipmap

          OES_standard_derivatives

          OES_texture_float

          OES_texture_float_linear

          OES_texture_half_float

          OES_texture_half_float_linear

          OES_vertex_array_object

          WEBGL_color_buffer_float

          WEBGL_compressed_texture_s3tc

          WEBGL_compressed_texture_s3tc_srgb

          WEBGL_debug_renderer_info

          WEBGL_debug_shaders

          WEBGL_depth_texture

          WEBGL_draw_buffers

          WEBGL_lose_context

[mramato]

From the "something obvious" departement, it's pretty clear that Firefox is simply a slower browser when it comes to executing Cesium's JavaScript code. Opening the same scene in Chrome vs Firefox produces the same number of requests, same number of tiles and data transfered, same resulting image. It's just way slower.

Firefox does have some WebGL warnings in the console output so there is a chance that something is happening on the WebGL side that is causing a slower frame rate which transfers to slower tile loading due to time slicing.

• I'd suggest profiling JS performance first to see if there's anything obvious.
• Turning on WebGL validation may expose some issues?
• I don't think this is directly related to 3D Tiles, CWT is also slower, but we should confirm.

There's still a non-trivial chance that the answer is "Firefox is just slower", but we should prove it and write up issues in their bug tracker if so.

[lilleyse]

One recent improvement to note here is that Firefox 93 shipped with support for the imageOrientation flag for ImageBitmap which means we can now take advantage of ImageBitmap on Firefox. If you upgrade to Firefox 93 you should see less frame rate hitches when loading images of all kinds (Bing Maps, textured 3D Tiles, etc).

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/93

But everything that @mramato said is still relevant too.

[mramato]

And just for clarification, my testing was on Firefox 93 so it was likely even slower before that.

I'm not sure if FF performance charts are that different than Chrome, but an initial quick test showed ~43% of the time being spent in the DOM, which sounds really wrong. One stab in the dark would be if we are doing anything (such as getting client bounding width) every frame in a way that causes continuous reflow in FF and therefore abysmal performance.

But like I said, that's a stab in the dark. Whoever looks into this should do a full analysis before trying to change anything.