Closed Bug 772457 Opened 8 years ago Closed 8 years ago
Remove compile-time option to disable ANGLE, replace it by an option to disable Web
GL altogether (also disabling ANGLE)
The --disable-angle --enable-webgl build setting doesn't make sense (WebGL really needs ANGLE) and has been broken inadvertently in bug 760323 (It's not tested). It's a better idea to just have a single --enable-webgl option (which is tested, as Thunderbird builds with WebGL disabled). The only problem is I just realized that WebRTC has started to depend on d3dx9 which is a DLL that we only ship if ANGLE (i.e. if WebGL) is enabled. http://mxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/src/modules/video_render/main/source/windows/video_render_direct3d9.h -> WebRTC team, plz warn me next time! So with this change, WebGL will become a build-time dependency for WebRTC, which IMO is quite OK since the code size increase from enabling WebGL is very small compared to the code size of that d3dx9 DLL anyway (2M). Also, we have a definite plan to stop shipping that DLL in the ANGLE makefiles (bug 741742) so if WebRTC wants to still use them, it will have to carry over the build-system work that we do currently for ANGLE (see configure.in and gfx/angle/Makefile.in). Anyway, it shouldn't block us from doing what makes the most sense for the build-system around WebGL.
Also, WebRTC: if you're using d3dx9, you'll run into exactly the same issue as bug 760323 with the WebRT apps and you'll have to preload this library manually for it to be found by WebRT apps.
In fact the bustage in 760323 was not about --disable-angle, it was about --disable-webgl. But I still think that we should do that.
No longer blocks: 760323
Turns out that there is *no* --disable-webgl option! That's what we want to fix here.
Summary: Remove compile-time option to disable ANGLE (but keep the option to disable WebGL, which also disables ANGLE) → Remove compile-time option to disable ANGLE, replace it by an option to disable WebGL altogether (also disabling ANGLE)
This new version replaces MOZ_ANGLE by MOZ_ANGLE_RENDERER in remaining places. (Indeed MOZ_ANGLE was poorly named since it only controls whether we want the GLES-ON-D3D stuff)
Updated the error messages to stop pointing people to the now-removed --disable-angle option.
So, what is left for us to do for WebRTC? (Not knowing the interactions between GL, ANGLE, and dx*.) If we need to pref something on by default if webrtc is prefed on, or pref off WEBRTC, or warn that they should be, let me know. WebRTC may not need the dx9 renderer in the long term, as we'll be rendering to 'external' source (i.e. passing decoded data to a MediaStream that feeds to a <video> element). The code has internal renderers so it can run stand-alone as well.
Most importantly you should evaluate whether you really need d3dx9. If you really need d3dx9: - either you declare officially that WebGL is a build-time dependency for WebRTC i.e. --disable-webgl should also disable WebRTC at build time; - or you edit the build system so that we ship d3dx9_??.dll as long as WebRTC is enabled at build-time. Currently, we only ship it if WebGL is enabled at build time, which is the default, but can be disabled by --disable-webgl. By "currently" I mean "with my patches here". If you do not really need d3dx9, remove the #include at http://mxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/src/modules/video_render/main/source/windows/video_render_direct3d9.h and then you don't have anything to worry about.
Note that if you go down the route of editing the build system, the system-detection stuff is in configure.in (search for D3DX9) and the code actually extracting the DLL from the CAB archive is in gfx/angle/Makefile.in.
Comment on attachment 640766 [details] [diff] [review] add --disable-webgl, remove --disable-angle, clean up configure.in Looks good to me..
Attachment #640766 - Flags: review?(vladimir) → review+
Assignee: nobody → bjacob
Target Milestone: --- → mozilla16
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.