Closed Bug 583838 Opened 12 years ago Closed 12 years ago

use ANGLE if available for WebGL under D3D


(Core :: Graphics: CanvasWebGL, defect)

Windows 7
Not set



Tracking Status
blocking2.0 --- beta4+


(Reporter: vlad, Assigned: vlad)




(4 files, 1 obsolete file)

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.
Submitted upstream as

This greatly improves ReadPixels and TexImage2D performance on windows with the native image byte order.
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.
Attachment #462161 - Flags: review?(bjacob)
blocking2.0: --- → beta4+
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!
Attachment #462161 - Flags: review?(bjacob) → review+
Attached patch part 3 - find ANGLE as an addon (obsolete) — Splinter Review
Use category set by the ANGLE addon to find the DLL.
Attachment #463335 - Flags: review?(dtownsend)
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.
Attachment #463335 - Flags: review?(dtownsend) → review-
Making the world safe for funky charsets!
Attachment #463335 - Attachment is obsolete: true
Attachment #463375 - Flags: review?(dtownsend)
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(";1");
>+            nsCOMPtr<nsILocalFile> anglePath, glesv2Path;
Calling these variables *Path when they are actually files is confusing.  r=sdwilsh with that fixed.
Attachment #463375 - Flags: review?(dtownsend) → review+
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 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.
Attachment #463757 - Flags: review?(bas.schouten)
Attachment #463757 - Flags: review?(bas.schouten) → review+
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.)
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 586588
No longer depends on: 586588
Depends on: 670025
You need to log in before you can comment on or make changes to this bug.