Announcement

Collapse
No announcement yet.

GNOME Shell Adds VP9 Screencasting, Mutter Improves Wayland

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

  • GNOME Shell Adds VP9 Screencasting, Mutter Improves Wayland

    Phoronix: GNOME Shell Adds VP9 Screencasting, Mutter Improves Wayland

    For the upcoming GNOME 3.15.4 development milestone release towards GNOME 3.16 there are some notable improvements for the GNOME Shell and Mutter...

    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
    Has the VP9 encoder had a speed increase I haven?t heard about? Even the VP8 encoder was pretty slow, and VP9 was worse AFAIK. Or are they just encoding to VP9 as a post-process step?

    Comment


    • #3
      VP8 encoding is not bad for me at all, even on a tri-core Phenom II. It was only slow when using something like earlier versions of Handbrake, which didn't do multi-threading correctly for VP8.

      VP9 is a lot slower though (as expected). It would be nice if GNOME devs made it an option on which one to use, but we know how GNOME devs feel about user options..

      Comment


      • #4
        Originally posted by DanL View Post
        VP8 encoding is not bad for me at all, even on a tri-core Phenom II. It was only slow when using something like earlier versions of Handbrake, which didn't do multi-threading correctly for VP8.

        VP9 is a lot slower though (as expected). It would be nice if GNOME devs made it an option on which one to use, but we know how GNOME devs feel about user options..
        In my testing it wasn't noticeably slower with the settings that we use. If it turns out to be to slow for many people the solution is not "provide an option" but "revert the change" ... so test results and/or bug reports welcome.

        Comment


        • #5
          Originally posted by drago01 View Post
          In my testing it wasn't noticeably slower with the settings that we use. If it turns out to be to slow for many people the solution is not "provide an option" but "revert the change" ... so test results and/or bug reports welcome.
          Fair enough. I guess screencasting is less intensive than trying to encode movies and such?

          Comment


          • #6
            Originally posted by drago01 View Post
            In my testing it wasn't noticeably slower with the settings that we use. If it turns out to be to slow for many people the solution is not "provide an option" but "revert the change" ... so test results and/or bug reports welcome.
            ...how hard would it be to expose a vp8/vp9 or slow CPU/fast CPU screen cast toggle in the control center?
            Do you have data that indicates that to be across the threshold of the paralysis of choice? Or is it just part of the arbitrary coterie of gnome design?

            Comment


            • #7
              Originally posted by liam View Post
              ...how hard would it be to expose a vp8/vp9 or slow CPU/fast CPU screen cast toggle in the control center?
              Do you have data that indicates that to be across the threshold of the paralysis of choice? Or is it just part of the arbitrary coterie of gnome design?
              There is a very large amount of research done on the impact of exposing more decision points on usability

              Comment


              • #8
                Originally posted by RahulSundaram View Post
                There is a very large amount of research done on the impact of exposing more decision points on usability

                http://uxmyths.com/post/712569752/my...igher-satisfac

                Originally posted by liam View Post
                ...Do you have data that indicates that to be across the threshold of the paralysis of choice...
                I'm very aware of this. There exists a middle ground between paralysis of choice, and no options whatsoever. Too few options can lead to just as poor an experience as too many. The art is in choosing the right options to expose, and choosing the best default values for the particular users and use cases you want to support. You can't just point to a general principle as sufficient justification for a solution to a specific problem. So basically, you didn't actually answer me, or defend why this particular choice is one choice too far.

                If it's possible for the system to automatically choose the best codec based on the system capabilities, that would obviously be better than the user having to choose. But a choice in this case could very well lead to a much better experience for users on lower-end hardware, and make not much (if any) impact on users with standard-to-good hardware.

                Comment


                • #9
                  Originally posted by liam View Post
                  I'm very aware of this. There exists a middle ground between paralysis of choice, and no options whatsoever. Too few options can lead to just as poor an experience as too many. The art is in choosing the right options to expose, and choosing the best default values for the particular users and use cases you want to support. You can't just point to a general principle as sufficient justification for a solution to a specific problem. So basically, you didn't actually answer me, or defend why this particular choice is one choice too far.

                  If it's possible for the system to automatically choose the best codec based on the system capabilities, that would obviously be better than the user having to choose. But a choice in this case could very well lead to a much better experience for users on lower-end hardware, and make not much (if any) impact on users with standard-to-good hardware.
                  The general principle is the default position. You admit that the system choosing the options is better and that is backed up by extensive research. So the onus is upon you to show that there is a requirement for such codec version options to be exposed in the UI. "Could very well lead" is very vague rationale. You have to run performance analysis on such low end hardware (if it is really too low end, it won't even run GNOME 3 anyway) and if the performance of vp9 is really unacceptable, you will have to also show why defaulting to vp8 for everyone wouldn't be the best path.

                  Comment

                  Working...
                  X