[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which O

From: Ivan Vučica
Subject: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)
Date: Wed, 27 Nov 2019 16:46:16 +0000

On Wed 27 Nov 2019 at 16:31, Max Chan <address@hidden> wrote:
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.

What about performance regressions on specialty low-performance hardware used by some important contributors? And last time I was using it, Opal backend was buggier and slower than using Cairo directly.

Again, not up to me to decide anyway. Not to mention things are very intricate anyway (or else I wouldn’t deliver a half-baked implementation after ~3mo GSoC work back in, what, 2013? with our 2018 student running into problems trying to deliver CAAppKitBridge as well).

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

If I’m invoking glPushMatrix() without a wrapper, that means I cannot possibly think of myself as using an “OpenGL binding”. Using C API directly is as native as it gets. There is no binding that the implementation uses, contains, intends to provide.

Objective-C is C. It is other things, too, but it is also C.
Sent from Gmail Mobile

reply via email to

[Prev in Thread] Current Thread [Next in Thread]