Announcement

Collapse
No announcement yet.

GNOME 3 Might Be Too Resource Hungry To Ever Run Nicely On The Raspberry Pi

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

  • #21
    Originally posted by Vash63 View Post
    Any comment on the chances of the compositor thread being separated from js extensions and anything else?
    There's a lot to unpack, here.

    1. Only one thread can access the graphic subsystem; you cannot touch the GPU from multiple threads
    2. There is no such thing as a "JS extension": all the code written in JavaScript is running in the same context (that's what allows writing extensions in the first place), and all the JavaScript code ends up rendering something — either directly or indirectly
    3a. You cannot move things in separate threads in the hope the garbage collection won't stall the compositing thread because you cannot free a resource created inside a thread from another thread; the Shell has multiple windowing system resources, which means that they have to be freed in the same thread that created them, which happens to be the compositing thread
    3b. If you think this would go away with a different language, you're sorely mistaken
    4. Anything that can be moved to a separate thread — input polling, I/O — is either in the process of being moved there, or already moved; some things, like uploading texture data to the GPU, can cause stalls, but they need to happen on the main thread because OpenGL works that way

    Comment


    • #22
      Originally posted by ebassi View Post

      There's a lot to unpack, here.

      1. Only one thread can access the graphic subsystem; you cannot touch the GPU from multiple threads
      2. There is no such thing as a "JS extension": all the code written in JavaScript is running in the same context (that's what allows writing extensions in the first place), and all the JavaScript code ends up rendering something — either directly or indirectly
      3a. You cannot move things in separate threads in the hope the garbage collection won't stall the compositing thread because you cannot free a resource created inside a thread from another thread; the Shell has multiple windowing system resources, which means that they have to be freed in the same thread that created them, which happens to be the compositing thread
      3b. If you think this would go away with a different language, you're sorely mistaken
      4. Anything that can be moved to a separate thread — input polling, I/O — is either in the process of being moved there, or already moved; some things, like uploading texture data to the GPU, can cause stalls, but they need to happen on the main thread because OpenGL works that way
      Ok, is it fair to speculate that with Vulkan you would be able to do better because it allows more multithreading?

      Comment


      • #23
        I call bullshit on that.. at least extensions could be moved to a seperate JS engine and exchage via IPC.
        Last edited by cen1; 05-31-2018, 09:54 AM.

        Comment


        • #24
          Originally posted by starshipeleven View Post
          Ok, is it fair to speculate that with Vulkan you would be able to do better because it allows more multithreading?
          At the very least, Vulkan allows multiple threads to talk to the GPU/graphic subsystem.

          Comment


          • #25
            Originally posted by ebassi View Post
            You're also missing that GTK+ is not a compositor toolkit; you can't use widgets inside your compositors, and you can only use override-redirect windows, like menus. Additionally, GTK+ does not have a framebuffer backend, so you cannot write a Wayland compositor with it.
            Just switch to Qt and finally make a decent DE out of it.

            Oh, actually, you don't have to - Plasma already exists :P

            (yes, I'm aware Qt in C is a no go. Sadly, GTK+ went downhill in recent versions, and EFL is... well, EFL. Seems there are no good, well supported toolkit choices for C these days )
            Last edited by dos1; 05-31-2018, 08:37 AM.

            Comment


            • #26
              It would be very interesting to know how KDE's Plasma compares to Gnome 3 on the Raspberry Pi.
              ## VGA ##
              AMD: X1950XTX, HD3870, HD5870
              Intel: GMA45, HD3000 (Core i5 2500K)

              Comment


              • #27
                Originally posted by ebassi View Post
                GNOME Shell is a compositor. You cannot separate the compositor from the window manager from the display server.
                https://en.wikipedia.org/wiki/GNOME_Shell
                "GNOME Shell is written in C and JavaScript as a plugin for Mutter."

                https://en.wikipedia.org/wiki/Mutter_(software)
                "Mutter is a window manager initially designed and implemented for the X Window System, and recently has evolved to be a Wayland compositor"

                Comment


                • #28
                  While i never understood the stupidity of Javascript being used in a key aspect of a GUI, i must say Gnome behaves better than Windows 10. That isnt saying much though.

                  As for Raspberrry PI who would rationally run resource heavy Windowing systems on the platform? If you dont understand your hardwares capabilities whom is to blame.

                  this brings up the question; what environment these days is lowresource and performant on such platforms? Enlightenment? KDE ( never liked it)? FVWM (does it still exist)? In any event Raspberry PI has the volume to justify something tailored to its neeeds. Complaing about Gnome on the platform just seeems misplaced in my mind. Now complaints about its behavior on modern hardware designed to run modern operating systems is another thing and highly justified.

                  Comment


                  • #29
                    This is going to be an issue for the Librem5 as well :|

                    Comment


                    • #30
                      Originally posted by ebassi View Post
                      Second: Clutter was developed to work on SoC from 2008, and on netbooks with crappy Atom CPUs and Intel integrated GPUs that barely had fragment shaders. It worked fine on those.
                      And if it worked fine on those shits, then what happened now and can't even run flawlessly on high-end machines?

                      Comment

                      Working...
                      X