Actually this is not a big news but it’s nice to see on practice X being used on the advanced age :) Here I’ve played with some UI configuration settings, browsed for while, toyed with facebook, opened some photos in the viewer and etc, all for about 5 minutes:
and zooming in the X11 core slice we have:
Moral of the story: as showed on the last figure, most of the traffic from the core protocol is related with window management, window state changes and notifications of positioning for clients. Actual drawing doesn’t happen on the core X11 at all. Everything goes through GL, GLES and similar APIs where DRI2 manages in some way them. And well, XRender is something to be deprecated soon on modern UIs. Its big slice part there is due a bug on Qt for not proper disabling glyphs for font rendering still. Another interesting fact (not on those figures) is that compositor manager is taking ~15% of the total interaction with X server – so then again, not big news for us.
—
This doesn’t necessarily need to use the recent Erkki and Rami’s XRes additions for doing client tracking in the server side, but for who likes to hack on the server side, it’s quite easy to do. The hack I’ve done with Pauli’s help and using XRes version 1.2 is on this branch.
April 20, 2011 at 4:26 pm |
Nice diagrams Tiago. Now let’s get xrender out of there for good :)
April 20, 2011 at 5:21 pm |
thanks Sami. Chatting quickly with aberres today, he mentioned that it’s being cooked the xrender removal, so it’s on the way!
October 17, 2012 at 10:15 am |
[...] I’ve reported about one year ago that some new systems don’t use the core X protocol and just use a few extensions instead. One would claim that this is alright cause the API would be smaller, but my opinion is if things carry on expanding outwards like they have been, we’re going get to a point where the graphics systems becomes unmaintainable. Moreover, it takes too long for the shell developer learn that just a small set of the API is needed. The X protocol flexibility feature in which developers can add many new extension as desired and the lack of a proper API deprecation mechanism is definitely a problem to consider here. [...]