Slashdot Mirror


New X Proposal on Freedesktop.org

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."

9 of 395 comments (clear)

  1. this sounds like a great idea by fizz · · Score: 4, Insightful

    its about time someone does some decent work on the actuyal framework of the xserver, because right now, most limitations are not due to the window manager, rather the server.

  2. cool, now give me media pipes by ikoleverhate · · Score: 4, Insightful

    cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement! x finally becomes less about boring rectangles, and becomes truly fun to hack ;) Lets hope this gets support from enough different groups to make it a standard. And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)

    1. Re:cool, now give me media pipes by julesh · · Score: 4, Insightful

      X already supports funny shaped windows. Have you never run xeyes?

      The only problem with it is that almost all toolkits other than Xlib don't actually support it, so you have to hack around at a low level to use it, but its there, and if toolkit implementors bothered, it would probably become easy to use, too :-)

      And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components!

      You mean some kind of graphical pipeline, where one application transforms the graphical output of another one, and so on? There are graphic libraries available today that allow this kind of operation, but generally they don't operate well with GUIs (i.e. they run with one window that all of their output goes to). My only question is: what would you do with it? I can see that an ability to shrink or enlarge a window might be handy, but that's a much simpler task than the possibilities of what you're suggesting allow for...

  3. Re:without altering existing X protocol "too much" by Short+Circuit · · Score: 3, Insightful

    Assuming xlib isn't statically linked, I don't think there'll be too much of a problem. I'd even venture a guess that simpler applications wouldn't be affected at all.

  4. Good idea, but not new by Chris_Jefferson · · Score: 5, Insightful

    The main principle here seems simply to be for the X-server to store each window, wether it be visable or not. At the moment if you stack windows on top of each other the X-server forgets what is on the covered up bits, and when the window becomes visable again it is redrawn. This was a good idea back when memory was scarce, because storing X full screen applications could take X*screensize memory. However today with more memory, we can store all those windows without forcing a redraw.

    This is long overdue in X, and also as stated makes things like alpha blending, and Mac OS-X style openGL window-dragging acceleration much more trivial, and also for those who like network transparency, won't require resending windows each time they become visable (although adds the new problem that unless you are careful you could end up spending lots of time sending updates to non-visable windows). It is of course nessasary to allow some chucking of hidden windows (because full screen 32-bit images still take up quite a lot of room), but overall its a good plan!

    --
    Combination - fun iPhone puzzling
  5. Discussion summary by binux · · Score: 4, Insightful

    Let's summarize the discussion that this is going to trigger:
    Whine 1: X is slow and bloated we need a replacement.
    Response 1: The XFree86 implementation may be slow and bloated and not the protocol.
    Response 2: Come up with something better and we'll talk.
    Whine 2: Who uses the remote display capability of X anyway?
    Response 1: On local displays X uses shared memory and is fast enough.
    Response 2: If 5% of the users need the feature it should be retained.

  6. Ill advised by amightywind · · Score: 3, Insightful

    This seems to be a band aid solution and complex as well. With OpenGL being so prevalent why not create an X replacement entirely upon it?

    --
    an ill wind that blows no good
  7. All I ever wanted from Xwindows... by zerocool^ · · Score: 4, Insightful

    ...was to be able to cut and paste between applications. A unified API for a clipboard system that uses a unified set of keys to cut and paste.

    Alpha blending should be miles and miles behind the development of a window system that actually works.

    But, this looks to be more typical X development. No brake pedal, but you can shift gears via the steering wheel, the stereo, or a series of buttons on the sunroof; it has 539 airbags, each requiring a different pressure to go off, and there's a seatbelt interface for every previous seatbelt in existance. Plus it has the most efficient 46 horse power engine ever made, even though opening the glove compartment causes it to stall, or at least backfire.

    ~Wx

    --
    sig?
  8. Re:Extra Memory Usage by cK-Gunslinger · · Score: 3, Insightful

    Do you expect your grandma to open her box and install a new graphics card?

    No more than I would expect my grandma to update her X Windows library to incorporate new buffering extensions.