Issues with Angle on macOS

[Yan Pujante]

I have currently 2 issues with Angle on macOS. I tried with the prebuilt libraries that come with Google Chrome as well as libraries build by myself, with the exact same results.

Note that I am using raylib/glfw for the base framework and I build with (cmake) option OPENGL_VERSION "ES 2.0" to force using the Angle dylibs (libGLESv2.dylib and libEGL.dylib)

Issue #1.

If I run a very basic code (draw a rectangle, draw the fps count) without using any (glfw) hint, then Angle uses the renderer under src/libAngle/renderer/gl/clg. It is very (crazy) fast and I am getting 17000fps (yes it is not a typo). But the rendering is wrong when there is alpha involved. For example I am rendering a rectangle with color  {40, 73, 122, 137} on a black background, but I am getting this shade (measuring it gives: 83/101/127)

So that is the issue I have: it seems that it is not handling alpha blending properly. Somehow it seems to be related to srgb, but I don't know why it is doing that nor what I can do to fix it.

Issue #2

If I use the glfw hint glfwInitHint(GLFW_ANGLE_PLATFORM_TYPE, GLFW_ANGLE_PLATFORM_TYPE_METAL), then Angle uses the renderer under src/libAngle/renderer/metal. Which is what I am expecting. The rendering is "right" and looks like this (notice how the shade is much darker than before)

But the issue I have in this case is that the framerate seems to be limited to 60fps, although it is quite erratic, sometime jumping to 200fps and back down to 60fps. I do confirm that I call swapInterval with a value of 0, which translate into this Angle call

   // SurfaceMt.mm line 502

    mMetalLayer.get().displaySyncEnabled = interval != 0;

Every single time I pause in the debugger I end up on this call which seems to be what is throttling the entire loop:

The (Objective C) call [CAMetalLayer nextDrawable] in SurfaceMtl.mm ends up being a major bottleneck, sometime waiting 16ms... hence the 60fps. I am not sure what to do about this.

If anybody has any insight/tip for either Issue 1 or 2, please let me know. I will be more than happy to try things locally.

Thank you

Yan

[Geoff Lang]

Hey,

Window surfaces on MacOS are all emulated by ANGLE, they don't see a ton of usage because many of our integrators just use ANGLE to render into IOSurfaces and then composite themselves.

• It looks like frame pacing is not implemented in our CGL backend. That's why you're seeing 17k fps.
• I'm not sure how blending is determined when compositing.
• Apart from the erratic values you see, it sounds like displaySyncEnabled is doing what it's supposed to but not blocking in the eglSwapBuffers call because the first time the drawable is used in each frame is for the clear.

I'd recommend doing window management and compositing yourself on MacOS. Grab an IOSurface out of the window and make an EGLImage with it so ANGLE can render into it.

Geoff

--
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/a88c8c25-d3db-4ed9-8090-f57515f32e02n%40googlegroups.com.

[Yan Pujante]

Thank you for the feedback.

I wanted to add the findings that a user added on the github issue I had created on the raylib project for this very problem: https://github.com/raysan5/raylib/issues/3179#issuecomment-1664548717

Thank you

Yan