OSNews

Maybe you don't, but the thing that pisses me off EVERY time I use Linux is just how jerky the UI is.

Accelerated X is more than just wobbly windows (and that is something that would be silly to actually keep - its likely there for just showing what CAN be done, not what WILL be in actual implementation)

Going from OSX's beautifully double-buffered, OGL accelerated Aqua to Windows's lucky to not split windows as you drag them quite as badly as in the past, to some Linux desktops where window movement is just appalling, please.

Linux needs this, and updating workspace managers etc will also come in useful.

I don't need this stuff. Sure its fun to play with, by for day to day stuff I find it more annoying than anything.

If it's annoying, than the designers aren't doing their jobs properly. Putting the display server on GL isn't about fancy animations, it's about a number of very practical human interface issues:

1) It's about making anti-aliasing pervasive on the desktop. There is no excuse in 2005 to not have a fully anti-aliased desktop. NeXTStep showed us the way decades ago, and they were running on ridiculously primitive hardware by today's standards.

2) It's about polishing the UI by eliminating flicker and tearing. Again, this is a very old concept, but has yet to reach the desktop except in OS X. Flicker-free animation has been the standard for games since I loaded my first NES cart, and probably a good deal longer.

3) It's about enabling user interface designers to come up with new ways of interacting with computers, inside the existing WIMP paradigm. OS X's animations are actually a huge part of this. Fundementally, animations are about establishing transitions. Transitions are important in a UI, much like they are important in a story or presentation, because they help the user track the changing state of the desktop. Well done animations make transitions more natural, and enable the user to figure out where everything is without thinking as much about it.

4) It's about enabling artists to create more graphically-rich user interfaces. I don't know about you, but all else being equal, I'd much rather read a polished, glossy magazine than a simple, drap newsletter. The computer interface is no different.

Ultimately, it's about providing the mechanisms to allow designers to make interfaces that are both more pleasant to use, and more efficient to use (through a reduction in cognitive load).

I agree with everything rayiner said but the thing he (sorry if you are a 'she' rayiner :-) is that when most people are using the desktop they have an extremely power processor sat on the graphics card doing nothing.

Xgl will offload much of the graphic processing to this currently unused processor and freeing up the load on the CPU!

1) sorry but i dont buy the need for that. maybe im old hat but i just dont buy it.

2) can be dealt with without the need to go opengl. what is needed is some buffering of the desktop graphics. going opengl for that is overkill...

3) maybe so. but again i wonder about the need to go opengl to handle animations. 2d acceleration have been around a very long time.

4) just as long as we dont end up with a polished piece of glass that will shatter if you as much as look at it funny. build it to work reliably first!

as for cognitive load. silly me, but i find that simple recognicable shapes helpe there more then a million and 1 shades of any color

having the ability to create buttons in 1001 diffrent shapes dont help much. it just means that i have to rember what the button is in that interface vs this interface...

This is so true and well-written, I had to blog about it. http://djst.org/blog/2005/12/22/animated-desktop-for-the-sake-of-us...

and that is what we call a lack of vision

compositing is designed to speed things up, to make actions possible. these actions can and should serve a purpose in the arena of user feedback.

not everything comes down to useless animations. but you are probably only used to windows so its immaterial.

Why move away from commandline? Wasn't win 3.1 good enough? What acceleration provides is capabilities to innovate in ways that couldn't previously be done.

While there will always uses of new technology that have no merit other than looking pretty while taxing your computer, advancements like the OpenGL acceleration have given the tools to create more useable interfaces that would be otherwise impossible to create. And often you need the technology in place so you can experiment with it to find a new paradigm. One area I hope they go to is some standard backend that all programs communicate with, which will resize icons, text, and like dynamically as you change the resolution. Among other things it would help those with poor sight to easily move to higher resolutions.

Also, as others have mentioned, there are immeadiate practical benefits as well with anti-aliasing and eliminating problems like flickering.

