Slashdot Mirror

← Back to Stories (view on slashdot.org)

New X Proposal on Freedesktop.org

Posted by CmdrTaco on from the one-for-the-techies dept.

Bytal writes "Havoc Pennington (of Red Hat and GNOME fame) seems to have a very interesting entry in his blog on the development of a new extension to the venerable X server going on at freedesktop.org. More specifically it seems to provide for most things that people have clamoring for (alpha blending, flicker-free window compositing and switching, as well as even OpenGL integration) without altering the existing X protocol too much."

5 of 395 comments (clear)

  1. FreeDesktop.org at SCALE 2x by irabinovitch · · Score: 5, Informative
    Seth Nickell will be speaking about the freedesktop.org project and his work with GNOME.org at the Southern California Linux Expo on November 22, 2003. SCALE 2003 will be held at the Los Angeles Convention Center. More information is available on their website at http://www.socallinuxexpo.org

    For a free exhibit hall pass use the promo code 'free'.
    For 50% off a full access pass use the code 'sctek'

  2. Extra Memory Usage by mickwd · · Score: 5, Informative

    "The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times."

    What are the memory implications of this ?

    With many people using resolutions of 1280x1024 or 1600x1200 in 24-bit or 32-bit colour, dual-displays and multiple desktops becoming more common, this could chew up a lot of RAM.

    A single, maximised window at 1600x1200/32-bit is going to use 7.5MB, even if it's just a terminal window. I can quite easily have 10 windows open at one time, especially when web browsing (OK, not all maximised, but not all small, either). There goes 75MB of RAM, just for the screen display (let alone the extra memory X uses for pixmaps, etc). If it's constantly being accessed in order to update the display, it won't be easily paged out to disk, either.

    Things like tabbed browsers and terminal programs help quite a bit (assuming that the contents of each tab won't be stored in RAM - or will they ?). But not everyone likes using them.

    Would someone with more knowledge about the current workings of X care to comment ?

    1. Re:Extra Memory Usage by IamTheRealMike · · Score: 5, Informative
      I am not an expert but I'll answer as well as I can.

      What are the memory implications of this ?

      The reason keithp is going to be buffering each node in the window tree is for memory reasons - buffering entire toplevel windows is far too expensive. It involves two extensions, aXe and XDAMAGE to work correctly. I believe XDAMAGE is partly useful for reducing the work needed to implement eyecandy effects, but it's all new to me too so I'm prolly wrong.

      Secondly, MacOS X gets around the memory requirements partly through heavy use of video RAM and partly through compressing and decompressing toplevel windows on the fly (as far as I know). I wouldn't be surprised if the new X team take a similar route.

      Finally, I don't think OpenGL will feature in this. OpenGL is a neat 3D API but not so great at 2D work - we seem to be heading towards using XRender as our low-level 2D API with Cairo providing a Quartz style drawing system on top. That doesn't imply speed loss - both OpenGL and XRender are abstractions over the hardware acceleration engines of the card, so there's no reason why XRender based apps could not get the sort of speeds we associate with 3D HW accel (even if today it doesn't reach those speeds). The advantage of going the Xrender route is that it's much easier to mix and match the old style and new style rendering (note how OpenGL requires you to set it up for a particular rect but XRender can just be used as a standard drawing op).

      Like I said, no expert, keithp is the canonical source for this, but that's what I've gathered from reading and listening.

  3. Re:Good idea, but not new by Anonymous Coward · · Score: 5, Informative
    This is long overdue in X

    Uh, this idea is called "backing store" and it's been around since, I believe, X11R4. I'm not sure what this proposal does that's new, other than offer new uses for it.

    Given the current bloat of GTK and Gnome when trying to run remotely (even over 100Mbit), backing store is a good thing. When an application lets you turn it on. Which GTK doesn't. Heck, I've even seen a GTK developer claim "X doesn't have any backing store concept." Geez, people, learn your existing technology!

  4. Re:Good idea, but not new by otaylor · · Score: 5, Informative

    Likely the GTK+ developer was me. I certainly didn't say that X has no concept of backing store. I may well have indicated that the current X implementation of backing store quite typically does more harm than good. For instance, under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds in the windows backing store. (Having traced through the X server code to figure out why this was happening some years ago, I can authoritatively say that X does have a concept of backing store.)

    Keith's new extension is quite different from traditional X backing store; the obvious difference is the ability to control how the windows are composited to the screen. But there are other differences; the server, for instance, uses only a single backing store buffer for the entire toplevel window, instead of one for each subwindow.