Results 1 to 6 of 6

Thread: GNOME's GTK+ Is Still Striving For A Scene Graph, Canvas API

  1. #1
    Join Date
    Jan 2007
    Posts
    15,429

    Default GNOME's GTK+ Is Still Striving For A Scene Graph, Canvas API

    Phoronix: GNOME's GTK+ Is Still Striving For A Scene Graph, Canvas API

    Besides updates on Wayland support at this week's GUADEC conference in France was also an update on the work being done for implementing a scene graph within GTK+ itself and exposing a canvas API...

    http://www.phoronix.com/vr.php?view=MTc1Mjg

  2. #2
    Join Date
    Jan 2009
    Posts
    1,480

    Default

    I read through some of his post (very long) and it didn't fill me with confidence.
    He categorically refuses to use gl for drawing (but compositing is OK), or even consider using SIMD. Yeah, it's hard but lately there's been a decent amount of work put forth in exactly that area (see glamour, but more to the point, romain guy's android font rendering article on medium(https://medium.com/@romainguy/androi...r-c368bbde87d9), and Mitev's instanced rendering (http://blogs.igalia.com/elima/2014/0...d-web-content/)).
    Bassi mentioned using the Thebes(Firefox) drawing library, which, if it could be done would be great, but, as he says, it's not separated out as a library right now and it's c++ (do you know what would be a good use of resources? actually doing that work instead of creating another library from scratch).
    Do you know what isn't c++, has a stateful canvas(image based), an accelerated rendering library, and is cross platform? EFL.
    Both of these projects are small but EFL has what gnome needs NOW without staying over (again). Adding their resources to that project would actually make a big difference. Of bassi wants to create something how about implementing elev8? That would provide a qml-like competitor which, AFAIK, isn't even on the drawing board for gnome!
    Gnome has great ambitions but are held back by technical issues. Why intentionally hamper yourself like this? Is it because of the vast number of gtk apps? Does anyone know what the net change in apps has been from gtk 2->3? My guess is that it's gone down BUT even if it hasn't, and unless it's gone up significantly, it might make sense to just ripoff the bandaid. Gtk goes into maintenance mode and you move forward and implement what the designers want NOW.
    I know this won't happen. These guys built gtk and will not abandon it, when if it's best for the gnome project. They'd rather see the ship sink than their baby starve (a graphic analogy but this is how it looks to me). Now, I'm sure they don't see it this way. They just see more problems that need solving. They're engineers so that makes sense, but the project leads better be looking at the gnome as a whole, and, just as importantly, the next few years and where they see themselves, realistically and taking history into account.

  3. #3
    Join Date
    Dec 2011
    Posts
    2,162

    Default

    Why unify/merge and bloat the widget toolkit?
    Why not just keep these separated?

    It seems they are both good, but for different stuff.

  4. #4
    Join Date
    Jun 2014
    Posts
    46

    Default

    Quote Originally Posted by uid313 View Post
    Why unify/merge and bloat the widget toolkit?
    Why not just keep these separated?

    It seems they are both good, but for different stuff.
    That is actually answered in the text: Because the widgets need it for their fancy CSS theming.

  5. #5
    Join Date
    May 2011
    Posts
    14

    Default

    Quote Originally Posted by uid313 View Post
    Why unify/merge and bloat the widget toolkit?
    Why not just keep these separated?

    It seems they are both good, but for different stuff.
    I think you have a big misunderstanding here. Drawing widget (whatever their complexity) without a scenegraph lead to over rendering, poor performance and poor battery usage. From day one, GTK should have relied on a scenegraph to draw its widget. It is clearly a case where performance was never a matter/subject for this toolkit and Moore's law would solve that problem maybe one day. It didn't. So now, it's catchup time. Qt has had a scenegraph for around 5 years, EFL for more than a decade. You can imagine how much optimization did go in and that GTK now need to develop to get that improvement. So it is not because you add some logic that you are adding bloat. It may actually lead to better performance, memory usage and battery usage.

  6. #6
    Join Date
    May 2011
    Posts
    14

    Default

    Quote Originally Posted by liam View Post
    Do you know what isn't c++, has a stateful canvas(image based), an accelerated rendering library, and is cross platform? EFL.
    Sadly this wont ever happen for personal reason. You can read it on Internet, but Bassi was before an employee of Intel. He was apparently forced to stop working on GNOME technology and instead on EFL. He hated that and did go all over the Internet stating how bad EFL was. Every time their was an article about EFL, he would show up and post some anger their. Looking at the situation now, a few year after those event, is kind of funny, as he is now trying to push a design change in GTK that match what EFL does. Sadly I don't think he is going to ever use EFL for that task.

    Also since now around a year ago, EFL has admitted defeat in one of its design goal. Evas was designed to be a standalone scenegraph that every toolkit could have used. After more than a decade to maintain it standalone, it has been admitted that no other toolkit will ever use it directly and they would rather prefer develop their own scenegraph with limitation than rely on something external to their project. Once that was accepted by EFL developers, they did merge the tree of all EFL component and are now moving to intricate all library more, to ease the maintenance cost.

    Quote Originally Posted by liam View Post
    Both of these projects are small but EFL has what gnome needs NOW without staying over (again). Adding their resources to that project would actually make a big difference. Of bassi wants to create something how about implementing elev8? That would provide a qml-like competitor which, AFAIK, isn't even on the drawing board for gnome!
    From EFL point of view, we are not going to take the road of Javascript. QML has teached us a lot of interesting things, that we better learn from. First of, having the possibility to do any kind of logic in QML really help, compared to edje. But that comes with a price, a JS run time. The Qt developers did spend a lot of time optimizing all they could to make that cost smaller, but JS is heavy and costly. That's why EFL now include a luajit runtime, it is a first step toward a EFL QML-kind theming component, that should be available during next year. As always more hand would help, but nobody is waiting for those to come :-)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •