Announcement

Collapse
No announcement yet.

GNOME Shell Picks Up Performance Improvements For Extensions

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GNOME Shell Picks Up Performance Improvements For Extensions

    Phoronix: GNOME Shell Picks Up Performance Improvements For Extensions

    While days too late for squeezing into GNOME 3.34.0, the GNOME Shell has landed a one year old merge request providing various fixes and performance improvements to its extension system...

    http://www.phoronix.com/scan.php?pag...xtensions-Perf

  • cynical
    replied
    Originally posted by jo-erlend View Post

    Good question. Sounds difficult to me. JS is still single-threaded, isn't it?
    Mutter is written in C, not JavaScript. And Gnome-Shell itself is also partly implemented in C, so the language is not the barrier.

    Originally posted by jacob
    Is the problem that all extensions run within the main UI thread being addressed, or is that too disruptive a change that will have to wait until GNOME 4?
    Way too disruptive. You can read a related proposal for "GNOME Shell 4" here, outlining the changes that need to be made.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by jacob View Post
    Is the problem that all extensions run within the main UI thread being addressed, or is that too disruptive a change that will have to wait until GNOME 4?
    Good question. Sounds difficult to me. JS is still single-threaded, isn't it?

    Leave a comment:


  • jacob
    replied
    Is the problem that all extensions run within the main UI thread being addressed, or is that too disruptive a change that will have to wait until GNOME 4?

    Leave a comment:


  • tildearrow
    replied
    Originally posted by Britoid View Post

    The extension system imho should just be removed or restricted to only a few areas (e.g. adding things on the top status menu).
    That'd make the desktop even less flexible, and after that I'm pretty sure many would move away from it...

    Leave a comment:


  • Britoid
    replied
    Originally posted by 144Hz View Post
    3.34.1 might end up eslint clean \o/ The extensions really need to up their CI game. How can they live with poor hosting on github? No wonder some extensions break when they miss out on Gitlab CI.

    https://gitlab.gnome.org/GNOME/gnome...e_requests/716
    The extension system imho should just be removed or restricted to only a few areas (e.g. adding things on the top status menu).

    Leave a comment:


  • 144Hz
    replied
    treba Problem is that Github CI features remain unused. On Gitlab they share it between gjs, shell etc.

    Leave a comment:


  • treba
    replied
    Originally posted by 144Hz View Post
    3.34.1 might end up eslint clean \o/ The extensions really need to up their CI game. How can they live with poor hosting on github? No wonder some extensions break when they miss out on Gitlab CI.

    https://gitlab.gnome.org/GNOME/gnome...e_requests/716
    While Gitlab is surely great, you can have all sorts of external CI hooked up to github as well. Talking about travis-ci etc.

    Leave a comment:


  • 144Hz
    replied
    3.34.1 might end up eslint clean \o/ The extensions really need to up their CI game. How can they live with poor hosting on github? No wonder some extensions break when they miss out on Gitlab CI.

    https://gitlab.gnome.org/GNOME/gnome...e_requests/716

    Leave a comment:


  • Britoid
    replied
    Originally posted by treba View Post
    AFAIK, 3.35 has not been branched yet, so this is all still going into 3.34
    Possibly 3.34.1

    Leave a comment:

Working...
X