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

[Maxthon Chan]

We should have three layers of falling back: OpenGL-on-Vulcan first, pure OpenGL next, Cairo software rendering last.

Moving some of the heavy duty graphics rendering off the CPU can help performances IMO.

On Nov 28, 2019, at 7:50 AM, James Carthew <jcarthew@gmail.com> wrote:

If Apple is forcing the use of Metal, wouldn't it make sense to use Vulkan rather than OpenGL? There's already working happening to make OpenGL a layer built on top of Vulkan e.g Zink: https://www.collabora.com/news-and-blog/blog/2018/10/31/introducing-zink-opengl-implementation-vulkan/

On Thu, 28 Nov 2019 at 09:57, Andreas Fink <afink@list.fink.org> wrote:

On 27 Nov 2019, at 19:02, Max Chan <xcvista@me.com> wrote:

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.

Given OSX 10.15 and above does require metal support graphics hardware, (a old MacPro (the big PC style towers, not the round ugly thing) could not be upgraded to 10.15 unless it had a metal capable video card, would confirm that.