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

[Max Chan]

Why is it slower though?

 

(My test systems has 16 amd64 cores and an RX 480 GPU, so I am not familiar with the plight of low end users.)

 

发件人: Ivan Vučica <ivan@vucica.net>
发送时间: 2019年11月28日 0:46
收件人: 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 27 Nov 2019 at 16:31, Max Chan <xcvista@me.com> 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