5 ms·

Neat. I wonder what performance is like compared to normal desktop environments.

by koeng 1y ago

gigatexal 1y 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.
- munchlax 1y ago
  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?
  - gigatexal 1y ago
    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
  - shmerl 1y ago
    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.
    - winrid 1y ago
      That doesn't require multi threading.
      - shmerl 1y ago
        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.
      - nasretdinov 1y ago
        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
  - wiseowise 1y ago
    “Don’t you guys have fast computers?”
    - munchlax 1y ago
      My computers are old and slow. They run XFCE just fine.
  - Twirrim 1y ago
    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.
  - pjmlp 1y ago
    Depends on how much Electron crap is running alongside the desktop.
  - robinsonb5 1y ago
    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.)
- matttproud 1y ago
  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 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.
  - radicaldreamer 1y ago
    The Project Looking Glass UI came to iPadOS and MacOS via Stage Manager https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/mac https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/...
    - ffsm8 1y ago
      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.
      - bestham 1y ago
        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.
      - heavyset_go 1y ago
        > 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
  - blauditore 1y ago
- SkiFire13 1y ago
  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.
- sapiogram 1y ago
  > 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.
  - tsimionescu 1y ago
    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.
ikiris 1y ago
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.
- andydotxyz 1y ago
  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.
  - nickcw 1y ago
    I'm looking forward to the v2.7.0 - I think this will fix the glacial scrolling on Android which is great!
  - ikiris 1y ago
    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.
    - andydotxyz 1y ago
      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...
pjmlp 1y ago
I bet running circles around the JavaScript mess of GNOME.

Neat. I wonder what performance is like compared to normal desktop environments.

by koeng 1y ago

Neat. I wonder what performance is like compared to normal desktop environments.

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.

munchlax 1y ago
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?
- gigatexal 1y ago
  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
- shmerl 1y ago
  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.
  - winrid 1y ago
    That doesn't require multi threading.
    - shmerl 1y ago
      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.
    - nasretdinov 1y ago
      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
- wiseowise 1y ago
  “Don’t you guys have fast computers?”
  - munchlax 1y ago
    My computers are old and slow. They run XFCE just fine.
- Twirrim 1y ago
  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.
- pjmlp 1y ago
  Depends on how much Electron crap is running alongside the desktop.
- robinsonb5 1y ago
  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.)
matttproud 1y ago
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 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.
- radicaldreamer 1y ago
  The Project Looking Glass UI came to iPadOS and MacOS via Stage Manager https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/mac https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/...
  - ffsm8 1y ago
    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.
    - bestham 1y ago
      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.
    - heavyset_go 1y ago
      > 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
- blauditore 1y ago
SkiFire13 1y ago
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.
sapiogram 1y ago
> 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.
- tsimionescu 1y ago
  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.

ikiris 1y ago

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.

andydotxyz 1y ago
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.
- nickcw 1y ago
  I'm looking forward to the v2.7.0 - I think this will fix the glacial scrolling on Android which is great!
- ikiris 1y ago
  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.
  - andydotxyz 1y ago
    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...

pjmlp 1y ago

I bet running circles around the JavaScript mess of GNOME.