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.

Multithreading doesn't automatically make stuff smooth. It allows you to increase throughput, but it can also increase latency if don't have enough work or you split it too much.

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.

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.

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.

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

The Project Looking Glass UI != The Project Looking Glass They are talking about the UI which could have inspired Stage Manager. Apple also had the purple window button before Project Looking Glass so there is that.

> [...] that Apple would sue Sun if they moved forward to commercialize it – Jobs felt the project infringed Apple's intellectual property.

Classic Apple.

Jobs dropped such suggestions after he was informed Keynote would get hit back

What are you guys doing with your desktop environment that you need it to be performant and multithreaded?

Aren't all computers plenty fast enough now?

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.

Depends on how much Electron crap is running alongside the desktop.

We are called power users ;-) we can do more than one thing or ten things at a time and want things to be responsive and fast and not drop frames and not crash the whole session when some plugin fails etc etc. you know, a well designed thing

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.

That doesn't require multi threading.

If it does almost nothing - may be not. Otherwise you'll be doing something in the main thread which will take time, unless you also squeeze concurrency (i.e. multitasking) into one thread and then again, why not use multiple threads already.

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

“Don’t you guys have fast computers?”

My computers are old and slow.

They run XFCE just fine.

You'd think, wouldn't you? But in some regards they still feel less responsive than the desktop of a sub-10MHz machine from the 1980s.

(I'm not kidding - the tight coupling of quadrature-based mouse counters and hardware sprite mouse cursor - bypassing all the wireless, serial / PS/2 / USB encoding and decoding we have today - and on-screen gadgets being drawn and redrawn in the input subsystem's context without messages having to trickle through a ten foot long pipeline of frameworks and UI toolkits, all gave a sense of immediacy, of "having the computer's full attention", that's rare to find in today's world of janky semi-functional web apps.)

> 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.

While I agree on channels, you can't easily reproduce the behavior of Go's threads in other languages. The whole Go IO library is built with support for Go's green threads. The result is that 1000 Go threads waiting on IO operations will actually issue only a handful of OS non-blocking IO calls and have the runtime handle polling and waking up the right threads.

Not sure how relevant this is for UI operations, to be fair. The C#/JS style async/await model actually seems more amenable to controlling which works happens on the necessarily single GUI thread and which parts happen in background threads, and how to sync them later.

Based on the name its probably based on Fyne... Last time I tried to use fyne was not great. They overly fixate on mobile first to the detriment of any other platform.

Fyne has never been focused on mobile first - it is platform agnostic. Desktop performance is incredibly fast and mobile performance is nearly as good (Fyne v2.7.0 will deliver a huge speed boost this month). If you haven’t tried it in a couple of years I highly recommend you give it another go.

I'm looking forward to the v2.7.0 - I think this will fix the glacial scrolling on Android which is great!

This is also the type of response you’ll get if you bring up any issues. Their marketing people will come argue with it instead of trying to fix things. I basically gave up dealing with them and went back to suffering through qt. The project looks promising and I’d love to use it but the actual experience is regret every time I’ve tried.

I don't understand this - are you calling me a marketing person? I started the project and continue to do most of the coding. Feel free to tell me I don't know what I am talking about but I would like to know more what we can do to dispel the idea of being mobile focused...

I bet running circles around the JavaScript mess of GNOME.