Announcement

Collapse
No announcement yet.

GTK Scene Kit Continues Making Progress With New API, Offloading More Work To The GPU

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

  • GTK Scene Kit Continues Making Progress With New API, Offloading More Work To The GPU

    Phoronix: GTK Scene Kit Continues Making Progress With New API, Offloading More Work To The GPU

    GNOME developer Emmanuele Bassi has shared the latest work he's been doing on GSK -- the GTK Scene Kit and the much anticipated improvements it will bring...

    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
    This is going to be great. GTK's performance has improved drastically in the last few releases; and this should help even further.

    Comment


    • #3
      after having critized Enlightenment and the EFL (for example https://twitter.com/ebassi/status/575973425224785920), he is adapting their technology (actually Evas, the canvas) to GTK stack. So they are not so bad finally...

      Comment


      • #4
        Originally posted by vtorri View Post
        after having critized Enlightenment and the EFL (for example https://twitter.com/ebassi/status/575973425224785920), he is adapting their technology (actually Evas, the canvas) to GTK stack. So they are not so bad finally...
        Yes, because working for 10 years on a scene graph API integrated with the GNOME stack and using OpenGL to render is, nowadays, considered "adapting Enlightenment and EFL". At least according to Phoronix forum commenters.

        Just for the record: the Enlightenment project did not invent type systems; main loops; event handling; and scene graphs. They are just exceptionally bad at implementing them.

        Plus, I've never criticized the ideas that Enlightenment implements — only their terrible, terrible implementations; their awful project management techniques; their priorities; and the design of most of their code base.

        Comment


        • #5
          @ebassi:
          Browsers like Firefox are nowadays much used and graphics intensive applications.
          How would (if at all) GSK help making Firefox faster?
          As I understand it, Mozilla is (still) working on their own opengl accelerated compositor etc. for Firefox on linux, using currently skia for canvas and (up until now) cairo for other content (talking about nightly builds). Yet Firefox also uses GTK3.
          So would/could GSK be an alternative choice for acceleration, useful only for Browser chrome acceleration or would it somehow tie-in with their current/future work (making all rendering faster)?
          Last edited by Stebs; 06 July 2016, 09:44 AM.

          Comment


          • #6
            Originally posted by Stebs View Post
            @ebassi:
            Browsers like Firefox are nowadays much used and graphics intensive applications.
            How would (if at all) GSK help making Firefox faster?
            It wouldn't. GSK is meant to be used by GTK+ itself and by GTK-based applications that wish to replace Clutter for their UI.

            Originally posted by Stebs View Post
            As I understand it, Mozilla is (still) working on their own opengl accelerated compositor etc. for Firefox on linux, using currently skia for canvas and (up until now) cairo for other content (talking about nightly builds). Yet Firefox also uses GTK3.
            So would/could GSK be an alternative choice for acceleration, useful only for Browser chrome acceleration or would it somehow tie-in with their current/future work (making all rendering faster)?
            Nope; rendering HTML is a very different task, and Mozilla has its own set of tools there — Gecko, and Servo/webrender. I actually used some of the ideas of Servo/webrender when designing and implementing GSK, but rendering a GUI with a toolkit is fairly different than rendering an HTML page.

            Comment


            • #7
              Originally posted by ebassi View Post

              It wouldn't. GSK is meant to be used by GTK+ itself and by GTK-based applications that wish to replace Clutter for their UI.
              So all GTK+ applications will benefit from this or only ones looking for an alternative to Clutter?

              Comment


              • #8
                Originally posted by hussam View Post
                So all GTK+ applications will benefit from this or only ones looking for an alternative to Clutter?
                All GTK+ applications that use GTK widgets, as opposed to those applications getting a GTK window and then drawing themselves on it.

                Comment


                • #9
                  Thanks, clearer now.
                  I think it would be interesting to see gnome-system-monitor use GSK, since it's CPU-usage (mainly from drawing I guess) can make it's own measurements quite noisy (htop ftw ).

                  Comment


                  • #10
                    Originally posted by ebassi View Post

                    All GTK+ applications that use GTK widgets, as opposed to those applications getting a GTK window and then drawing themselves on it.
                    Sounds great!

                    Comment

                    Working...
                    X