Bug 137842 - REGRESSION(r174107): [EFL] WebGL broken
Summary: REGRESSION(r174107): [EFL] WebGL broken
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on: 144247
  Show dependency treegraph
Reported: 2014-10-17 19:22 PDT by Carlos Alberto Lopez Perez
Modified: 2017-03-11 10:35 PST (History)
9 users (show)

See Also:

Using Xorg driver for WTR until fix the GL issue on xvfb driver. (1.08 KB, patch)
2015-04-26 19:23 PDT, Hunseop Jeong
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Alberto Lopez Perez 2014-10-17 19:22:07 PDT
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.
Comment 1 Csaba Osztrogonác 2014-11-03 01:57:09 PST
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.
Comment 2 Csaba Osztrogonác 2014-11-26 04:04:00 PST
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?
Comment 3 Csaba Osztrogonác 2014-12-02 05:05:07 PST
Can we get a feedback from EFL maintainers if WebGL is supported / important?
Comment 4 Csaba Osztrogonác 2014-12-05 07:33:54 PST
Comment 5 Gyuyoung Kim 2014-12-07 17:19:19 PST
(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.
Comment 6 Jinwoo Song 2014-12-07 17:43:44 PST
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/
Comment 7 Csaba Osztrogonác 2014-12-08 02:27:44 PST
(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?
Comment 8 Csaba Osztrogonác 2014-12-08 03:14:45 PST
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.
Comment 9 Gwang Yoon Hwang 2014-12-08 03:24:00 PST
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.

Comment 10 Csaba Osztrogonác 2014-12-08 10:52:41 PST
The problem is come from elementary/src/lib/elm_win.c:

static Eina_Bool
   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;
                  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.
Comment 11 Carlos Alberto Lopez Perez 2014-12-09 10:20:04 PST
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)
Comment 12 Csaba Osztrogonác 2015-01-08 14:49:29 PST
Any plan to make WebGL work out-of-the-box without magic environment variable hacks?
Comment 13 Csaba Osztrogonác 2015-01-14 01:33:22 PST
Comment 14 Csaba Osztrogonác 2015-02-26 03:34:34 PST
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.
Comment 15 Gyuyoung Kim 2015-04-24 02:38:50 PDT
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.
Comment 16 Hunseop Jeong 2015-04-26 19:23:47 PDT
Created attachment 251719 [details]
Using Xorg driver for WTR until fix the GL issue on xvfb driver.
Comment 17 Gyuyoung Kim 2015-06-15 18:31:16 PDT
(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.
Comment 18 Michael Catanzaro 2017-03-11 10:35:45 PST
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.