Selenium with Cesium

CesiumJS
1

Hi,

I work on the Onesky team. I am creating automated tests to test our app that uses Cesium, but I am having trouble getting around a speed problem I have with Cesium and headless browsers.

Cesium works perfectly with Selenium tests with a non-headless browser, but when switched to headless, Selenium takes up to 10x as long to run the same tests in Chrome headless as Chrome non-headless. It also doesn’t function at all in Firefox headless. This slowness can cause erroneous errors as well. I have confirmed this is an issue with Cesium because we do not see the problem on any test that does not involve the Cesium globe loading.

I am wondering if you run automated tests against Cesium in a different way that I could consider switching too, or know a way to configure the driver capabilities to get around this.

I am currently using Selenium standalone with webdriverio and mocha.

2

Welcome to the Cesium forum John!

CesiumJS uses Jasmine for automated testing. This is documented a bit here: https://github.com/CesiumGS/cesium/blob/master/Documentation/Contributors/TestingGuide/README.md#running-the-tests. Have you tried running that on the same machine to compare the performance? I think most of the tests there create like a very small canvas when rendering to speed things up.

Have you had a chance to try it out with any other WebGL libraries? I’m curious if this slowness is in the way you’re setting up the canvas/running WebGL inside Selenium. Another thing the CesiumJS unit tests do is re-use a scene/canvas instead of creating and destroying it across some tests.

If you are able to share some kind of minimally reproducible environment (maybe as a GitHub repo), I’d be curious to take a look since it’s not an uncommon question.

3

Hi Omar, thanks for the quick reply.

I haven’t explored running that Jasmine test on my machine, but I was able to put together a minimally reproducible test for you to try. I think it is probably the way I’m setting up the canvas/running WebGL as you stated. I setup this repo and my coworker and I both tested and saw that headless mode caused about a 2.5x increase in test time. You can turn headless mode on and off by commenting it in the chrome config.capabilities sections of cesiumForum10502/wdio.conf.js. I also added homepage.js which tests the onesky homepage which does not include any WebGL and is not affected running headless or non-headless. You can run this test by commenting out the threejs line in config.specs and uncommenting the homepage line.

Let me know if you’re able to run it and get the same results. I am wondering how to make a smaller cesium canvas display while still maintaining visibility of the rest of the app.

4

Hi Cesium,

I am wondering if anyone has had time to take a look at this. I am still experiencing the issue and have tried several methods to fix it, but have ended up only getting it to work quickly when I am in non-headless mode.

5

I haven’t had a chance to investigate more but I noticed your browser resolution is quite high:

browser.setWindowSize(1920,1040);

What happens if you half that (or make it 200x100 or something) ? Another Cesium specific thing is just decreasing the viewer.resolutionScale. Setting that to 0.5 means it’ll render at the same window size but half the canvas size and scale it up.

I suspect the issue is that there is just some overhead in initiating a WebGL canvas/the browser for test, and as long as you can re-use as much resources as you can, it should spread out that cost across all the tests. For example, in the CesiumJS tests here, a scene is created just once for all tests in this file:

So only a single canvas is used for all those tests.