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

[Matt Rice]

On Thu, Nov 28, 2019 at 8:28 AM Ivan Vučica <ivan@vucica.net> wrote:
>
> On Thu 28 Nov 2019 at 04:13, Maxthon Chan <xcvista@me.com> 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
>

It is worthwhile in this regard to understand how cairo is tested, in
that it aims for bit-for-bit compatible rendering between its
different backends.
what support there is for rendering cairo via openGL is not absolved
of this requirement, and so most things still fall back to software
rendering.