discuss-gnustep
[Top][All Lists]
Advanced

[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: Thu, 28 Nov 2019 08:27:22 +0000

On Thu 28 Nov 2019 at 04:13, Maxthon Chan <address@hidden> wrote:
We should have three layers of falling back: OpenGL-on-Vulcan first, pure OpenGL next, Cairo software rendering last.

If you are saying “CA-on-OpenGL-on-Vulcan”, my POV is: that’s up to the user to figure out how they will use their OpenGL software, or for someone else to contribute to rewrite with Vulkan in place of actually finishing the thing. Why would we care if our OpenGL software runs on Vulkan or not?

Next, you also mention Cairo software rendering as a bad thing. If you’re advocating for doing CG-equivalent on GPU here (and I think you aren’t) I asked before how you would do this. Please also refer to David’s email.

Cairo (or its equivalents) *will* be used to paint into a layer even if we switch to that.

I looked up “Cairo OpenGL” thinking maybe they have a GL based implementation of the API, like QuartzGL sort of was, but I got these instead and didn’t look further for now:

https://www.cairographics.org/OpenGL/
https://softwareengineering.stackexchange.com/a/224966


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

Which heavy duty rendering do you see in GNUstep right now?

Even with CA I would not call it heavy duty till you have a hundred layers, a bunch of 3D transforms and shadows, plus an occasional filter [n.b. we have bad shadows support, no masking support and no filters support on our side].

The heaviest stuff would be a full screen repaint, if there were gradients etc, which yes, moving to a layer based approach (painting on CPU, compositing on GPU) might help.



On Nov 28, 2019, at 7:50 AM, James Carthew <address@hidden> 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 <address@hidden> wrote:


On 27 Nov 2019, at 19:02, Max Chan <address@hidden> 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.



--
Sent from Gmail Mobile

reply via email to

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