Is CGL still developed?

[Joao da Silva]

Hi ANGLE team,

There are a few bugs and missing features in the GL backend for macOS using CGL. It seems like this functionality isn't used by Chrome; is this backend still being developed?

I'd be happy to try and fix the issues detailed below, with some guidance. Any hints would be very appreciated :-)

Thanks!

- Joao

#1: resizing the window animates the sizing of the framebuffer, interpolating from the old size to the new size.

This happens at [1], because WebSwapCGLLayer is a CALayer and animates changes to its properties by default. Wrapping that line in a CATransaction with no animations fixes this (documented at [2]). I can send a patch if this is the right fix.

#2: resizes show an outdated frame with the previous size, every time.

This frame is drawn stretched and stays on screen if the app isn't rendering continuously. eglWaitClient isn't implemented in CGL [3] and that might be part of the problem. There's a call to drawInCGLContext right after the window resize that swaps in a texture with the obsolete size; the next call to drawInCGLContext swaps in the correct size.

However, the application already resized and swapped buffers inside the resize callback. Is it possible to implement eglWaitClient in a way that makes the upcoming eglSwapBuffers do the right thing?

#3: eglSwapInterval isn't implemented [4] and eglSwapBuffers returns as fast as possible.

The macOS documentation [5] mentions calling CGLFlushDrawable to wait for vsync and having a doublebuffered CGLContextObj (i.e. including kCGLPFADoubleBuffer in CGLChoosePixelFormat). This didn't work: swaps still return as fast as possible and the CPU is at 100%.

[1] https://github.com/google/angle/blob/37f59b85087c347b3cf946f4881df8c266be1f1c/src/libANGLE/renderer/gl/cgl/WindowSurfaceCGL.mm#L56

[2] https://apple.co/34vbXsT

[3] https://github.com/google/angle/blob/37f59b85087c347b3cf946f4881df8c266be1f1c/src/libANGLE/renderer/gl/cgl/DisplayCGL.mm#L497

[4] https://github.com/google/angle/blob/37f59b85087c347b3cf946f4881df8c266be1f1c/src/libANGLE/renderer/gl/cgl/WindowSurfaceCGL.mm#L305

[5] https://bit.ly/338GpZ4

[Geoff Lang]

CGL has no default framebuffer so we've attempted to emulate everything, mostly so that our testing works. Because of this, resizing is delayed and frame pacing is difficult.  

For production applications I recommend creating EGL buffers from IOSurfaces using EGL_ANGLE_iosurface_client_buffer. It won't solve your frame pacing issues though, you will have to do that yourself.

--
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/4d7f3e80-07c7-4723-9389-9376c63902ean%40googlegroups.com.

[Ken Russell]

Also, to clarify - ANGLE's CGL backend is in the process of being shipped in Chrome on macOS right now, so it is still being supported. The team is, however, hoping to follow up the shipment of ANGLE in Chrome on macOS with a switch to ANGLE's Metal backend soon afterward.

-Ken

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

[Joao da Silva]

Thanks for the pointers and context.

The Metal backend works well for Window.js. Once Chrome switches then this project will switch too.

Meanwhile, a few tweaks to the CGL backend fixed the issues. Posting the details below in case they're useful to other projects as well.

Best,

- Joao

- - -

1. Synchronizing with monitor refreshes was the most important fix. CGLFlushDrawable stopped working in macOS 10.14; the CVDisplayLink API can be used to sync with monitor refreshes instead. The fix is similar to this fix for libSDL:

https://github.com/libsdl-org/SDL/commit/13869f19

2. The animation of the CALayer animating was disabled with a CATransaction.

3. Resizing without black borders was a bit more involved. It required resizing the CALayer and the textures from the eglWaitClient implementation. The drawing between the calls to eglWaitClient and eglSwapBuffers is then targeting a texture with the correct size. The eglSwapBuffers implementation in WindowSurfaceCGL::swap never sees textures with the wrong size after that change. Finally, swap() has to call [mSwapLayer setNeedsDisplay] and wait for the vsync cond variable from step #1 above.

[Geoff Lang]

We'd be happy if you upstreamed these changes. It would give more predictable behaviour for other ANGLE Mac users.

[Ken Russell]

https://chromium.googlesource.com/angle/angle/+/refs/heads/main/doc/ContributingCode.md describes how to upstream these - we definitely would appreciate it if you'd take the time to do so. Thanks in advance.