One technology I believe will be key in the future is storing normal (not game) window contents on the graphics card in vector form.

People keep missing the fact that Cairo antialiases objects to a fixed sized buffer. If the window manager transforms this buffer in any way other than a straight copy all of the antialiasing is lost. Even simple scaling ruins the antialiasing computation.

Storing the window contents in vector form lets the antialiasing computation be deferred (and done on the GPU) only after the window manager has decided on final window placement. Doing this requires GPU based glyph bitmap generation, but this has already been demonstated to work.

Yes, all of this can be done on the main CPU and that line of thinking gave us WinModems!

Simple example:

Ubuntu has this gksudo thing that shades the desktop when the user needs to submit a password. The shading is done to make it clear that you can't do anything else while the dialog is showing.

The problem is that this shading effect has to be done in a way that makes it essentialy just a full screen screen shot, hiding the actual state of the desktop.

With the help of OpenGL an effect like this could be implemented so that you still see the real desktop.

I was thinking that it would be best to put a blurry glass (transparency) effect over (using shadows to imply heigt difference) the desktop to communicate the input block.

I don't call that guy a troll, but I totally agree about that anonymous part. If you write an article (even if it is only an editorial) at least have the courage to tell your name/nick.
It's also sad that osnews noe publishes articles from people hiding in the shadows.

Whether he uses a nom de plume or presents his passport and has it notarized has absolutely no influence on the validity of his ideas.
For all we know he has to work at Novell or something.

>Whether he uses a nom de plume or presents his passport and has it notarized has absolutely no influence on the validity of his ideas.

Nothing could be farther from the truth.

>For all we know he has to work at Novell or something.

Precisely so. And if he did, such information would be an important factor in evaluating the merits of his argument. Worse, the fact that this "editorial" was provided "anonymously" gives me every right (intellectually) -- in fact, requires me -- to dismiss out of hand any points made therein.

This "anonymous editorial" is the most bizarre thing I've seen in quite some time. "Anonymous editorial" comes close to being an oxymoron; at a minimum it is a non-sequitor.

Peter Yellman

So you're saying it's a lie that those very same ideas from someone else would not have the same merit or be equally valid. Thinking that merely working for some corp. entity magically makes someone more intelligent is quite the opposite.

Some_Name I_Just_Made_Up

Its funny people always complain about the anonymous part, I guess DRM/treacherous computing etc doesn't bug.

Mustafa Aziz Ab-durahman Shishmankizi

I read this article thinking, how could this article be published like this? Don't the people responsible for this site know anything about technology?

KDE for sure, and Gnome, i'm guessing support the Composite extension. This gives you a hardware composited desktop. I use it myself with the nvidia drivers and while it's working it gives an amazing look and feel.

X.org 7 was just released and i'm looking forward faster development in the area of hardware acceleration. XGL was just an idea of how this stuff could be done. There are others. I'm sure the best one will emerge on top and that is what we'll all end up using. Video card drivers, as it stands, are low quality in the open source field, and not quite stable in the proprietary field. This is a huge hinderance to developping a hardware accellerated desktop. The pieces to the puzzle are being filled in faster than you think.

Why does it even matter who wrote the article? Just read it and enjoy it ... or not.

He's probably just really tired of getting flamed by everyone every time he writes an honest article.

Insert 2 cents worth: I totally agree that Linux needs this technology. The question isn't why, but why not?

You probably don't *need* that Samsung 80" inch plasma TV either ...

point is, this person has clearly no idea what he is talking about. gnome/redhat are NOT working on X, cairo uses the available X server implementations - just like Trolltech's Arthur in Qt, used in the upcoming KDE 4. so KDE will have a fully hardware accellerated desktop in 2006.

and he also doesn't understand why it is bad Novell doesn't work in the open on XGL. well, it is easy (and has been explained several times): it is just not efficient. they are building it themselves, so the community can not help testing it, the developers that will be using it can not start trying and learning to use it, and the developers from the graphics drivers (like Nvidia and Ati) can't help or integrate it into their drivers.

