What's the recommended backend for each platform?

[Joao da Silva]

Hi all,

ANGLE supports various backends:

https://github.com/google/angle#level-of-opengl-es-support-via-backing-renderers

What are the recommended backends for each of the desktop platforms?

Are they all equally stable and tested?

I'm looking into whether to use D3D9 or D3D11 on Windows, and GL or Metal on macOS. Or whether to just use Vulkan instead.

The criteria for my project are

(1) Support GLES 3.0 (to back a WebGL2 implementation)

(2) stable rendering across the platforms,

(3) performance,

(4) smallest binary size (i.e. by excluding unused backends from the build).

Thanks!

- Joao

[Geoff Lang]

You could mirror what Chrome currently uses for the best stability:

Windows: D3D11 with D3D9 fallback

Linux: GL, Vulkan is in progress

Mac: GL, Metal is in progress

Android: GL, Vulkan is in progress

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/35c79186-f907-490b-9bf9-2c6c465995c3n%40googlegroups.com.

[Jamie Madill]

I'd add that the Vulkan backend is likely going to become the most well supported back-end on any platform that supports Vulkan natively, including Windows. It's currently not as tested on a wide range of Windows configs as the D3D11 back-end.

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/CA%2BPGBXv7y%3Dys%2Bwky2VEPbKXkRHhG00ThJQ4O0m9is7jyhvMjRQ%40mail.gmail.com.

[Rafael Cintron]

Joao, for Windows, I highly recommend using the D3D11 with a D3D9 fallback like Geoff states.  As Geoff says, these backends are the most tested ones on Windows. 

 

A plus of using DirectX is that on some Windows machines such as Xbox and Qualcomm Windows machines like Surface Pro X, DirectX is the only backend that will work.

 

--Rafael

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/CACOTusSNMTq4RBed4aNzvCtCOhN34DobyGCOt8eP17DG05NkHw%40mail.gmail.com.

[Joao da Silva]

Thanks for the input! Using the same backends as Chrome makes a lot of sense.

Everything works fine, and integrating ANGLE was quite straightforward (including with GLFW and Skia).

(FWIW, I've patched libEGL_static to skip the thin_archive config and set complete_static_lib=true, so that windowjs.exe can be distributed as a single binary. GLFW needed some fixes to skip trying to load libEGL.dll as well. Works quite well in the end!)

The bane of my existence is now window resizes :-)

I'm trying really hard to make resizes do contentful paints in sync with the resize event (WM_SIZE). The application is single threaded and just enters Javascript, draws its thing, and swaps buffers. It works almost all of the time, except showing a stretched frame now and then, and I have no idea why or how to sync this properly. The application renders to a texture first, and then copies it to framebuffer 0 (via Skia). AFAICT, Skia is flushing its commands to the GPU as expected.

Would you have any hints of things to try?

I've noticed that the glitch happens very frequently when eglSwapInterval is 1 (i.e. vsync is on), and very rarely when it's 0 (vsync off). Setting the swapinterval to 0 from the resize callback also makes it glitch less often (!). Looking into the D3D11 renderer, this seems to be related with swap chains but I don't know D3D to understand the details.

Also noticed that calling eglWaitClient after resizing the surfaces improves things.

Would you suggest trying some of the extensions, or maybe WS_EX_NOREDIRECTIONBITMAP + DirectComposition?

Maybe there's a way to make Windows wait as long as necessary for the paint? :-)

(I've also checked obvious things like setting glViewport, checking that the context is current, etc.)

Thanks for the help.

Best,

- Joao

[Rafael Cintron]

Joao, I am not sure what kind of applications you’re building. 

 

In general you should prefer to use flip model swap chains along with WS_EX_NOREDIRECTIONBITMAP.  See DXGI flip model - Win32 apps | Microsoft Docs. 

 

The stretching you’re seeing is likely because the WM_SIZE messages are coming in but your code is (for some reason) not resizing the swap chain buffers to the new window size.  If you specified DXGI_SCALING_STRETCH, then windows will stretch the contents to fit the window. 

 

--Rafael

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/636b9d40-4882-44fe-8283-5efa7e04158en%40googlegroups.com.

[Joao da Silva]

Hi ANGLE team,

coming back to this thread a year later to ask if things have changed regarding the recommended backend for each desktop platform. In particular,

* Does macOS default to Metal now? Is Metal better than CGL as a backend right now?

* And does any platform using Vulkan by default now too? Is it better to just use Vulkan for Windows, macOS and Linux?

Thanks,

- Joao

[Geoff Lang]

Metal and GL are both actively supported on Mac. I think it's fairly safe to set as your default. Performance and conformance are generally better but it's had less time to "bake" in the wild.

We're in the process of shipping Vulkan as the default on Linux and Android, you can expect it to work well there. Windows will likely not use Vulkan any time soon, it doesn't integrate particularly well with the OS compositor.

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/eda00031-b633-4f05-9e4f-dfeb0db85f73n%40googlegroups.com.