Comment by gigatexal
Comment by gigatexal 7 hours ago
Probably better than Gnome’s single threaded-ness.
I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.
Comment by gigatexal 7 hours ago
Probably better than Gnome’s single threaded-ness.
I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.
Seriously. I don't know if folks remember this Java desktop research project from 25-some years ago: https://en.wikipedia.org/wiki/Project_Looking_Glass. To say that it was slow was an understatement (it was a real PITA to get this installed and built at the time; I spent an afternoon in college doing that out of boredom).
I imagine FyneDesk is plenty fine for what it is doing in comparison.
I do, this was a research project.
Also this was mostly interpreted back then, without JIT compiler support.
Also to note,
> Regardless of the threat, Sun determined that the project was not a priority and decided not to put more resource to develop it to product quality. The project continued in an experimental mode, but with Sun's finances deteriorating, it became inactive in late 2006
Written from a Java userspace powered mobile phone, with 75% worldwide market share.
That was a really cool project but yeah the Java couldn’t hack it.
FyneDesk aims to compete on performance with the light weight window managers whilst offering the rich experience of complete desktops.
We are close on performance in most areas, once Fyne v2.7.0 is out we will do a new release which is going to blow our previous out of the water. Just a few thread handling bugs to iron out for optimal results first…
Java is fast enough for having legions of kids playing games written in it, and a full OS userspace, it is a matter of implementation, and how much use gets done in JNI, no different than reaching out to CGO or Plan 9 Assembler, while keeping most of the code in Go.
Oh yes, I didn’t mean to knock the language - I also worked on amazing things in Java before I moved to go.
But the runtime of a Go app is, by default, faster than Java and my experiences have shown much, much better performance with the sort of multi-window full screen throughput we need for building a desktop.
The Project Looking Glass UI came to iPadOS and MacOS via Stage Manager https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/...
youre implying that Stage Manager is Java. I dont think thats true though?
Isnt it only the _design_ of stage manager somewhat resembles some design choices by project looking glass?
this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.
> this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.
Looking Glass-like switchers are still available in Plasma
> [...] that Apple would sue Sun if they moved forward to commercialize it – Jobs felt the project infringed Apple's intellectual property.
Classic Apple.
They should be, but with the speed and resources available on machines these days, people don't spend as much time optimising every little thing, and even make trade-offs, e.g. Gnome 3 desktop has the spidermonkey javascript engine in it, and an increasing numbers of components are using javascript.
Not necessarily the environment, but compositor itself must be fast. It shouldn't introduce any delays that would affect for instance input latency in its processing loop. Gamers would for sure complain.
Someone could totally make it do everything in a single thread and not think about that, which would be pretty bad.
On a high enough resolution, especially with 5K-6K displays a single-threaded software-only compositor is absolutely going to have horrible performance. Even on Full HD it's actually quite noticeable
> I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.
You can do the same in any language with threads, and a library providing channels. Hell, you could probably do it better with a library, go's channels are unnecessarily error prone with nils, channel closing, and cleanup behavior.