Bug 137842 – REGRESSION(r174107): [EFL] WebGL broken

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit EFL

[Carlos Alberto Lopez Perez]

Revision r174107 <http://trac.webkit.org/r174107> updated the EFL libraries used by WebKitEFL to a major new version. WebGL support is broken since that.

On the terminal, I get "evas_gl_new() Evas GL engine not available." errors.

I'm using the internal jhbuild, and I execute the minibrowser as follows:

$ cd WebKit
$ LD_LIBRARY_PATH=$(pwd)/WebKitBuild/Dependencies/Root/lib WebKitBuild/Release/bin/MiniBrowser http://get.webgl.org/

When it loads, the page says "Your browser supports WebGL", *but* the cube don't shows.

I also tried https://webglsamples.googlecode.com/hg/aquarium/aquarium.html and it don't shows any fish on the screen (however it still reports the number of fps despite only showing a grey screen)

I tested to revert r174107, then I wiped out WebKitBuild/Dependencies and rebuilt all the jhbuild dependencies (Tools/Scripts/update-webkitefl-libs), and tried the test again. Now it works as expected in both tests.

For the record: I tried this on two machines. One with a Nvidia GPU and the proprietary drivers, and another one with an Intel GPU (sandybridge) and the free Mesa drivers (both machines running Debian testing). The same result on both machines: WebGL is broken, but reverting r174107 fixes it.

[Csaba Osztrogonác]

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.

[Csaba Osztrogonác]

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?

[Csaba Osztrogonác]

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

[Csaba Osztrogonác]

ping?

[Gyuyoung Kim]

(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.

[Jinwoo Song]

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/

[Csaba Osztrogonác]

(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?

[Csaba Osztrogonác]

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.

[Gwang Yoon Hwang]

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

[Csaba Osztrogoná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.

[Carlos Alberto Lopez Perez]

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)

[Csaba Osztrogonác]

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

[Csaba Osztrogonác]

ping?

[Csaba Osztrogonác]

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.

[Gyuyoung Kim]

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.

[Hunseop Jeong]

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

[Gyuyoung Kim]

(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.

[Michael Catanzaro]

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.