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

[Max Chan]

Well given how apps are being written now, a lot of code I have seen assumes 
the existence of CoreGraphics in AppKit, so it won't hurt if GI directly 
depends on Opal.

And I am not considering CoreFoundation-based code plain old C.

-----邮件原件-----
发件人: Ivan Vučica <ivan@vucica.net> 
发送时间: 2019年11月28日 0:23
收件人: Max Chan <xcvista@me.com>
抄送: Discuss-gnustep Discuss <discuss-gnustep@gnu.org>
主题: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which 
ObjC2.0 features are missing in the latest GCC?)

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.