Thoughts on Electron's off-screen rendering support

Hi folks,

I was playing around today with trying to get the reference viewer branch of this project running in headless mode. I couldn’t get any output at all, and after a fair bit of digging I found in threads such as https://github.com/cypress-io/cypress/issues/1194 and others the suggestion that Electron is unable to offer this ability under Linux, or indeed in any non-hardware-accelerated environment. Does this sound right to you? That would be unfortunate for those of us who have hopes of running this as part of pipelines on back-end systems.

That thread is about a Docker environment, which might be confounding the issue. The actual symptom for me is that canvas.getContext('webgl') hangs indefinitely.

There is a tutorial page at https://github.com/electron/electron/blob/6f91af93433df4e9c0e7fb592e5b2dcb0b1c7888/docs/tutorial/offscreen-rendering.md which suggests that software rendering should work. I tried their app.disableHardwareAcceleration() suggestion, but then canvas.getContext('webgl') (and experimental-webgl) just return null.

It’s always possible there’s something peculiar about my system setup. Have you run into this at all?

[donmccurdy]

Spent a while hacking on this yesterday. I didn’t get the existing headless mode working, but running things in electroshot (https://github.com/mixu/electroshot/) at least let me write a shell script to output matching images, launching the browser programmatically.

I’m strongly inclined to say that the UI portions of the reference viewer should be left to either (a) demo code, or (b) a separate distributed package from the viewer itself. Roughly:

• demo/ui/
  • gui controls
  • managing list of available models
  • managing list of available environments
• src/
  • takes a single model as input (URL or ArrayBuffer)
  • takes configuration options as parameters; no UI
  • takes <canvas/> as a parameter; renders into it

With the core library accepting a canvas as a parameter, it is possible for end-users to pass an emulated canvas (like headless-gl) in Node.js contexts. Any such headless context may have limited portability to different operating systems, but that’s likely something that end-users of the viewer can deal with.

I’d suggest that only the (non-UI) src/* portion should be published to NPM. We could optionally put the UI on NPM as a separate package, but I think that’s probably out of scope for now.

[ghost]

I don’t know about the original post, but that it didn’t work on MacOS recently was reproducible and fixable for me.