583838 - use ANGLE if available for WebGL under D3D

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We should be able to use ANGLE for rendering WebGL if we don't have OpenGL or if going through D3D would result in better overall performance (due to d3d compositing).  This bug sets things up so that if libEGL.dll and libGLESv2.dll are found, they will optionally be used.  It does /not/ set up a full build of ANGLE inside our tree; for various reasons, that might not be possible, but that's work for a followup bug.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 1 - add EXT_texture_format_BGRA8888 extension to ANGLE

Submitted upstream as http://code.google.com/p/angleproject/issues/detail?id=21

This greatly improves ReadPixels and TexImage2D performance on windows with the native image byte order.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 2 - build EGL on windows and use ANGLE if present

The bulk of the work.  This patch does a few things:

- Builds the EGL backend on Win32, including build fixes there (adding GLAPIENTRY so that we have the right calling convention).  On Win32, only offscreen contexts are supposed for EGL.

- Adds a "known extension" API to GLContext, so that we can quickly check for things like EXT_texture_format_BGRA8888/EXT_bgra/etc. and can do it inside rendering code as well instead of needing to store the results all over the place.

- Adds code to WebGL to try the EGL provider if the default one fails on Win32, or to use EGL first if MOZ_WEBGL_PREFER_EGL is set in the environment.

If the angle DLLs are dropped in to the firefox bin directory, they'll be found and used.  This seems to work well on the computers I've tested it on (via PREFER_EGL) and on intel-only computers where ANGLE is the only thing that would work.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 462161 [details] [diff] [review]
part 2 - build EGL on windows and use ANGLE if present

Looks good as far as I can see!

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 3 - find ANGLE as an addon

Use category set by the ANGLE addon to find the DLL.

Comment 5

[Dave Townsend [:mossop]]

Comment on attachment 463335 [details] [diff] [review]
part 3 - find ANGLE as an addon

I think you want to create an nsILocalFile and initialise it with that path and then call Load on it which will handle the character encoding properly.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 3 - find ANGLE as an addon, v2

Making the world safe for funky charsets!

Comment 7

[Shawn Wilsher :sdwilsh]

Comment on attachment 463375 [details] [diff] [review]
part 3 - find ANGLE as an addon, v2

>+#ifdef XP_WIN
>+        // ANGLE is an addon currently, so we have to do a bit of work
>+        // to find the directory; the addon sets this on startup/shutdown.
>+        do {
>+            nsCOMPtr<nsIPrefBranch> prefs = do_GetService("@mozilla.org/preferences-service;1");
>+            nsCOMPtr<nsILocalFile> anglePath, glesv2Path;
Calling these variables *Path when they are actually files is confusing.  r=sdwilsh with that fixed.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 4 - allow ANGLE WebGL contexts to work with GL layers

This isn't a situation that I expect will show up often, but it was just entirely broken before, so we may as well support it.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 463757 [details] [diff] [review]
part 4 - allow ANGLE WebGL contexts to work with GL layers

highly unlikely situation, but may as well do the right thing.  will only be hit if someone is forcing ANGLE for WebGL but using an OpenGL layer manager.

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Did not push part 1, as having that is irrelevant in our codebase -- it's going into upstream angle with some changes, and I didn't want to have to deal with merges.  (We don't build this out of our tree right now.)

http://hg.mozilla.org/mozilla-central/rev/d879bb244890
http://hg.mozilla.org/mozilla-central/rev/314346f198ed
http://hg.mozilla.org/mozilla-central/rev/12c77406bb5f