so - it is a waste of money, as this stupid way of developing just slows down everything. now everyone is waiting for them to release it, and IF they release it is still buggy and mostly untested (unless they spend a long time and lots of money to test it) and no-one knows about it.

stupid stupid stupid novell.

It's not a flame bait. At it's best it's a formulated opinion with a rethorical qeustion. Too bad it was anonymous as that amde me lower the score.

Luminocity is a plugin for the X server as whole to interact directly with the HAL and OpenGL to provide 3D effects for Gnome. XGL is a plugin for X to do the exact same thing, only not neccessarily be localized to a particular window manager. XGL is NOT it's own server, rather it is a standard X server with GLX operating in an embedded fashion. You can see how Luminocity might be paralelled to make the comparison.

Luminocity is a plugin for the X server as whole to interact directly with the HAL and OpenGL to provide 3D effects for Gnome. XGL is a plugin for X to do the exact same thing, only not neccessarily be localized to a particular window manager. XGL is NOT it's own server, rather it is a standard X server with GLX operating in an embedded fashion. You can see how Luminocity might be paralelled to make the comparison.

Luminocity is a toy window manager with a neat compositor. It applies only to Gnome. Xgl is the start of an OpenGl framework to replace X (it needs the old Xserver now....but only until someone picks up Mr. Smirl's work on the Xegl). One is a framework for opengl, the other is a toy to begin learning how to use opengl. They are Apples and Oranges. The only similarity is that they are eye candy buzzwords that use opengl to get their cool effects!

Edited 2005-12-22 21:48

And Thom gave this stupid uniformed diatribe a 10.

Well done Thome!

I forgot to set the value to 7, pressed "rate" too soon. I'll look into fixing that.

i agree. a shame it is. i'm no developer, just been reading some stuff about this, and i can clearly see how stupid this article is. sure thom and the other editors should've known...

Oh and some KDE devs wanted to contribute to XGL, but can't as it isn't open.

Where were they when Jon Smirl made it clear to the community that without support and help from others, he was going to drop development on XGL?

Adam

Ok. To break down your list of laundry complaints.

- You apparently read Seigo's entry out of context. To put it lightly, he was complaining that people outside of Novell aren't being allowed input into the development of XGL. So, yes he was saying Novell is wrong for doing this, and NO, Mr. Seigo did not point out any specific issues with the developemtn process, other than his shutout of involvement.

- This article wasn't a rant on the problems of OSS development. Every week there is a new post of this very site that displays the strengths/weaknesses. I've never heard anyone argue that it was smooth and streamlined. I've been involved in dozens of projects for the past 5 years, and never has one ever been as smooth as a closed developemtn process that is controlled by a management plan. It's not saying the Open way is bad, it's just saying that having a clear idea of what needs to get done makes things move faster.

- Mr. Seigo is allowed his opinions, as is the author of this very article. Nothing is shocking about Siego's comments, but he's getting an all expenses paid trip to the end of the line with XGL from Novell and he's complaining about it. It's just a little nonsensical and kind of crazy to complain about something that (because of the closed development) he has no solid facts about.

- This isn't a KDE vs. Gnome issue at all. The point was made that Gnome has one functonal method of an OpenGL accelerated interface running, with possibly a second to come. This leaves KDE in a bit of a pickle.

- XGL is NOT an independent X server. XGL is just a name for X with GLX running under the hood. GLX is a plugin, Luminocity is a plugin, but both aim to do the same exact thing. Luminocity isn't experimental, it's still being worked on? Read up a bit on that.

- "Why, aren't they allowed to have an opinion?" Yes they are allowed to have an opinion. So is this guy/gal.

"You apparently read Seigo's entry out of context."
How so?

"To put it lightly, he was complaining that people outside of Novell aren't being allowed input into the development of XGL."
Where did I state otherwise?
And then he went to say why such a close process is a bad idea in his opinion.
However, my point was that author of an article that slams Seigo for what he said, should take into account what he said, not just exclaim "where's the problem?".

"This article wasn't a rant on the problems of OSS development."
No, it wasn't about problems with OSS development at all, hence to simply claim that OSS project management is chatic is simply an unfounded, unexplained, yet very broad claim. In other words, the author was trolling.

"Nothing is shocking about Siego's comments"
Yet the author of the article claimed they were, which was my point.

"he's getting an all expenses paid trip to the end of the line with XGL from Novell and he's complaining about it."
Because he want's to take part in the development and think it will actually help with the development of XGL if others could get involved to. Reasonable points, are they not?


"It's just a little nonsensical and kind of crazy to complain about something that (because of the closed development) he has no solid facts about."
How do you know what he knows about it?

"This isn't a KDE vs. Gnome issue at all."
Yup. Just as I said.

"The point was made that Gnome has one functonal method of an OpenGL accelerated interface running, with possibly a second to come. This leaves KDE in a bit of a pickle."
And the point is wrong. First, because there Qt4 with arthur and second, becuase contrary to what the author seems to think Luminocity and XGL are two very different things.
http://www.gnome.org/~seth/blog/relations

"XGL is NOT an independent X server."
Xegl is.

Again, you're cutting and pasting quotes out of context guy. All your answers are moot when compared to the quotes I replied to you with (in their entirety). However, I will have to re-state that XGL IS NOT AN INDEPENDENT X SERVER. XEGL may be, but we're not talking about that now are we? Novell isn't working on XEGL, they are working on X + GLX = XGL. You seem to like to argue. Perhaps you're a bad lawyer somewhere.

"Again, you're cutting and pasting quotes out of context guy."
I haven't. But simply stating it is easier than actually answering, isn't it?

"XGL IS NOT AN INDEPENDENT X SERVER. XEGL may be, but we're not talking about that now are we? "
No, we are talking exactly about this. Sorry, but if you don't have a clue, don't post. Thanks.

"You seem to like to argue. Perhaps you're a bad lawyer somewhere."
Ah, personal insults. I really enjoy your style...

Being the only person in this discussion who has committed code to both the XGL and Xegl projects I probably know what they do.

XGL is a transtion tool while the rest of Xegl gets built. XGL is not intended as a permanent solution.

But given the politics surrounding X currently, Novell will probably ship XGL as a product even though it is intended as a transisition tool.

- XGL is NOT an independent X server. XGL is just a name for X with GLX running under the hood. GLX is a plugin, Luminocity is a plugin, but both aim to do the same exact thing. Luminocity isn't experimental, it's still being worked on? Read up a bit on that.

Luminocity IS experimental. Its basically a tech demo. The creator one day hopes that the cool effects of its compositor might end up in Metacity, but it is not a replacement for Metacity, nor will it be.


Xgl is an X server implementation that, rather than directly accessing chip specific hardware drivers, does its low-level drawing using OpenGL calls. That means Xgl is functionally equivalent to a traditional X server, it just uses a different rendering path. Put another way, Xgl is to X11 as Glitz is to Cairo: it provides the same APIs rendered in a much smarter way.

Luminocity, on the other hand, is a compositing manager / window manager fusion that composites using OpenGL. Compositing and Window managing are all about what you do with client-rendered windows. Luminocity doesn't know what's inside windows, and it doesn't care. Xgl, on the other hand, I would characterize as primarily being about how the contents of windows are drawn (in this case: quickly and with less CPU load, *grin*). Xgl can do some other non-inside-window things like drop shadows, but I'm going to argue later those are mostly expedient demos of cool technology and Xgl is probably not the place we want to be doing those things long term. From the perspective that Luminocity is mostly about rendering windows and Xgl is mostly about rendering window contents, they are theoretically complimentary. At the moment, they can not be used in conjuction with one another (since they both want to directly drive the GL hardware), but they're goals are at least compatible.

Neither Xgl nor Luminocity are complete on their own. Xgl provides an X server and requires a window manager (and a compositing manager?) (and an X server for doing GL calls into, but see below, that will hopefully cease to be an issue eventually). Luminocity provides a window manager and a compositing manager but requires an X server (currently using Xfake or Xephyr, though supposedly there's some plan for modifying the core fd.o X server so Luminocity will work using only the host X server?). With some hand waving (in particular there's no way to hand OpenGL textures residing in the video card between processes), perhaps we could get Xgl to render windows into textures on the video card, and then use Luminocity to figure out what do with those textures. All graphics computations are done by the card, and data flows only once to the card. Perfect! Other than those niggly make-or-break technical details ;-)

