Bug 137842

WebGL tests are skipped since 7+ months: https://trac.webkit.org/changeset/167345 , so I'm not sure if it is important for EFL port nowadays.

WebGL is still broken with the latest EFL too. Any plan to fix it? If it isn't imporant / supported to have working WebGL with EFL, why not simple disable building it?

Can we get a feedback from EFL maintainers if WebGL is supported / important?

ping?

(In reply to comment #3) > Can we get a feedback from EFL maintainers if WebGL is supported / important? I think WebGL is important to us. Besides Tizen also has supported WebGL based on WebKit. Let me check if after finishing my local work.

FYI, in my local environment, webGL runs well with latest code. I'm using ubuntu 13.10 and NVIDIA driver. ELM_ENGINE=opengl_x11 ./MiniBrowser http://get.webgl.org/

(In reply to comment #6) > FYI, in my local environment, webGL runs well with latest code. > I'm using ubuntu 13.10 and NVIDIA driver. > > ELM_ENGINE=opengl_x11 ./MiniBrowser http://get.webgl.org/ Ah, one more magic environment variable. It really works. Thanks. But it worked out-of-the-box previously - with EFL 1.10, but something changed with 1.11, and now we need this magic. We already tried the -e option of MiniBrowser, but it doesn't work, only this env magic helps. Can't we make it work out-of-the-box somehow?

I checked, MiniBrowser calls elm_config_preferred_engine_set("opengl_x11") by default if we don't pass -e command line argument. Something must be changed in elementary between 1.10 and 1.11.

For me, I couldn't use evas_gl backend without EVAS_GL_NO_BLACKLIST environment. As you can see, several GPUs are blacklisted (including llvm!), I cannot run WebKitEFL with OpenGL acceleration using out-of-box. https://github.com/kakaroto/e17/blob/master/evas/src/modules/engines/gl_x11/evas_x_main.c

The problem is come from elementary/src/lib/elm_win.c: ... static Eina_Bool _accel_is_gl(void) { const char *env = NULL; const char *str = NULL; if (_elm_config->accel) str = _elm_config->accel; if (_elm_accel_preference) str = _elm_accel_preference; if ((_elm_config->accel_override) && (_elm_config->accel)) str = _elm_config->accel; env = getenv("ELM_ACCEL"); if (env) str = env; if ((str) && ((!strcasecmp(str, "gl")) || (!strcasecmp(str, "opengl")) || (!strcasecmp(str, "3d")) || (!strcasecmp(str, "hw")) || (!strcasecmp(str, "accel")) || (!strcasecmp(str, "hardware")) )) return EINA_TRUE; return EINA_FALSE; <-------------- BANG!!! } ... else if ((getenv("DISPLAY")) && (!getenv("ELM_ENGINE"))) { if (_accel_is_gl()) { enginelist[0] = ELM_OPENGL_X11; enginelist[1] = ELM_SOFTWARE_X11; enginelist[2] = NULL; } else { enginelist[0] = ELM_SOFTWARE_X11; < -------- BANG !!!!! enginelist[1] = ELM_OPENGL_X11; enginelist[2] = NULL; } } ... To put ELM_OPENGL_X11 in the first place, we should set the ELM_ENGINE environment variable automatically for MiniBrowser and WebKitTestrunner too, or make _accel_is_gl() is true with setting ELM_ACCEL env or elm_config_accel_preference_set("opengl") or something different API call, which modifies _elm_accel_preference and _elm_config->accel_override. Additional problem is to run webgl tests. EFL /elementary / whatever else disables gl if we use xvfb. We shouldn't do it or should have a dedicated tester machine with DISABLE_XVFB_DRIVER=1 environment variable.

I don't know why upstream (EFL) disables GL at the first shot. I guess they have a good reason, it would be nice to know that reason. But at least on the WebKitEFL jhbuild I guess some patches are needed to ensure that it runs with GL support enabled even when using the LLVM pipe software rasterizer (the one that is used with xvfb for the tests)

Any plan to make WebGL work out-of-the-box without magic environment variable hacks?

ping?

I skipped these tests properly in http://trac.webkit.org/changeset/180670. Please unskip once WebGL works out of the box on the EFL bot.

Currently openGL only works on EFL MiniBrowser. It isn't supported by EFL WebKitTestRunner. According to our investigation, EFL seems to only support openGL backend when using elementary. That's why EFL MiniBrowser is able to use openGL. - https://lists.webkit.org/pipermail/webkit-dev/2015-April/027391.html To fix this problem, we may need to fix EFL itself, or make WKR to use Elementary.

Created attachment 251719 [details] Using Xorg driver for WTR until fix the GL issue on xvfb driver.

(In reply to comment #16) > Created attachment 251719 [details] > Using Xorg driver for WTR until fix the GL issue on xvfb driver. When we enable USE_NATIVE_XDISPLAY, too many flaky tests have been generated. When using it, WTR compares image buffer during layout test (I don't know why WTR compare image buffer when enabling the USE_NATIVE_XDISPLAY yet). However test results are different during the two test cycles. That's why there are too many flaky tests on EFL bot.

Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.