Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: Working On The X.Org 7.6 Katamari

  1. #1
    Join Date
    Jan 2007
    Posts
    14,827

    Default Working On The X.Org 7.6 Katamari

    Phoronix: Working On The X.Org 7.6 Katamari

    If all goes according to plan, X.Org Server 1.9 will be released in about two weeks, but after that there still is the X.Org 7.6 release "katamari" to be done. While X.Org releases themselves aren't as important any longer with the X Server releases being done at different points and the rest of the X.Org package collection being modular, the X.Org 7.6 release is expected in October...

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

  2. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,108

    Default

    It's sad to see X gaining bloat and forcing it on users (very little used xcb libs, which in turn force python).

  3. #3
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,792

    Default

    Isn't XCB considered a good thing?

  4. #4
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,108

    Default

    Yeah, it adds support for multi-threaded X client drawing and also supposedly improves Xlib operations' speed.

    The thing is, no app I need has the need to draw from more than one thread, and Xlib op speed is the least of my graphics speed worries. IE - no user benefit at all, just bloat.

    Before libX11 1.4 it wasn't forced, --without-xcb is removed in 1.4.

  5. #5
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,792

    Default

    I thought XCB is intended as a replacement for Xlib/Xt and it makes things simpler for developers.

    Also, what bloat are you referring to? Most stuff I read about XCB is that it reduces bloat and helps performance.

    Furthermore, many programs seem to use it. Here, an "lsof /usr/lib/libxcb.*" gives:

    Code:
    COMMAND    PID   USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
    dbus-laun 2247 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kdeinit4  2295 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    klauncher 2296 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kded4     2298 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kglobalac 2307 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    ksmserver 2324 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kwin      2337 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    knotify4  2360 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    plasma-de 2362 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kuiserver 2365 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kaccess   2377 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    krunner   2386 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    polkit-kd 2387 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    yakuake   2389 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    kmix      2392 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    tvtime    2437 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    ksystrayc 2438 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    thunderbi 2457 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    firefox   2739 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
    Pretty much every application I start uses XCB?

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,108

    Default

    Also, what bloat are you referring to?
    1.5mb of libraries I have no need for, plus on average 2 more linked libraries per X app (thus slowing the start of each app).

    Plus the fact it requires python, which is bloat by itself.

    Pretty much every application I start uses XCB?
    None of those by themselves, all via libX11.
    Very few apps can use it at all, and of those most also have a working xlib backend (mesa, evas).

  7. #7
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,792

    Default

    Hmm, it seems like your only concern is 1.5mb of space, which sounds kind of ridiculous :P

    The extra link stage per X app does not increase loading time, since we're talking about shared libs.

    Also, Python is a powerful tool that has become an integral part of Linux infrastructure, just like Perl. It makes certain tasks very easy to implement.

    So to sum it up, where you see "bloat", I see advancement and development, and making use of existing technologies instead of reinventing the wheel. As it should be. If everyone was sharing your opinion, we would still be using 386'es with 2MB RAM, MS-DOS and Turbo Pascal

  8. #8
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,108

    Default

    Quote Originally Posted by RealNC View Post
    Hmm, it seems like your only concern is 1.5mb of space, which sounds kind of ridiculous :P
    If bloat was accepted, we'd all be running Windows and buying new comps every year.

    The extra link stage per X app does not increase loading time, since we're talking about shared libs.
    Sure it does. I openly admit having read Drepper here
    IIRC it was in his "How to write shared libraries" doc.

    Can't recall how to measure it right now, but there's an env var to show exactly how much time the dynamic linker spends resolving these. Cutting down on shared libs, both linked and dloaded, is why OpenOffice got a start speed boost at one point.

    Also, Python is a powerful tool that has become an integral part of Linux infrastructure, just like Perl. It makes certain tasks very easy to implement.
    It will not become a part of my ecosystem if I can help it. Even perl is not considered always present, see Rob Landley's perl-removal patches to the kernel build system.

    So to sum it up, where you see "bloat", I see advancement and development, and making use of existing technologies instead of reinventing the wheel. As it should be. If everyone was sharing your opinion, we would still be using 386'es with 2MB RAM, MS-DOS and Turbo Pascal
    I'll agree to disagree here.
    I'll also point I'm not against the improvements per se (multithreading, faster xlib), but the way they are implemented. Python, one-lib-per-X-extension approach, and being big additional libs instead of, say, fixing/adding to Xlib.

  9. #9
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,792

    Default

    You will see zero difference if you enable XCB on your system.

    I challenge you. This is Phoronix, which means we even have benchmarks, no? I know what I'm talking about because I had -xcb in my USE flags for ages There is absolutely no negative hit in performance or loading times, which in short means: XCB is not bloat. Far from it.

  10. #10
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,606

    Default

    Quote Originally Posted by curaga View Post
    Can't recall how to measure it right now, but there's an env var to show exactly how much time the dynamic linker spends resolving these. Cutting down on shared libs, both linked and dloaded, is why OpenOffice got a start speed boost at one point.
    Btw, this is why prelink exists.

Posting Permissions

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