Slashdot Mirror
Next Generation X11
Rene Rebe writes "The German News site Golem is running a report (babelfish translation) about the next generation X11 projects, like the OpenGL X-Server Xgl, Luminocity as well as Enlightenment 17. The report is including many screenshots and five videos."
1. Seth Nickell has posted a few videos showing the Luminocity window manager doing some super Open GL hardware acceleration tricks.
2. Interview: Rasterman Speaks of Enlightenment .17
3. XGL file format specs
Iran captures three CIA agents
Yeah wasn't there a Y windows in the works at one point.
You mean this?
Fresco was the other big contender.
The Linux Kernel is so flexable in how you can customize it for the hardware situation, its a shame you can't do the same thing for X.
Modern X actually does let you plug-in, plug-out all kinds of useless^H useful crap. It has actually matured into a fairly decent system, network transparency or no.
Where this article falls flat is on trying to make us believe that any of what we're seeing is "new". We've seen it all before, just with fewer cheap effects (e.g. the "wobbly windows").
Javascript + Nintendo DSi = DSiCade
enlightenment
luminocity
xgl
Well, y-windows' last release is over a year ago, and Fresco's last frontpage news item was 2003-03. Looks like there has been some work on it, between then and early 2004, with minor changes (based on the nightly snapshot diffs), but not a huge amount. The snapshot tarball has been 4.1mb for the entire time. I have the feeling that both these projects are basically dead :(
Plugged in how?
This is something I spent a *long* time explaining to some people on a forum about a related subject. Network transparency doesn't involve significant overhead, dammit!
There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.
Now, networking indeed can slow things down a little due to things like latency. But that's effectively inexistent if you're talking on the local host. And X already has shared memory communication as well. On Linux there are also the so called Unix Sockets, which is pretty much like TCP/IP, only with even less overhead since it's done locally, so it can be implemented in a simpler way.
However, as far as an application is concerned, an Unix socket and a TCP/IP one are exactly the same thing, so it makes no sense to get rid of network transparency - you wouldn't win anything with that anyway.
That is not the XGL that you are looking for. This is.
Not very good googling.
Schrodinger's cat is either dead or really pissed off...
Don't go there expecting anything you'll be able to use in the near future. I fully expect HURD 1.0 to be released before we're done.
/. is a stream of fools bitching at Mark/Andrew/me for not working hard enough on Y. I work on it in _my_ time, and people telling me what I ought to be doing usually causes me to go do something else entirely.
Please don't join the mailing list and ask "is anyone still working on this?" or "when will feature x be included?", because I'm tired of telling people to fuck off. We're working on it, we'll work on the features _we_ want in the order we feel like doing them. If you want something done you can do it yourself or pay someone else to do it for you.
Apologies for the rant: the usual followup to that link being posted on
Phil
( phil -at- y -hyphen- windows -dot- org )
I guess today is a passable day to die.
Please don't post here such nonsense! Read at least the first sentence on http://cairographics.org/introduction: Cairo is a vector graphics library designed to provide high-quality display and print output.
That's what it is. A 2D vector graphic library with multiple backends, which means you can draw something and choose if you use as drawing backend X11, a PNG file, a PDF file, glitz (OpenGL) or something else.
Gtk3(?) will _use_ Cairo and it's X11 or glitz backend to draw it's widgets!
Oh brother.
...to be used in Linux...
...and its special feature is ability to use opengl rendered screens in place of bitmaps for window drawing...
There is a language being developed codenamed cairo..
No. Cairo is a 2D vector graphics library, not a language.
or Windows. or Mac. It is a cross platform library.
its a GTK fork...
No. It is not. The CVS head version of GTK uses cairo for drawing.
Among its features are multiple drawing back-ends. One is OpenGL, another is Render. Because it is a vector library, it may or may not render to bitmaps - depending on the backend.
A product is already being developed using this called luminocity.
Luminocity is a fork of the metacity window manager that has a built in composite manager that renders to OpenGL.
Now that that's been cleared up...
Schrodinger's cat is either dead or really pissed off...
Right. But you need to do this marshalling one way or another. Remove network transparency and you'd *still* have to provide data in some particular format and follow some particular protocol.
My point is that just getting rid of the network socket won't help you any. You'll still end sending exactly the same stuff but using another mechanism, incurring in pretty much the same overhead.
It's not like getting rid of the socket would suddenly free you from the need of communicating in some standard way with the server. How would it understand you otherwise?
Unless you're still using a 486, you shouldn't have to worry about JPEG decompression using up your CPU cycles. It doesn't require that much power.
That said, I do wish libjpeg was faster and actually made significant use of SSE. Intel's optimized jpeg routines are way WAY faster.
X11 is the standard that X clients and servers use to communicate. What you are thinking of is XFree86, which for all intents and purposes is dead/dying/bad.
The bottleneck in remote X11 display is *not* decompressing and recompressing JPEGs, it is the network. Modern remote-display systems (NX, VNC) already use JPEG compression. And they already work very fast over a LAN; in many cases fast enough that you don't even notice them. You don't have to imagine "very fast thin client Linux boxes", just go set some up!
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Xorg and Xfree are an implementation of the X11 standard. (your thinking of XFree86, which stagnated for years and is now dead, confirmed by netcraft)
Yeah, but I don't think they know it. The funny thing is, they released 4.5.0 (4.4.0 was the one that marked the controversial license change) just a month ago, and I never even heard about it. All the Linuxes and FreeBSD (not sure about NetBSD and OpenBSD) have ditched it in favor of X.org; I don't see why they bother.
LOAD "SIG",8,1
2.6 has MUCH better GUI performance. On par with what I've gotten with FreeBSD (go figure) in the past. I'd keep trying new 2.6 releases if I were you, it's worth the upgrade.
As for integrating GNOME or KDE into X, I don't even know what you mean on a technical level. Perhaps you could give me an example?
You don't think that explorer on Windows compiles seperately from the MFC? It simply links to it as a library (statically or dynamically, I'm not sure, doesn't really matter). This is no different in the Unix world.
I can see how it appears to be different because you have more options here where things change radically. But really, it's not all that different.
The biggest difference is how windows are drawn and messages are passed. With these latest developments, both Windows and X are moving towards the same thing (and I think OS X has been doing this) as far as drawing windows goes.
Killing Explorer in Windows doesn't kill all your apps. The only thing it might kill are explorer windows you had open, and sometimes you won't see all the same tasktray icons (though the corresponding program will still be running). Other than that everything stays up. Heck you can even continue to use most programs without even starting Explorer so long as you don't minimize them.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
If you're communicating by sockets, you have to make two context switches, right? One to call the kernel, and one from the kernel to the X server. Whereas if there was a system API, then it would be just one context switch: you call the kernel, end of story.
That is an argument for putting the GUI in the kernel, not for getting rid of network transparency,
If we count entire paths, it would be: you-kernel-x-kernel-you, vs. you-kernel-you.
No, a "context switch" is from one process to another, a process into the kernel is not a context switch, at least not in the same way.
For example:
1) FP - process 2 process requires save & restore of floating point registers, but process to kernel does not because the kernel does not do FP
2) General registers - process 2 process requires save & restore of all general registers because each process has its own state, when you make a system call, you bring all of your general registers in with you since the "state" of the system is your currently running process. Somem will be saved off in case the kernel clobbers them, to be restored on the way back out to the user process but worst case, that's only one save & restore and if you go back to a different process (which is usually the case, even in your example) then the number of saves & restores is the same either way.
3) There's more, but I'm too sleepy to type any of the rest.
Well, since you're distro-shopping anyway, try here.
Actually, just insert your package manager controls in place of "emerge," and it should be applicable in ubuntu or whatever.
grammar-lesson free since 1999. (rescinded - 2005)
Or even use the task manager to work with minimised windows!
-2A
The revolution will not be televised... but it will have a page on Wikipedia
Um, and how exactly would you communicate? So, you remove the protocol. And then?
An API is an interface that can be provided by instance for a library. Or it can be provided by an application and used by a library (plugins). But your application isn't *linked* to the X server, so it can't just call functions in it!
The only way to make what you say possible would require each application to be in the same address space as the X server, or for the X server to be in the kernel. Both approaches are quite horrible, IMO.
If the application is a module in the X server then a failure in the application can bring the whole server down. And there's no possible to have applications running with different permissions. Just wonderful, we can go back to MS-DOS levels of security and stability!
X in the kernel is a more viable approach, but forget about it. The kernel developers don't want it there for a good reason, and this isn't exactly removing the network protocol anyway - it's an entirely different system that wouldn't even look remotely like X.
I get the idea that you don't know much about software design. I'll say it again: You can't get rid of network transparency that easily! It has to be there because there has to be some way to talk to the server. I'll try to explain this way. Here are the most common forms of Unix IPC:
Network sockets
Unix sockets
Pipes
Shared memory
Message queues
Guess what? Except shared memory all of those are pretty much the same as network sockets. RPC (remote procedure call), which is probably what you mean by "API" works through network sockets. And shared memory is inconvenient to use for some things.
So, again: Unless the X server moves into the kernel, or the application moves into the X server there's simply nothing better than networking to make the application and server talk.
There is a standard API, the X library. It's not like its interface changes every week or something. I don't know of any applications that talk the X network protocol directly.
So, we have that already. You can change the network protocol, and it IS being changed and extended (Xrandr, Render, Shape, etc). But still, you won't get rid of it.
Please take an Unix book and open it. The classic Unix server either forks or multiplexes to handle multiple clients. If it forks, how does the parent server talk to the children? Usually using shared memory, unix sockets, or pipes. How do the children talk to the clients? Shared memory, network sockets, unix sockets, or pipes.
How does the X server talk to clients? Network sockets, unix sockets or shared memory. There you have it. It works *exactly* the same way virtually every other Unix server works. Nothing at all oddball about it.
Under GGI that would be, at best, a VNC style of network transparency, and you'd get a rectangle on the other end of the connection. But GGI isn't a replacement for X; if you were to implement X this way then you'd have multiple xlib implementations which forms a higher level API than GGI, with concepts of windows and whatnot.
Funny you should mention it. The problem with the framebuffer is that the API is bound to the implementation. It's a framebuffer; but that implementation doesn't fully describe the hardware available. GGI has a higher level API, and so the GGI API can be translated into commands to the graphics card that take better advantage of the card's ability. Again, this isn't an X replacement, but an example of an architectural style (which I'm asserting is superior to X's client/server style).Though you were right when you said that X is moving in the direction of an API. Something like the Render extension is the style I'm talking about (at least from my understanding of how such extensions work). It's primarily an API, not a protocol. It can be implemented in terms of the stable X protocol, but to be efficient that is usually shortcutted, using some protocol I know nothing about and probably isn't standard. (Yes, it does it with shared memory or somesuch -- but shared memory isn't a "protocol"; you need to define what you put in that shared memory, not just where it is, and AFAIK these extensions to not try to define that what in any formal way.)
Well actually, yes it does. You still have to marshal pixmaps (a wretched and primitive yet still bloated format) into a shared memory segment just so the server can pull them out of there and transfer them to the graphics driver.
How the hell do you think this works on, say, Macintosh or Windows? Magic elves make the bits appear on your screen? X11 gives you the same choice as any other system: you can either let the server do a copy-conversion, or you can use direct rendering. Most sane people will choose letting the server do the copy for most applications.
And X's implementation of network transparency doesn't give clients any way to tell the server to aggregate events or even tell it to "shut the hell up already" with all the mouseover events over regions where they're not listening to the events.
Huh? You have detailed control over what regions you get what events for. But what's the point anyway these days? Mouse events are not a performance bottleneck on X11.
Network transparency is a good thing. X's implementation of it stinks.
First of all, X11 isn't an "implementation", it's a protocol
Secondly, implementations of X11, like XFree86, do pretty much the same thing Macintosh or Windows do: they have a graphics server process that's separate from the application, and they use IPC to talk to it.
The only thing that "stinks" is that people like you who evidently have no idea what's going on opine about X11's design.
Aha, I think I'm starting to understand the way you think at last. But I still don't see the point.
So fine, GGI has the API concept you like so much, and provides an uniform interface to anything. It's modular, cool and shiny. Now, how do you suggest to make a GUI environment following the same system?
The thing you seem to be missing is that X, or its replacement can't be done this way. So okay, we'll try to do it the Windows way. We'll come up with a nice API so that we call CreateWindow, and a window is made. Now, how does that actually happen?
Well, something needs to make that window. It can't be the application. In the case of GGI/SDL it's simply a problem of translating that high level command into pixels on the screen. But that won't work, you need to be able to run several applications on the same desktop. Just letting several processes call functions and draw stuff where they please is only going to create a huge mess or something useful.
So, how do we solve this? We need an arbitrator, which will assign and manage resources. It will ensure whatever is drawn is drawn in the right order. It will keep track of who owns what, and what is where. It will send messages when something of interested happens, like a paint event.
How, this can't go inside this magical library. How would you decide who is in control? That won't work. The arbitrator must be its own entity and dictate the rules to all who use the services it provides. One example of a system like this is the kernel. A program can't just take a 64K chunk of memory starting at 0x80abcdef, hell, no. The program instead calls the kernel and asks: "I want 64K of memory", and the kernel makes sure there's enough of it, that there's some location big enough, and that the program is allowed to have that much. Then, it adds it at the end of the current process, marks it as used, etc.
Same here. Now, who would arbitrate this stuff? Well, one possibility is the kernel. However, as I mentioned already, this won't happen. The kernel developers don't want it and with good reason. They say that if it can go in user space then it will have to go in user space. And since you can perfectly do all this stuff in user space that's where it will be.
Now that we decided it will be in user space, we know it will run as a process. This process manages resources used by other programs, which also are processes. All of this means both the manager and the users need to talk. And how do we do that?
Well, we can pick: Network sockets, unix sockets, shared memory, pipes, queues. I'll leave out queues because I'm not that familiar with them. Pipes are unidirectional. You can get the same effect, just better with unix sockets. Shared memory is great for sharing data but not for implementing protocols. In a complex event based system you need to be able to poke things and to be poked, and networking does this a lot better.
So, we arrive at using networking yet again! Amazing, isn't it?