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 wrote:
>
> If Apple is forcing the use of
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
> On 27 Nov 2019, at 19:02, Max Chan 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 render
Hi David,
On November 27, 2019 at 2:59 AM, David Chisnall
wrote:
On 27/11/2019 10:49, Andreas Fink wrote:
Which cmake version did you use to get it built as the one coming with
Debian10 is too old.
What error did you get? The minimum required is 3.1[1], which is from
some time around 2014. I
Great. Yes I noticed the ICU version numer change. These things are usually
easy to spot and fix.
Which cmake version did you use to get it built as the one coming with Debian10
is too old.
It turns out the cmake is only too old for Swift's libdispatch tip. The
approach taken in the script
Guys,
I am going to set an ultimatum at this point. Any decision regarding the
deprecation of GCC will be deferred for one year from this date.
We know what needs to be done in that time frame to bring GCC up task and I
will discuss with the GCC team about possible implementation whether that
inv
On Wed 27 Nov 2019 at 18:58, David Chisnall
wrote:
> On 27 Nov 2019, at 18:29, Ivan Vučica wrote:
> >
> > 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.
>
> Apple wrote quite a lot pub
We can treat the internals of a window as a composite of views, then apply the
same philosophy.
-邮件原件-
发件人: David Chisnall
发送时间: 2019年11月28日 2:59
收件人: Ivan Vučica
抄送: Max Chan ; Discuss-gnustep Discuss
主题: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which
ObjC2.
On 27 Nov 2019, at 18:29, Ivan Vučica wrote:
>
> 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.
Apple wrote quite a lot publicly about how their fast rendering server (Quartz
Extreme!!11e
Look at quartzgl and how it ended up.
And to go back to open systems: which api would you use to feed a GPU a
fast updating “vector image” with beziers, gradients, etc? How would you
restructure X11/Wayland and the whole graphics stack to first build a “PDF”
of a window to upload in this way? How
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 rasteriz
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 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
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 (d
On Wed 27 Nov 2019 at 16:49, Max Chan wrote:
> Why is it slower though?
>
I don’t know. It was in 2013. I think Fred followed up on my work and
cleaned things up.
But it was much slower and it probably still is. I should rebuild with it
again and compare.
But if you ask why, no, I never profil
Why is it slower though?
(My test systems has 16 amd64 cores and an RX 480 GPU, so I am not familiar
with the plight of low end users.)
发件人: Ivan Vučica
发送时间: 2019年11月28日 0:46
收件人: Max Chan
抄送: Discuss-gnustep Discuss
主题: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was:
On Wed 27 Nov 2019 at 16:31, Max Chan wrote:
> Well given how apps are being written now, a lot of code I have seen
> assumes the existence of CoreGraphics in AppKit, so it won't hurt if GI
> directly depends on Opal.
What about performance regressions on specialty low-performance hardware
used
Well given how apps are being written now, a lot of code I have seen assumes
the existence of CoreGraphics in AppKit, so it won't hurt if GI directly
depends on Opal.
And I am not considering CoreFoundation-based code plain old C.
-邮件原件-
发件人: Ivan Vučica
发送时间: 2019年11月28日 0:23
收件人: Ma
On Wed, Nov 27, 2019 at 3:59 PM Max Chan wrote:
>
> Well if we are using OpenGL, since almost all other OpenGL related code is in
> CoreAnimation, and it is OpenGL that actually opens the window for us in a
> system agnostic manner, we might as well.
We are not using OpenGL and it has not been
Well if we are using OpenGL, since almost all other OpenGL related code is in
CoreAnimation, and it is OpenGL that actually opens the window for us in a
system agnostic manner, we might as well. (CoreAnimation may end up containing
a complete set of Objective-C binding of OpenGL API in it...)
-
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
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
I disagree that rewriting -gui to use SwiftUI is a useful use of
volunteer time, or that this is the appropriate layering.
On Wed, Nov 27, 2019 at 3:29 PM Max Chan wrote:
>
> API layering. From what I feel like the API should be layered like this:
>
>
>
> GUI (AppKit) -> CoreAnimation -> Opal (Co
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 inte
API layering. From what I feel like the API should be layered like this:
GUI (AppKit) -> CoreAnimation -> Opal (CoreGraphics) -> Cairo/OpenGL.
If we have SwiftUI acting as the common denominator between AppKit and UIKit,
then it would be:
GUI (AppKit) & UIKit -> SwiftUI -> CoreAnimatio
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
发送时间: 2019年11月27日 23:17
收件人: Max Chan
抄送: Discuss-gnustep Discuss
主题: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Wh
On Wed, Nov 27, 2019 at 3:01 PM Max Chan 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 an
Yes. But why do you believe it's related to the core animation apis?
On Wed, Nov 27, 2019, 10:01 AM Max Chan 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 i
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
On Wed, Nov 27, 2019 at 3:32 AM Maxthon Chan wrote:
>
> When talking about SwiftUI, I mean having CAAppKitBridge/Opal/Back implement
> SwiftUI API as its interface to the upper layers.
I am getting increasingly confused here. Why would these particular
libraries implement the SwiftUI APIs?
Espe
On 27 Nov 2019, at 12:29, David Chisnall wrote:
I am no longer actively working on Foundation or AppKit, so I
shouldn't get much of a say in what those projects do, but if GNUstep
is going to be tested with only GCC then my advice would be:
- Actively market GNUstep as only an OpenStep imp
On 27/11/2019 08:37, Fred Kiefer wrote:
For me this reoccurring build issues are one of the reasons why I do not use
clang and the new runtime. They both develop too fast for me. It is quite
normal that things change and from time to time they are even broken. If I
remember correctly most of t
On Wed, 27 Nov 2019 at 12:15, Andreas Fink wrote:
>
> On the other hand I would _LOVE_ to see a OS X like desktop with AppKit and I
> would spend time working on it. Given the other desktops under Linux have not
> much success because of the way they do certain things, I think there is a
> big
it was complaining that i need least 3.14.
Debian 10 comes with 3.13.4
but now I can't reproduce that. I have to investigate this...
I'll retest with a empty new VM
It happened to me on 2 separate machines
> On 27 Nov 2019, at 11:59, David Chisnall wrote:
>
> On 27/11/2019 10:49, Andreas Fink wr
> On 27 Nov 2019, at 10:48, Johannes Brakensiek
> wrote:
>
> On 26 Nov 2019, at 23:43, Fred Kiefer wrote:
>
> That could be said about all backward-compatibility. A follow up question
> is, does it hold us back enough to justify breaking compatibility? It seems
> some people think yes, and ot
On 26/11/2019 22:43, Fred Kiefer wrote:
If I understand you correctly your suggestion is that we try to add support in
gcc for some of the basic ObjC 2.0 features. That should be doable although the
last time I tried I gave up on it. That was right after the Dublin meeting
where we had a simil
On 27/11/2019 10:49, Andreas Fink wrote:
Which cmake version did you use to get it built as the one coming with
Debian10 is too old.
What error did you get? The minimum required is 3.1[1], which is from
some time around 2014. I would be shocked if Debian included something
that old.
David
Gregory,
I’m leaving out your replies as it seems you did not get me right.
First I was trying to strengthen your approach by reflecting the public
opinion about GNUstep as far as I recognized it. Of course it is not
fully true and of course I did not write and speak with everyone or did
scie
Great. Yes I noticed the ICU version numer change. These things are usually
easy to spot and fix.
Which cmake version did you use to get it built as the one coming with Debian10
is too old.
> On 27 Nov 2019, at 06:55, Patryk Laurent wrote:
>
> Hi Andreas,
>
> I have just updated the script a
Johannes,
On Wed, Nov 27, 2019 at 4:49 AM Johannes Brakensiek <
johan...@brakensiek.info> wrote:
> On 26 Nov 2019, at 23:43, Fred Kiefer wrote:
>
> That could be said about all backward-compatibility. A follow up question
> is, does it hold us back enough to justify breaking compatibility? It see
Stefan,
On Tue, Nov 26, 2019 at 4:18 PM Stefan Bidigaray
wrote:
> Hi Greg,
>
> On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>>
>> Stefan,
>>
>> I personally don't like off list discussions it makes things a little
>> more complicated than they need to
On 27/11/2019 00:25, Andreas Fink wrote:
This is now under Debian10 with clang-10 from the llvm repo.
cmake is very cryptic here to tell us where it breaks. so go figure
I never use the makefile generator for CMake, but with ninja you can do
ninja -v to see the build steps (and it automati
On 26 Nov 2019, at 23:43, Fred Kiefer wrote:
That could be said about all backward-compatibility. A follow up
question
is, does it hold us back enough to justify breaking compatibility?
It seems
some people think yes, and others think no. We're at a stalemate,
where no
progress can be expecte
On 27 Nov 2019, at 9:37, Fred Kiefer wrote:
Thank you for updating this instruction file. Is there a link to this
in the GNUstep wiki? I understand that we should make it as easy as
possible for new (and experienced) programmers to grab the correct
instructions the first time.
For me this r
> Am 27.11.2019 um 06:55 schrieb Patryk Laurent :
>
> Hi Andreas,
>
> I have just updated the script at
>
> https://github.com/plaurent/gnustep-build/blob/master/debian-10-clang-8.0/GNUstep-20-buildon-debian10.sh
>
> and verified that it builds fully under Debian 10 (buster) by testing it
>
44 matches
Mail list logo
