Announcement

Collapse
No announcement yet.

Enlightenment E18 Alpha Release Is Imminent

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

  • #21
    Originally posted by gens View Post
    compositing under X requires copying things around in memory, so it's cpu consuming and makes delays
    This is not generally true and Wayland compositing is not inherently faster than X compositing.

    Let me explain: We all know the famous GLX_texture_from_pixmap extension which allows to use a pixmap as a GL texture. Now X11 pixmaps are stored on the GPU where possible and therefore accessible within OpenGL through this extension.

    X without compositing: Each application draws directly on the screen using X primitives (e.g. pixmaps, but also lines, boxes, text that looks ugly?) and on EVERY screen damage (e.g. a window moved over another) drawing has to be repeated.

    X with CPU compositing: What you see on the display is a fullscreen window managed by the compositor who can use the same X primitives to draw. The application's drawing is performed onto pixmaps available to the compositor. As the compositor keeps these pixmaps, applications are not bothered with screen damage. The compositing process is, as said, done with X primitives and the pixmaps typically reside, as said, on the GPU, so using XRENDER etc. the CPU compositing can still be 2D hardware accelerated.

    X with GL compositing: Here the compositor uses GL commands to draw its window and within these commands pixmaps (the pre-rendered application windows) are directly accessed as textures.

    Wayland: Basically very similar to the X compositing cases, the differences lie in the protocols. For example, applications do not draw primitives anymore but have to provide a pixmap in the first place, even including their decorations. Wayland also has no idea about how to draw text on the screen, be it ugly or non-ugly. Wayland also has no clue on how to bring anything to the screen, this is the sole responsibility of the compositor (e.g. Weston). Obviously there is a direct exchange of pre-rendered windows to the compositor and I don't know how that works. Can the application render into a GL framebuffer (like Qt OpenGL backend) and this is used as a texture by the compositor? I don't know but probably there is a mechanism.

    tl;dr: Wayland compositing is not inherently more efficient or use less content copies than X compositing. The avoidance of extra copies through GLX_TEXTURE_FROM_PIXMAP was the groundbraking feature that made the whole compositing feasible in the first place. Anyone remembers XGL?

    Comment


    • #22
      Originally posted by gens View Post
      afaik they found a victim to improve the file manager

      i use it as a full DE for a while now
      it has its bugs, but not more then any other DE
      I also use E as my main desktop. Apart from some stuff missing its stable and -more importantly- it is not stupid UI/UX wise. But the missing stuff is what doesn't make it ready for everyone.

      Comment


      • #23
        Originally posted by Ericg View Post
        As far as I remember... Full screen apps can request not to be double buffered (bypass compositing). But normal usage does require compositing just to help ensure no tearing and no stuttering
        they don't request at all. the compositor *MAY* at its discretion optimize compositing to tell the hardware to direct-scanout fullscreen window buffers *IF* the fullscreen window has no alpha channel, is not covered by any other windows etc. (in wayland). E17 AND E18 both implement this trick in X11 too - the compositor shuts itself off.

        So Wayland and X11 are the same here compositing-wise. Wayland will force compositing if the compositor can't program a direct scanout. In X11 the same thing (thought if your hardware has multiple hardware layers then Wayland could use them all to redirect buffers to - in X11 you can't do this - but this tends to only be embedded hardware that can do this for multiple RGB(A) layers).

        Comment


        • #24
          Originally posted by BSDude View Post
          I think the fact that E17 took a dozen years to ship is due to the project being independent. Now E18 has taken 1 year to reach alpha and that is due to Samsung sponsoring Rastermann AFAIR on another thread.
          While Samsung does do a lot in this department - it's untrue that this is the reason. E17 just got to that point where it could be released nicely.

          Comment


          • #25
            I think your explanation are a bit off

            Originally posted by ypnos View Post
            X without compositing: Each application draws directly on the screen using X primitives (e.g. pixmaps, but also lines, boxes, text that looks ugly?) and on EVERY screen damage (e.g. a window moved over another) drawing has to be repeated.?
            1) X doesn't have only 'text that look ugly': what about the X render extension which provide glyph cache?

            2) In current X implementation the window manager and the X server are two different process, in Weston everything is in one process, this should be more efficient, I think that nothing in X prevents to have the window manager and the display server in the same process, but current implementations don't have this..

            Comment


            • #26
              Originally posted by ypnos View Post
              ...
              well
              to test i got an usb stick and tried rebecca black os
              nouveau driver
              no noticeable delay, not with mouse nor when moving windows

              weston used ~5% cpu average while moving a window around (didn't check cpu scheduler so it could be ~2% from max cpu speed, anyway X uses more)
              dont know how to check gpu usage
              (i know its not that simple, just a quick test)


              went on to test with xonotic, didnt get far (textures messed up and locks up)
              maybe someone with a radeon driver or a newer intel gpu can get it running


              all X compositors i tried had some noticable delay
              even tried e18 from git cca a week ago

              ofc weston is not a full blown DE so this dosent say much


              also tried quick weston on a laptop with an old integrated intel gpu
              very much mouse delay
              but i dont think it was set up properly so..


              PS theres also AIGLX

              Comment


              • #27
                Untrue

                This statement is entirely untrue:
                "but it won't be until E19 where Enlightenment can act as a Wayland compositor."

                E18 can already act as a Wayland compositor:

                Note:  This blog post outlines upcoming changes to Google Currents for Workspace users. For information on the previous deprecation of Googl...




                Not sure where you get your information from, but you need to check your sources

                Comment


                • #28
                  Incorrect Information

                  full Wayland support but it won't be until E19 where Enlightenment can act as a Wayland compositor.
                  Not sure where you are getting your information, but this is entirely Incorrect !! Please, check your source

                  The compositor inside E18 can already act as a Wayland compositor (and has had that ability for quite a while now)

                  Note:  This blog post outlines upcoming changes to Google Currents for Workspace users. For information on the previous deprecation of Googl...


                  Comment


                  • #29
                    Originally posted by gens View Post
                    well
                    to test i got an usb stick and tried rebecca black os
                    nouveau driver
                    no noticeable delay, not with mouse nor when moving windows
                    You should try resizing windows. That just feels so much smoother on wayland. Also, remember Beryl, which by default only showed window outlines while resizing, because it was so slow?

                    Comment


                    • #30
                      did 'e' ever finally implement wireframe resize and move? I've been asking for that essential feature forever.

                      Comment

                      Working...
                      X