Announcement

Collapse
No announcement yet.

GNOME 3.37.2 Released As Another Step Towards GNOME 3.38

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

  • GNOME 3.37.2 Released As Another Step Towards GNOME 3.38

    Phoronix: GNOME 3.37.2 Released As Another Step Towards GNOME 3.38

    GNOME 3.37.2 is out as the latest development snapshot in the quest towards the stable GNOME 3.38 desktop environment this September...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    GNOME Shell has the new capability for indicating apps that should always run on discrete GPUs
    No. It has the new capability for indicating the apps that should NOT always run on the DEFAULT GPU. You can argue if this is really useful and if this is really what developers wanted to do in the first place, but it is what they actually did by naming the property PrefersNonDefaultGPU. On desktop systems with two GPUs typically the default one is discrete and the non-default one (hence the preferred by apps using that property) is the integrated one.

    I'm grabbing popcorn because I suspect looking at the results will be a lot of fun. I wonder how the heck could such a stupid name go through unnoticed. But never mind, it's Gnome after all, i can't expect much from it anyway.
    Last edited by lucrus; 07 June 2020, 06:44 PM.

    Comment


    • #3
      So, notebooks usually have two GPUs, a default one and a high performance one you can optionally switch to.
      This .desktop file setting does nothing but automatically launch with the high performance GPU as it was intended by gnome and the freedesktop people.

      Comment


      • #4
        Are the GNOME developers still saying that multi-threading won't come until 4.0 (if that even happens).

        Comment


        • #5
          Originally posted by Alexmitter View Post
          So, notebooks usually have two GPUs, a default one and a high performance one you can optionally switch to.
          This .desktop file setting does nothing but automatically launch with the high performance GPU as it was intended by gnome and the freedesktop people.
          What if I am using a 4K monitor (and using the high performance GPU by default because the integrated one is too slow for that resolution)?

          NonDefault is the integrated one, right?!

          Comment


          • #6
            Unfortunately it is difficult to figure out which one is default unless they add in some speed tests or heuristics.

            On my PC the integrated GPU only has DisplayPort and my Monitor is HDMI, so the discrete GPU is used as the default. I can't reasonably expect the feature to work better - if they used the name "more powerful", it wouldn't be correct. If they use discrete/not discrete, it would fail at the situation where both GPUs are discrete.

            Besides, the naming is from the Freedesktop specification which they implemented. If it can be fixed it needs to be fixed there.

            Comment


            • #7
              Originally posted by Space Heater View Post
              Are the GNOME developers still saying that multi-threading won't come until 4.0 (if that even happens).
              Technicaly multithreading has always been used. AFAIK as of 3.36 Gnome Shell doesn't do any IO in the main UI thread, which is one of the main reasons behind its massive improvement in reactivity and performance. What you probably refer to is the idea of running Gnome Extensions in separate threads so that they can't hang or slow down the UI. From what I've read that is still not going to happen before 4.0 because of the massive redesign in would require.

              Now if you ask me, it's not so much the multithreading that concerns me (that is basically an implementation detail anyway). What I would love to see would be to ditch the concept of extensions written in JS and hooking into the Shell's core functionality, and the over-reliance on third-party, unvetted extensions in general. Gnome Shell should offer a basic but full featured user environment from the start (including maximise/minimise buttons, tray, applications menu etc.) and extensions should be possible in the form of separate processes interacting with the core over DBUS. The DBUS-based extension API should of course be sufficiently useful but still limited in scope, such as adding new items to the top bar, creating new bars/panels (such as the Dock) and new menu options, and possibly hooking a SMALL number of Wayland events.

              Comment


              • #8
                I recently installed Pop_OS 20.04 and gave the new gnome there a try over the last couple of weeks... alas this weekend I installed KDE again. I love Pop_OS but even after they did that neat tile window extension, I could not get Gnome to work for me. The issues mentioned above with min/max buttons, their app "finder" and the general performance of the desktop I find personally just painful after extended use.

                KDE may have the Qt drama that happened this year but its still much more productive than Gnome... at least I find it so.

                Comment


                • #9
                  Originally posted by jacob View Post
                  Gnome Shell should offer a basic but full featured user environment from the start (including maximise/minimise buttons, tray, applications menu etc.)
                  Already available on GNOME Classic section selectable on Log In screen for these users looking for a more legacy interface.
                  GNOME Shell Classic
                  Caption

                  Comment


                  • #10
                    Originally posted by 144Hz View Post
                    3.34.7 and 3.36.3 modules had new releases as well. Long term support without all the LTS speak.

                    This is great news for SUSE, Fedora, Ubuntu and Debian.
                    Yes, Fedora packages were updated recently. I found nice Wayland advantage over X. When playing Quake Live, using alt + Tab and switching to another workspace the mouse is stuck in Quake in X. In Wayland it works as expected.

                    Comment

                    Working...
                    X