http://www.gnome.org/~seth/blog/relations

> It's not about preferences of projects or hurt feelings, it's about removing the most important factors in open source. Cooperation and per review, the process which gives open source the edge.

Is OpenOffice developed by cooperation and peer review, or by a team of full-time engineers 'sponsored' by Sun?
I'm not saying it doesen't happen, son't get me wrong.
My point is that large projetcs are better handled with strong hierarchy, and very few communities are able to attain it like, say, KDE.

Novell is going to to the bigger part of the work, and later open up for (i suspect few) volunteers and peer review - imho simply because it's the way to go for big and complex systems.

A humble opinion.

openoffice is, like mozilla, an bad example of free software. it happens to be GPL or another free license, but that's the only thing it has.

KDE and Gnome are examples of real free software: developed by a community of developers, using peer review and responsive to questions and requests from the community (maybe KDE a bit more than gnome, as the latter has lots of commercial involvement, degrading the user influence & imho experience).

Yes, I'm glad Novell is contributing to open source at all. No one is under any obligation to open the whole development process.

It's not open source then, is it, especially considering that it is existing code and existing open source project hosted on Freedesktop.

I can well see why this article was posted anonymously.

Edited 2005-12-21 23:25

Open source = code that is openly available. There is no requirement that the development process itself also be opened up! By all regards, Darwin is an open source project, but it's development is closed.

