Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)

[Ivan Vučica]

On Wed, Nov 27, 2019 at 3:59 PM Max Chan <xcvista@me.com> wrote:
>
> Well if we are using OpenGL, since almost all other OpenGL related code is in 
> CoreAnimation, and it is OpenGL that actually opens the window for us in a 
> system agnostic manner, we might as well.

We are not using OpenGL and it has not been a requirement for -gui.

In fact, even with CAAppKitBridge, unless you set wantsLayer to YES,
you will not get an OpenGL context or window created.

CA depends on Opal, but the rest of -gui has no reason to depend on it
-- you can use CARenderer + NSOpenGLContext and create CALayers by
hand *today*, no integration work necessary. You can keep using Cairo
backend.

Even if we switch to Opal backend as the default or even only backend,
there's *no* requirement for CA or OpenGL. Platforms where OpenGL is
not available (but where Cairo works, e.g. on top of X11) would
*still* be well supported with Opal. (Problems would arise only on
platforms where users use other backends.)

So... where do you see that we depend on Core Animation in a way where
we *have* to *require* OpenGL, and where it would be appropriate to
open a window inside CA (as of today)? If anything, this would still
remain functionality in a separate library with platform-specific and
window-server specific implementations. CA implementation itself is
not the right place.

> (CoreAnimation may end up containing a complete set of Objective-C binding of 
> OpenGL API in it...)

Why? CA just uses C API anyway, with thin wrappers for shaders and
(IIRC) textures. Objective-C is still C.