yukinying / chrome-headless-browser-docker

Continuously building Chrome Docker image for Linux.
https://store.docker.com/community/images/yukinying/chrome-headless-browser/tags
Apache License 2.0
369 stars 53 forks source link

WebGL disabled in chrome-headless-browser-stable image #47

Open divlek opened 2 years ago

divlek commented 2 years ago

I have a requirement to take visual regression snapshots for pages that need WebGL enabled, in both Apple M1 machines and in Linux (for CI/CD). This image yukinying/chrome-headless-browser-stable seems to be suitable for both. But I'm encountering an issue with WebGL not being enabled by default.

Steps to reproduce

  1. Run docker pull yukinying/chrome-headless-browser-stable:latest
  2. Run docker run -it --privileged -p 9222:9222 yukinying/chrome-headless-browser-stable:latest sh
  3. In chrome://inspect, under remote target -> launched this URL https://webglreport.com/ which shows WebGL not enabled.
image image

The same steps work fine with the latest yukinying/chrome-headless-browser image. WebGL seems to be enabled by default. Screenshots below :-

image image

Wondering what could be the issue with yukinying/chrome-headless-browser-stable image. Appreciate any input on this.

yukinying commented 2 years ago

I don't have in depth knowledge on this. My thought is that the docker container run chrome with --disable-gpu option, and that may be disabling WebGL. But both containers are using the same flag, so it can also be a case that the flag is behaving differently in different CPU arch.

I would suggest you repeat the experiment with different chrome flag, which can be overriden with docker entrypoint, and see if those flags are causing trouble or not.

divlek commented 2 years ago

I tried tweaking the entry point with different chromeFlag setting (removed --disable-gpu flag as well) as below, still WebGL is not getting enabled for the yukinying/chrome-headless-browser-stable image. Also tried different values as defined in the chromium code. Found no luck.

ENTRYPOINT ["/usr/bin/dumb-init", "--", \
            "/usr/bin/google-chrome", \           
            "--headless", \
            "--in-process-gpu", \           
            "--use-cmd-decoder=validating",\
            "--enable-unsafe-webgpu", \           
            "--use-gl=angle", \
            "--use-angle=swiftshader", \
            "--ignore-gpu-blocklist", \
            "--disable-dev-shm-usage", \
            "--remote-debugging-address=0.0.0.0", \
            "--remote-debugging-port=9222", \
            "--user-data-dir=/data"]

Noticed that even without adding any additional flags yukinying/chrome-headless-browser:latest has WebGL enabled. I think chromium latest version has this enabled by default. But for some reason image supporting arm64 architecture is having some issue with enabling this.

yukinying commented 2 years ago

Yeah it looks like a chrome issue with the cpu arch. If you are able to find the right setting, I am happy to put the right flag to the Docker file entrypoint.

gidztech commented 1 year ago

@divlek Using yukinying/chrome-headless-browser image (instead of stable) which has WebGL enabled, is it actually rendering the canvas for you. I tried switching to that image for visual snapshot tests and I get a blank screen. I've not figured out what flag I'm missing or if the base image needs some libraries.

divlek commented 1 year ago

@gidztech Yes, I tried yukinying/chrome-headless-browser:latest in Mac intel chip machine (linux/amd64) it renders the canvas just fine. (Side note:- using loki as visual regression framework)

The same setup doesn't work in Mac M1 machine, so was trying to use yukinying/chrome-headless-browser-stable that supports Apple M1 environment. Tried using all the flags that I listed above (covered all possibilities in chromium code), but WebGL is not getting enabled. :(

As you said there could be potentially some libraries missing from base image to support this in yukinying/chrome-headless-browser-stable and it is not flag-related.

Appreciate if anyone has any input on solving this problem, as it is currently blocking the team from switching to M1 machines. Thank you!