There is no requirement that the development process itself also be opened up!

Then you've failed to understand why open source works as a concept. Bringing open source projects in-house is the shortest route to bankruptcy and ensures that the wider community is extremely distrustful of you when you do need their help and that less actually gets done.

They don't have to do it, but it's suicidal for all concerned if they don't. Some of the people at Novell have always struck me as Microsoft type people, except with open source software, and so it has proved.

Hardly. There are lots of open source programs developed very successful at corporation. Darwin and WebKit, to name two, then there is OpenMCL, most of the L4 kernels, etc. Indeed, most academic open source code is developed internally before being opened up. LLVM is an excellent example of that.

I don't see the issue here. If Novell wants to do this by themselves, why get mad at them for it? Lord knows it's never going to get done if the community has anything to say about it...

Geez, you're missing the point all together. The point of Open Source has nothing to do with the development process at all! The whole point to Open Source, is it having the code Open for use, alteration, improvement...you name it. Your logic is flawed and annoying honestly.

It's not open source then, is it?

On that logic neither is Qt or ghostscript. Whether or not something is open source is determined soley by the license it's released under.

am I wrong or you should allow *affordable* (btw) access to the sources of derivative works?
they arfe derivating it, let them work. when they'll be done, they'll open up...

Open sourcing is a tool, a development model, characterized by certain benefits and shortcomings, like any others. Whether anybody chooses to use it, it's their business. If I want to start a project and not open the source, because I think that development will go quicker and better this way, it's my call, as long as I respect all involved licenses.

Doing anything for the sake of that thing alone is a silly idea in general, and so's open source.

