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

[Ivan Vučica]

That's up to -gui's maintainer to decide, but I don't think Opal
backend is ready for primetime. :-)

As in, I wouldn't even set it as recommended, much less default, and
much much less only available backend.

Next, it's also not the job of Core Animation-compatible library to
open the window (for that matter, this should still be some platform
specific code, which CA mostly isn't -- so you're back to still
needing swappable backends at least for creating a window).

And from my understanding of Wayland protocol (and it's a protocol,
with some helper libraries, not a whole system), I am very much *not*
under the impression that there is any dependency on or requirement to
use OpenGL. Compositors may use it, but from my understanding, neither
they nor the clients are obliged to use OpenGL.

See https://wayland.freedesktop.org/faq.html#heading_toc_j_3

> # What is the drawing API?
>
> "Whatever you want it to be, honey". Wayland doesn't render on behalf of the 
> clients, it expects the clients to use whatever means they prefer to render 
> into a shareable buffer. When the client is done, it informs the Wayland 
> server of the new contents. The current test clients use either Cairo 
> software rendering, Cairo on OpenGL or hardware-accelerated OpenGL directly. 
> Additionally, media frameworks can share their buffers directly with the 
> server. As long as you have a userspace driver library that will let you 
> render into a shareable buffer, you're good to go.

On Wed, Nov 27, 2019 at 3:45 PM Max Chan <xcvista@me.com> wrote:
>
> Hmm if this is the case, maybe we should end up with the Opal backend being 
> merged into GUI proper and all other backends discarded. Way too many actual 
> macOS and iOS apps uses CoreGraphics directly.
>
> Also maybe we should drag OpenGL into this discussion, as a lot of 
> CoreAnimation stuff may need that. If this way, we have:
>
> CoreAnimation: OpenGL open a window on screen.
> Opal: Use cairo to CPU-render the view and put it onto that OpenGL window.
> GNUstep GUI: NSView paints a window.
>
> Dragging OpenGL in the discussion also allows us better compatibility with 
> Wayland too, as AFAIK Wayland uses exclusively OpenGL to render anything on 
> the screen.
>
> (There has been a trend in the Linux world to copy Apple architecture. 
> systemd is a clone of launchd and networkd, Wayland is modeled after 
> windowserver, etc. We might as well play along.)
>
> -----邮件原件-----
> 发件人: Ivan Vučica <ivan@vucica.net>
> 发送时间: 2019年11月27日 23:34
> 收件人: 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?)
>
> gnustep-back: x11 / win32 open a window on the screen.
> gnustep-back: Opal [let's treat it as a blackbox] / Cairo / libart / xlib can 
> paint into it.
> gnustep-gui: NSView paints using Opal/Cairo/libart/xlib into x11/win32 window 
> -- this is the stuff in gnustep-back
>
> Opal uses Cairo, but that's an internal implementation detail. It could have 
> multiple backends in theory. It exposes a Core Graphics API.
>
> Opal is, to me, the important backend because Core Animation's APIs (and 
> therefore the ~compatible partial implementation in GNUstep) uses CGContext 
> as the 'thing to paint into'. It happens to use Cairo, but Core Animation 
> doesn't care as long as it can get the pixels out and uploaded to the GPU 
> into a GL texture. (It might care if we can do that directly without a copy 
> of pixels -- maybe Cairo can paint directly into GPU somehow, I never looked 
> at that.)
>
> Either way, the layering as it is right now makes sense. There's confusion 
> about where should some of the graphics context state be kept (gnustep-back? 
> cairo+libart+xlib?) but that's not the critical part of the layering.
>
>
> On Wed, Nov 27, 2019 at 3:26 PM Max Chan <xcvista@me.com> wrote:
> >
> > TBH I am not familiar with how GUI and Back interacts, and I am confused at 
> > why GUI, Back, Opal et al are layered that way.
> >
> > -----邮件原件-----
> > 发件人: Ivan Vučica <ivan@vucica.net>
> > 发送时间: 2019年11月27日 23:17
> > 收件人: 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, Nov 27, 2019 at 3:01 PM Max Chan <xcvista@me.com> wrote:
> > >
> > > Apple implemented SwiftUI as a wrapper on top of AppKit and UIKit for 
> > > macOS and iOS respectively, however architecturally those three libraries 
> > > are at the same level. This is why I am suggesting us doing the reverse, 
> > > making our AppKit and UIKit wrappers of SwiftUI. A better way to phrase 
> > > this is that our partial SwiftUI becomes what Back used to be. So instead 
> > > of being a bundle embedded in GUI, Back implementing SwiftUI becomes a 
> > > proper framework standing on its own.
> >
> > Are you sure you're correctly considering what -back actually does?
> >
> > I don't think it makes sense to throw away all of -gui and possibly -back. 
> > I also don't think what you're saying is necessarily possible.
> > See how -draw* methods can be overridden, and how these calls eventually 
> > descent through -gui and -back into cairo, or art, or something else. 
> > Consider how graphics contexts are created and used in -back, how 
> > transforms are kept around, etc.
> >
> > If this was at work, I would request a design proposal and possibly a 
> > detailed design document at this stage, but given this is a free software 
> > project, I'll just say that this would certainly be interesting to read a 
> > partial implementation of your proposed architecture.
> >
> > If you want to bring something SwiftUI*-compatible into the story, I
> > think wrapping it around AppKit lib (not around the nonexistent UIKit
> > lib) makes sense. Alternative is treating it as a new, independent entity 
> > and not touching -gui. Certainly I would seriously consider inverting the 
> > dependencies in this way without a very strong reason -- and a much 
> > stronger case can be made to put -gui on top of Opal, where -gui turns into 
> > backends for Opal. So, why would you prioritize this over CAAppKitBridge's 
> > truly noninvasive* changes to paint into a CALayer?
> >
> > And this is all unimportant if the Swift bridge is not in place first.
> >
> > * We should certainly not call a compatible implementation "SwiftUI"
> > except for compatibility reasons, and I should finally go ahead and rename 
> > our CA-compatible library too.
> > ** They're noninvasive because if you don't load CAAppKitBridge's 
> > categories or use the Opal backend, you simply don't get to paint into 
> > CALayer; everything else works. There's just two i-vars and a property 
> > added to the NSView, otherwise, you don't really need to care.
> >
> > > SwiftUI is a new framework, so it would be a while before any major open 
> > > source release happens.
> >
> > You mean a major release of SwiftUI, or some major open source program 
> > being implemented using SwiftUI? Are there intentions to release SwiftUI as 
> > a free library? Can you point me at this?
> >
>