[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which O
From: |
Max Chan |
Subject: |
回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?) |
Date: |
Thu, 28 Nov 2019 02:40:17 +0800 |
If we have OpenGL, how about let it do more - that is, not just compositing
windows, but also building the contents of the windows too? This way we
effectively feeds the GPU a vector image of the screen/window (think a PDF
file) and let the GPU handle all the actual rendering, including rasterization?
The CPU-based renderer (Cairo) would be reserved when rendering to raster image
files.
-----邮件原件-----
发件人: Ivan Vučica <ivan@vucica.net>
发送时间: 2019年11月28日 2:29
收件人: 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?)
We're straying off of the main discussion again now, but I'll do one more
response :-)
On Wed, Nov 27, 2019 at 6:02 PM Max Chan <xcvista@me.com> wrote:
>
> I wonder how Apple implemented their version though…
I will intentionally not discuss this further, and I have intentionally not dug
very deep. I don't want to be overly exposed to ideas beyond the APIs.
But from the little that I had unfortunately observed, and from some stuff I
wish I hadn't read, yes, yes, WindowServer process and who knows what else is
involved in a lot of rendering of things in windows.
> 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.
Consider something else.
Let's imagine an X11 window manager that does compositing. Let's imagine it
assumes that the underlying platform *always* has OpenGL available, and even
the simplest 'skins' with animations switched off will be painted with OpenGL.
And if you switch to something that has no OpenGL available, you switch to
using Mesa's software rendering. (Apple has, during its OpenGL era on OS X,
maintained a pretty good software renderer.
Although slow, you could opt to use it if you needed something unsupported by
the GPU.)
How fast would *just* blitting pixels onto the screen be? I mean, it's
certainly repainting the whole scene. 3D games repaint the entire scene from
scratch rather than updating bits of it. I'd wonder, what's the restricting
factor if you repaint the entire scene (i.e. do a lot of pixel copies)? Where
do these already-painted 2D windows end up, in this hypothetical X11
compositing window manager? And, at that, let's expand our hypothetical window
manager: let's have it perform compositing of shadows, or add opacity using
alpha values, so that there's a reason why it's using a 'compositing' window
manager. How fast would that work without any 3D -- or 2D! -- acceleration?
(Are you sure what this spins up is the GPU fan?)
Anyway, I'd expect that there's a lot of CPU-bound pixel copies heading from
main system RAM to main system RAM, then -- when doublebuffering happens --
from main system RAM to whatever the permitted primitive interface is (directly
to video memory? I don't know how this works on x86, (S)VGA/VESA, or in OS X).
I'd expect there's no magic sauce at all enabled. So, I'd expect window
compositing being done through a software GL renderer (even if the underlying
windows are unchanging 2D textures drawn only through Core
Graphics) can significantly ruin the framerate.
But that's just uninformed guessing on my part, without actually testing
anything on a real Mac.
> That is, either get accelerated graphics working at a kernel level, or
> tolerate slow CoreGraphics.
Well, "slow".
Pixel copies, once something's painted with Core Graphics, can be slow, too. I
recall QuartzGL being a thing that Apple gave up on -- so even though I have no
idea what happened in the Metal era, I'd say that most of the OS X (and iOS)
systems have generally used software painting of graphics into layers.
Root-layers and their children then get composited onto a scene.
We don't need to paint everything with GL. We don't even need to composite
layers into a scene using CARenderer, as updating rectangular bits of an
X11/Win32 pixmap/bitmap/whatever-rectangular-collection-of-pixels-you-want as
necessary can indeed be faster.
...having now advocated for "-gui doesn't need to *depend* on GL", I'll say
this:
Compositing with GL is pretty fast on most systems, so when/if CAAppKitBridge
is functional, I'd really go wild with optional animations. :-)
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), (continued)
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?),
Max Chan <=
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), David Chisnall, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Andreas Fink, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), James Carthew, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Maxthon Chan, 2019/11/27
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/28
- Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Matt Rice, 2019/11/28
- Re: Which ObjC2.0 features are missing in the latest GCC?, H. Nikolaus Schaller, 2019/11/26