No announcement yet.

GNOME On Wayland Is Good For GNOME 3.10

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by jrch2k8 View Post
    1.) again is not "faster" in most cases since those effects are already in opengl/gles/glsl but fluid and glitches free, so the right terms would responsiveness, fluidity, clean, color accurate, frame quality, no tearing, no jagging, etc. faster is too ambiguos.

    2.) yes and see 1

    ofc an good side effect is that you get the chance of look at your code and improve it when you are porting to EGL/wayland and in some cases remove lots of bottlenecks that will translate in more FPS or even find ways to do more interesting effects since X is not in the middle anymore or even heavily improve quality maintaining efficient FPS.

    the only thing that instantly improve when you go the wayland way is memory bandwith pressure[RAM/FB/PCIE], since you don't need to push back and forth 3 or 4 times the same data to finally get X to render a frame and you get rid of that nasty X IPC but not necessarily translate in "faster" or more FPS unless your GPU/CPU are very weak, it just liberate wasted resources that can be now used efficiently and is up to the client how to improve the experience puting those recoverd resources to work.

    in resume wayland work is give you the tools and get out of your way and the wayland clients jobs is use those tools as efficiently as possible, so depending the client, so they can focus on Quality or performance or color accuracy or new effects/techniques,etc.
    Thanks for the thorough explanation. I'm really looking forward.


    • #32
      Originally posted by jrch2k8 View Post
      well im pretty sure timestamps and vsync don't exclude each other but maybe a wayland dev could go into the details of how they can interact with each other, using simple logic you need at least the freq of the vertical refresh since it make no sense to render faster than the vertical refresh when you can use that exceeding time to save power or other more interestesting functions other than discard 300 frames without never reach a front buffer.

      btw i mean vsync for weston and other compositor, couldnt edit after realize used the wrong word
      weston (and I think all other wayland compositors[*]) are vsync'd.. meaning they render to the back-buffer, and then do kms pageflip ioctl to tell the kernel to swap to that buffer during vblank. Well, there is recently an extension to kms pageflip which allows non-vsync'd flips (if the hw supports it), but I don't think that makes much sense to use for a compositor.
      [*] nothing about wayland requires that the compositor renders to the back buffer and does vsync'd page flips.. but for a UI, why would you do anything different?

      Regarding performance/speed/whatever, wayland enables two important optimizations which are not really possible with X. First, with EGL_EXT_buffer_age, it is able to know the state of the new back-buffer after a flip, and only redraw what is out-of-date. So if you just have a small area of screen changing (moving a window, scrolling, etc), the gpu does not need to re-render the entire screen. (This one might become possible w/ X11 at some point.) And second, for hw that supports overlays, it can sanely utilize hw overlays in the display controller to bypass the gpu for some/all composition.

      I'd guess that most compositing window managers that are being ported to wayland, in the first step they probably keep their existing rendering logic as it is just to get something working. Which doesn't take full advantage of the optimizations that wayland makes possible, but for the first step it is more important to get something into the hands of other developers so they can start working on updating apps, etc.