Announcement

Collapse
No announcement yet.

Accelerated Compositing, Better Video In WebKit

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

  • Accelerated Compositing, Better Video In WebKit

    Phoronix: Accelerated Compositing, Better Video In WebKit

    The Clutter port of WebKit now has better video support and can handle accelerated compositing...

    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
    The improvement here comes not by adopting some new video API but rather handling page composition on the GPU rather than within Cairo itself.
    Who said Cairo does not use the GPU when doiung composition?!
    When running on X11, all cairo does is to issue a simple XRenderComposite call to Xorg, which passes that request to a driver and which then is accelerated by the GPU.

    - Clemens

    Comment


    • #3
      Originally posted by Linuxhippy View Post
      Who said Cairo does not use the GPU when doiung composition?!
      When running on X11, all cairo does is to issue a simple XRenderComposite call to Xorg, which passes that request to a driver and which then is accelerated by the GPU.

      - Clemens
      Your probably mean the opengl backend of cairo (which afaik is not considered stable enough to be enabled on distros by default). Otherwise what's the point of its opengl backend if (almost) all stuff is done on the gpu anyway?
      btw it's been like a year since last version of cairo was released. Is it stalled?

      Comment


      • #4
        Originally posted by cl333r View Post
        Your probably mean the opengl backend of cairo (which afaik is not considered stable enough to be enabled on distros by default).
        No, I ment the "ordinary" X11 backend.

        Otherwise what's the point of its opengl backend if (almost) all stuff is done on the gpu anyway?
        Good question There are a few more things you can do, because OpenGL is a lot more-level than X11 but basically thats it.
        Usually Cairo's opengl backend doesn't perform a lot better compared to its X11 backend when with run with good drivers.

        btw it's been like a year since last version of cairo was released. Is it stalled?
        Cairo's features are quite hard to get right with OpenGL.
        When designing Cairo the developers made some decisions which make quite hard to do some parts of the API in hardware on the GPU.

        In the long term I guess cairo will drift into legacy - even FireFox is trying to get away from it.
        It seems currently effort is beeing put into creating lower-level 2D libarries, which target the specific need of certain apps, at least this is what firefox/opera/chrome do.

        - Clemens
        Last edited by Linuxhippy; 30 November 2011, 11:47 AM.

        Comment


        • #5
          Thanks,
          I'm in favor of replacing Cairo with something that targets hw acceleration right from the start, and not as a later option which always yields second-class decisions because of the need for additional compromises at least in the field of backwards/design compatibility.
          So I hope that what Mozilla is creating will be successful not only on Firefox but also on the (Linux) desktop in general. I worked a bit with Cairo and I don't like it, it can't handle text well enough etc. An almost ideal solution is something like Clutter/Cogl and what latest versions of flash offer, that is, a "2D/2.5D/3D" solution.
          Last edited by cl333r; 30 November 2011, 12:54 PM.

          Comment


          • #6
            Who said Cairo does not use the GPU when doiung composition?!
            Nobody said that.

            What they said is that the application bypasses Cairo and accesses acceleration through a different API now for some operations.

            edit:

            From the blog post:
            Because page composition happens now in the GPU instead of in Cairo, we don't need to copy each frame to a Cairo surface (saving a copy) and don't need either to change the pixel format from whatever GStreamer gave us to whatever Cairo wants.

            Another benefit of using Clutter-GStreamer is that alpha pre-multiplication can happen in the GPU (implemented as a shader), saving more CPU.

            Furthermore (and more importantly), we can use standard GStreamer elements that use the hardware for decoding. Given the proper hardware and driver support, frames could be placed directly where the GPU can find them when compositing the page.
            Last edited by drag; 30 November 2011, 01:02 PM.

            Comment


            • #7
              Originally posted by cl333r View Post
              I'm in favor of replacing Cairo with something that targets hw acceleration right from the start, and not as a later option
              Ironically Cairo was designed with hw acceleration in mind from the very beginning, as it was more or less designed to be the high-level interface for xrender.

              Comment


              • #8
                Originally posted by Linuxhippy View Post
                Ironically Cairo was designed with hw acceleration in mind from the very beginning, as it was more or less designed to be the high-level interface for xrender.
                By hw acceleration I mean decent hw acceleration solutions, xrender afaik was created out of desperation and is the lowest common denominator of the (extremely) crappy state of Linux graphics drivers years ago, which evolved as time went on and the graphics drivers became less crappy. I only consider decent hw acceleration DX and GL, or the video related ones - VDPAU and VA-API (and whatever M$ is using for video). I know you have a different opinion about xrender since you worked with it a lot (the Java XRender backend) and consider it a good hw acceleration solution.

                Comment

                Working...
                X