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

[Max Chan]

I wonder how Apple implemented their version though… I do have an observation: if I force VESA graphics on my Hackintosh (this requires special boot flags, so it is easier to do on Hackintosh than a real Mac,) the OS interfaces are rendered very slowly. However if I allow accelerated graphics (default behavior,) it operates smoothly but from time to time the GPU fan would spin up even though there is no GPU-intensive tasks.

 

I think Apple went down the exclusive OpenGL/Metal route. That is, either get accelerated graphics working at a kernel level, or tolerate slow CoreGraphics.

 

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

Why is it slower though?

 

I don’t know. It was in 2013. I think Fred followed up on my work and cleaned things up.

 

But it was much slower and it probably still is. I should rebuild with it again and compare.

 

But if you ask why, no, I never profiled it in great detail.

 

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

 

I just booted my 2009 MB the other day. I also have a Raspberry Pi. But some contributors run non-intel, non-arm hardware with far lower performance characteristics.

 

None of my machines has 16 cores; I am more than happy with the 4 core (x2 for hyperthreading one).

 

I would not easily go for a design that assumes “this doesn’t affect me, therefore it’s irrelevant”, at least for GS. Otherwise, if we go for radically divergent architectures, why not throw out AppKit and reimplement the important parts on top of GTK3 or Qt (neither of which, I think, pulls in an OpenGL dependency at this point).

 

 

发件人: 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

--

Sent from Gmail Mobile