Let's wait until Novell completes XGL and see what happens then, shall we? Even if they ship it with SuSE in binary only, like Apple did, what's the problem? SuSE will become a kick-ass desktop and Linux overall will benefit from this. The users will benefit from this.

But I have a feeling they'll try to cash in on the community goodwill too, by open-sourcing the main code, and make some money too, by keeping the out-of-the-box desktop integration and customization proprietary.

Isn't this the best economical model to date for open-source? Giving back and making money for yourself at the same time?

gee isnt that what they are working on RIGHT NOW.

vista is still a year (most likely 2 years) away and wont be that impressive.

basically X is under new management with lot of new efforts and will be leaving windows in the dust...

and in the case of fonts it already has (that is my personal opinion so you cant argue, but my desktop setup is pretty nice in the way of fonts compared to my windows work machine (ugly)

X will be leaving windows in the dust? I doubt that X can never be as good as windows until you have proper, functional, opensource drivers for modern video cards, which are pretty hard to come by. I hope for the day, but I don't think the big two will ever do it.

I don't want to insult or attack you in any way, but from following this whole developement from the outside I got the impression that you stoping work on XGL was about the only thing that happened because of EXA.

Other than that I saw post after post on the freedesktop mailinglist that pointed out that EXA is in no way a replacement for XGL, that it wasn't meant as competition to XGL and that XGL would still be the long term solution.

It's a matter of direction and focus, or rather, a lack thereof. Developer resources focued on EXA represents developer resources diverted from XGL.* As people said, free software developers are perfectly free to choose their own priorities and work on what they desire, and if EXA is the priority, then so be it. By by extension, Novell is perfectly free to work on what it considers a priority, and if that's XGL, well, that's that.

*) Needlessly, as some would argue. I cannot remember who said it, but someone pointed out that for little more effort than it would take to properly accelerate RENDER, you could add the same level of acceleration to MESA instead. Personally, I think RENDER as a concept is flawed, because it merely postpones the transition to OpenGL as the primary API (what happens when somebody wants to texture a Cairo shape with a procedural shader?), but then again, IANAXD, so I'll keep my big mouth shut

Edited 2005-12-21 23:53

"It's a matter of direction and focus, or rather, a lack thereof. Developer resources focued on EXA represents developer resources diverted from XGL."

Well, considering that it was one guy who wrote EXA I never understood where the real problem was here.

I know it also needs to be implemented in the drivers, but from what I hear this is supposed to be pretty trivial, so again, I fail to see why this should be such a large issue.

"By by extension, Novell is perfectly free to work on what it considers a priority, and if that's XGL, well, that's that. "
I don't get it. Nobody said that Novel didn't have the right to work on XGL, on the contrary, everybody praised Novel for working on it.
Aaron Seigo simply disagreed with them working on it in a non public environment and gave some reasons why he thinks this is a bad idea.
Now it is really beyond me why people don't argue against the reasons he gave, but instead build one strawman argument after another.

It's not one guy that wrote EXA. One guy started it and all of the X device driver writers followed him.

Rayiner is accurate in saying that the driver work involved in fully finishing EXA was equivalent to the work needed to get the Mesa drivers in shape for XGL. The developers just chose the EXA route.

In the last few months there's been a little progress on fixing the Mesa drivers to support XGL (DaveA's work) but they are far from being finished and Dave is only working on one driver part time.

XGL doesn't make progress because nobody is working on it, not because it is impossible to do. That's an argument that was used to justify EXA, the X drivers are already done - let's just extend them a little more.

I think you need to realize that "commercial development" and "closed development" are the same thing in the real world. Those of us that work in the software development world know that companies don't just throw money around and pay for the development of software they can't somehow profit from. It would be nice, but that's just not how it works. Name one company that pays for full time developers to only crank out Open Source software. Either way, if a commercial company DOES decide to release some of their code as Open Source, that means that people are free to change it AFTER it is released. If Aaron Siego can't wait that long, then maybe he should just start his own openly developed project to try and release something like XGL.