137842 2014-10-17 19:22:07 -0700 REGRESSION(r174107): [EFL] WebGL broken 2017-03-11 10:35:45 -0800 1 1 1 Unclassified WebKit WebKit EFL 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX https://bugs.webkit.org/show_bug.cgi?id=143561 P2 Normal --- 144247 1 clopez webkit-unassigned gyuyoung.kim hs85.jeong jinwoo7.song lucas.de.marchi mcatanzaro mtiborinf ossy ryuan.choi yoon oldest_to_newest 1042546 0 clopez 2014-10-17 19:22:07 -0700 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. 1045689 1 ossy 2014-11-03 01:57:09 -0800 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. 1051064 2 ossy 2014-11-26 04:04:00 -0800 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? 1051804 3 ossy 2014-12-02 05:05:07 -0800 Can we get a feedback from EFL maintainers if WebGL is supported / important? 1052726 4 ossy 2014-12-05 07:33:54 -0800 ping? 1053252 5 gyuyoung.kim 2014-12-07 17:19:19 -0800 (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. 1053255 6 jinwoo7.song 2014-12-07 17:43:44 -0800 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/ 1053333 7 ossy 2014-12-08 02:27:44 -0800 (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? 1053339 8 ossy 2014-12-08 03:14:45 -0800 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. 1053342 9 yoon 2014-12-08 03:24:00 -0800 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 1053438 10 ossy 2014-12-08 10:52:41 -0800 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. 1053835 11 clopez 2014-12-09 10:20:04 -0800 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) 1059961 12 ossy 2015-01-08 14:49:29 -0800 Any plan to make WebGL work out-of-the-box without magic environment variable hacks? 1061121 13 ossy 2015-01-14 01:33:22 -0800 ping? 1072333 14 ossy 2015-02-26 03:34:34 -0800 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. 1088207 15 gyuyoung.kim 2015-04-24 02:38:50 -0700 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. 1088906 16 251719 hs85.jeong 2015-04-26 19:23:47 -0700 Created attachment 251719 Using Xorg driver for WTR until fix the GL issue on xvfb driver. 1102113 17 gyuyoung.kim 2015-06-15 18:31:16 -0700 (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. 1286281 18 mcatanzaro 2017-03-11 10:35:45 -0800 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. 251719 2015-04-26 19:23:47 -0700 2015-04-26 19:23:47 -0700 Using Xorg driver for WTR until fix the GL issue on xvfb driver. Xorg.patch text/plain 1105 hs85.jeong ZGlmZiAtLWdpdCBhL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvcG9ydC9lZmwucHkgYi9Ub29scy9T Y3JpcHRzL3dlYmtpdHB5L3BvcnQvZWZsLnB5CmluZGV4IDNjODkyMTkuLjkxOTVhYjIgMTAwNjQ0 Ci0tLSBhL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvcG9ydC9lZmwucHkKKysrIGIvVG9vbHMvU2Ny aXB0cy93ZWJraXRweS9wb3J0L2VmbC5weQpAQCAtMzIsNiArMzIsNyBAQCBpbXBvcnQgb3MKIGZy b20gd2Via2l0cHkubGF5b3V0X3Rlc3RzLm1vZGVscy50ZXN0X2NvbmZpZ3VyYXRpb24gaW1wb3J0 IFRlc3RDb25maWd1cmF0aW9uCiBmcm9tIHdlYmtpdHB5LnBvcnQuYmFzZSBpbXBvcnQgUG9ydAog ZnJvbSB3ZWJraXRweS5wb3J0LnB1bHNlYXVkaW9fc2FuaXRpemVyIGltcG9ydCBQdWxzZUF1ZGlv U2FuaXRpemVyCitmcm9tIHdlYmtpdHB5LnBvcnQueG9yZ2RyaXZlciBpbXBvcnQgWG9yZ0RyaXZl cgogZnJvbSB3ZWJraXRweS5wb3J0Lnh2ZmJkcml2ZXIgaW1wb3J0IFh2ZmJEcml2ZXIKIGZyb20g d2Via2l0cHkucG9ydC5saW51eF9nZXRfY3Jhc2hfbG9nIGltcG9ydCBHREJDcmFzaExvZ0dlbmVy YXRvcgogCkBAIC00OSw2ICs1MCw4IEBAIGNsYXNzIEVmbFBvcnQoUG9ydCk6CiAKICAgICAgICAg c2VsZi5fcHVsc2VhdWRpb19zYW5pdGl6ZXIgPSBQdWxzZUF1ZGlvU2FuaXRpemVyKCkKIAorICAg ICAgICBvcy5lbnZpcm9uWydVU0VfTkFUSVZFX1hESVNQTEFZJ10gPSAnMScKKwogICAgIGRlZiBf cG9ydF9mbGFnX2Zvcl9zY3JpcHRzKHNlbGYpOgogICAgICAgICByZXR1cm4gIi0tZWZsIgogCkBA IC05OCw2ICsxMDEsOCBAQCBjbGFzcyBFZmxQb3J0KFBvcnQpOgogICAgIGRlZiBfZHJpdmVyX2Ns YXNzKHNlbGYpOgogICAgICAgICBpZiBvcy5lbnZpcm9uLmdldCgiRElTQUJMRV9YVkZCX0RSSVZF UiIpOgogICAgICAgICAgICAgcmV0dXJuIFBvcnQuX2RyaXZlcl9jbGFzcyhzZWxmKQorICAgICAg ICBpZiBvcy5lbnZpcm9uLmdldCgiVVNFX05BVElWRV9YRElTUExBWSIpOgorICAgICAgICAgICAg cmV0dXJuIFhvcmdEcml2ZXIKICAgICAgICAgcmV0dXJuIFh2ZmJEcml2ZXIKIAogICAgIGRlZiBf cGF0aF90b19kcml2ZXIoc2VsZik6Cg==