Novell Makes Public Release of Xgl Code

hamfactorial writes "Novell has announced the public availability of the Xgl code, an openGL accelerated X server layer. Available binaries ought to be coming soon for distributions running the modular X.org 7.0 release (possibly 6.9, though unconfirmed). A temporary page for Xgl information is up at the openSUSE website. This is the same code that was running in the Novell Linux Desktop 10 preview videos as seen earlier. Further information is also available at Miguel De Icaza's blog."

Window manager land

[Gopal.V]

Should I kill my fluxbox and use compiz as my default window manager ? Or can compiz actually live along side a normal windowmanager which has about half a year of short-cuts that I use heavily ?

I would love if someone could actually tell me if fluxbox (or indeed xfwm4) will work with XGl out of the box.

Re:Window manager land

[NoMoreNicksLeft]

It's an X.org extension. It's in no way like a window manager at all. At least you don't use gnome or kde, I suppose...

Re:Window manager land

[nathanh]

Compiz is just a compositing manager. As I understand it, it exists independently of Metacity or any other window manager you choose to use.

You understand incorrectly. Compiz is both a window manager and a compositing manager. There were technical reasons as to why it was done this way. Metacity will also be incorporating composite code directly rather than have a separate userspace process.

Re:Window manager land

[Tet]

Metacity will also be incorporating composite code directly rather than have a separate userspace process.

Which doesn't quite answer the question. Can *any* window manager be used, or only those that have incorporated the compositing code? Is it possible to use a standalone compositor (say, at the expense of some performance), or does it have to be part of the window manager? If it's the latter, than the obvious route is to make it a shared library, which the wm can dlopen() as appropriate. That way, you

Re:Window manager land

[nathanh]

Which doesn't quite answer the question. Can *any* window manager be used,

No.

or only those that have incorporated the compositing code?

Only Compiz; the different compositors are not feature compatible.

Is it possible to use a standalone compositor (say, at the expense of some performance),

No.

or does it have to be part of the window manager?

Yes.

If it's the latter, than the obvious route is to make it a shared library,

No.

which the wm can dlopen() as appropriate.

No.

Re:Window manager land

[Tet]

Wow! With a design that braindead, I sincerely hope that this project disappears into oblivion. Linux needs sanity far more than it needs eye candy, and this is without doubt the wrong path to be heading down.

Re:Window manager land

[arkanes]

For a lot of effects, the comp manager and the window manager have to have a high degree of interaction and knowledge of each other. For example, in some CVS versions of Metacity, the window can be transparent while the window decorations are not. This is impossible without merging the comp manager and the window manager. It gets even more complicated when you bring Xgl into the mix. This is not a "braindead" design. It is, in fact, the only possible design. Which you'd know if you worked on or with these p

Re:Window manager land

[Tet]

This is not a "braindead" design. It is, in fact, the only possible design.

Wrong. It is one possible design. The window manager and the compositor have to interact, that I'll grant you. But they don't necessarily have to be in the same process. There are many ways they could be communicating with each other -- using sockets, or shared memory, for example. Now for performance reasons, that might be impractical. As you say, I haven't worked on or with the code, so I don't know. But if that proved to be the

Re:Window manager land

[arkanes]

Seperating interrelated components that are fundamentally linked and have dependencies on each others behavior just because some retard who's read but doesn't understand some comp sci books mouths off on Slashdot is lousy engineering. Especially when said retard doesn't actually know the design or the implemetation.

Re:Window manager land

[arkanes]

You *can* seperate them, of course (xcompmgr, glxcompmgr), but integration with the window manager provides a number of possibilities that aren't present with a seperate comp manager, because it has knowledge of the window managers internals. The previous example of shading window chrome seperate from the window itself isn't possible unless you merge with the window manager. Now, you *could* still keep it as a seperate process and write special-case code for every window manager you can think of. But thats

Open Source community had to complain loudly

[billybob2]

Novell was initially reluctant to release this code -- after all, they didn't have to because the X11 license doesn't contain any forced sharing, copyleft [gnu.org] provisions. The Open Source community had [livejournal.com] to complain [blogspot.com] loudly [blogspot.com] before Novell decided it didn't want to risk losing support from independent developers. One reason they might have wanted to keep the modifications closed was to make a big splash for the release of the Novell Linux Desktop. Another possible reason is that Ximian (and Nat Friedman, who was Xim

Eye candy can make sense

[Max Romantschuk]

Most people who dislike eye candy do so because it slows things down or clutters the UI. Watching these videos and seeing what Apple has done with OS X made me realize that eye candy can make the interface more intuitive when done right. The virtual destop cube -thingy really looked like something usable for a change.

I suspect the possibilities created by hardware accelerated UIs will lay the groundwork for a whole new set of UI paradigms, but the real implications are probably still years away.

Re:Eye candy can make sense

[ardor]

I agree. Furthermore, the current state actually does not make much sense. Considering that, for example, nvidia-chips do not have a dedicated 2D core anymore, the driver has to emulate 2D for the legacy 2D APIs that have been used until now. Essentially, dedicated 2D development is dead; its nonsense to have a 2D core since the 3D one can do everything 2D-related much faster and with extras like blending or shaders.

So right now we have an artificial distinction between 2D and 3D. The vendors have to deal with composite stuff AND with opengl acceleration, sometimes simultaneously. Using OpenGL as the base for everything is much better, since opengl already has a client/server-architecture, driver development gets easier, X as a whole becomes leaner, responsiveness and look-n-feel of X improve, and the CPU does not have to deal with fake transparency stuff.

So its all about moving the 2D/3D-distinction away from the driver into the X server.

Re:Eye candy can make sense

[cyclomedia]

it's also worth bearing in mind that the desktop is *already* 3d... you have windows on top of other windows, objects in front and behind of each other, it simply lacks perspective.

desktop cube: old idea

[raboofje]

The virtual destop cube -thingy really looked like something usable for a change.

Actually, something similar has been available at least since 2002: http://desk3d.sourceforge.net/ [sourceforge.net]

It's still cool of course, and it probably works much better with Xgl.

Re:Eye candy can make sense

[master_p]

What you said seems interesting superficially. But when you examine the technology, you will see that nothing really groundbreaking will come out of this. The only real benefit from using the 3d hardware of a graphics hard for GUIs would be the independence of the image from the underlying video resolution. But since the GUI display will never become a vector display, this benefit will never be realized: all solutions currently implement top-level windows as 'textures', thus the bitmap world is here to stay

Re:Eye candy can make sense

[nathanh]

What bothers me is that the FOSS community didn't seem to take this technology seriously until Microsoft announced it was going into Vista.

What bothers me is that you can make such statements with such conviction when they are entirely untrue. The FOSS community have been working on features like this since at least early 2004. The Xorg/XFree86 split was partially due to arguments over the Composite and Render extensions that are necessary foundations for this demo.

This technology hasn't appeared on your radar because you aren't looking at the right places. If you read xorg-devel, or planet gnome, or freedesktop, then you would be aware that this technology has been treated seriously. The Novell demo came from out of the blue but the FOSS community has been working on the technology for ages.

Re:Eye candy can make sense

[Curtman]

"The FOSS community have been working on features like this since at least early 2004."

3Dwm [chalmers.se] is much older than that. From the PDF available on their web page:

"Initiated in 1999 by Niklas Elmqvist and Robert Karlsson at Chalmers Medialab"

Re:Eye candy can make sense

[popeyethesailor]

MS started Avalon over D3D way back in 2003. I'm not contradicting your post, just making a factual observation.

Re:Eye candy can make sense

[nathanh]

MS started Avalon over D3D way back in 2003. I'm not contradicting your post, just making a factual observation.

Cairo, which is the closest Free Software equivalent of Avalon, also began back in 2003 [keithp.com]. However the comment you were not contradicting was about Vista, not Avalon.

Re:Eye candy can make sense

[popeyethesailor]

As far as I know, Cairo is just a 2D graphics lib; Avalon's scope is a little more than that - it atleast includes both 2D/3D, a markup language for UI development, animations, audio/video support,text handling, among other things. And it was originally targeted for Vista(Longhorn), though back-ports exist for XP/2003.

Re:Eye candy can make sense

[FireFury03]

What bothers me is that the FOSS community didn't seem to take this technology seriously until Microsoft announced it was going into Vista.

The FOSS community _has_ been taking this technology seriously, it's just not hit the main-stream. (Seems to be the case with most FOSS GUI stuff that Apple and Microsoft get there first with the shiny bits.)

From the screen shots I've seen of Vista it looks like the 3D UI features (e.g. 3D windows, etc) are ripped off Project Looking Glass and OS-X, both of which have b

Re:Eye candy can make sense

[Macka]

OS X is fine for users trying to run two or three windows but for serious users that run ten or twenty programs at once it just is in the way

You need to learn how to use the OS X desktop more effectively then.

1. Map your Exposé functions to the screen corners from the "Dashboard and Exposé" option in System Preferences. I've got the following mapped: Top-Left-Application-Windows, Top-Right-All-Windows, Bottom-Left-Start-Screen-Saver, Bottom-Right-Desktop. Its way faster than having to hunt out F9-12 between mouse movements.

2. Make better use of Command-H to hide an app and its associated windows instead of iconizing. It keeps the dock from getting cluttered up

3. If things are getting too busy on the desktop use Option-Command-H to hide all the other apps except the one you're working on. Instant clarity.

4. Remember that you can bring an app (and all its associated windows) to the foreground by clicking the app icon in the dock.

As a serious user who's been using Mac OS X for 3-4 years now, full time, for both work and home I can tell you that the OSX desktop does not get in the way if you make full use of the available features. On the contrary, its a pleasure to use.

Re:Eye candy can make sense

[denominateur]

Or you could just have 4 to 6 virtual desktops and a list of ALL programs that can be accessed using alt-TAB, without messing with all those pesky osx features... man I hate osx even more than windows.

Re:Eye candy can make sense

[Lussarn]

OS X and windows has the same problem, cluttered Dekstops. As you say you need to hide the programs. When on UNIX I don't have overlapping windows, I use virtual desktops. It doesn't clutter and works really well. I manually position my programs the way I like to have them, that way I know where they are. On Win and OS X the windows can be all over the place where there is enough space at the moment. I don't see anything you just explained that changes that. No thanks. I don't want to search for my programs

Re:Eye candy can make sense

[Gulthek]

So use virtual desktops:

Codetek Virtual Desktop Pro [codetek.com]. I've moved beyond virtual desktops myself. I used to be incredible anal about my virtual desktops going so far as to label them by program type or even by program. When I switched to OS X from Linux two years ago I was annoyed by the lack of virtual desktops and focus follows mouse, but now with expose and the dock I find virtual desktops clunky and hard to use.

Re:Eye candy can make sense

[xtracto]

I agree with you in this sense, I have never understood what is the functionallity of the "transparency", I mean, what is the big deal, I can blend the content of all the stacked windows on the screen. Aside of the "coolness" factor It is confusing.

Why would you like to make lets say, your Firefox window transparent and having under that OpenOffice Word and under that your desktop image showing the moving world clock, what you will see at the end is, Nothing, just a mess of blended images.

Really, someone pl

Re:Eye candy can make sense

[10Ghz]

I have never understood what is the functionallity of the "transparency"

It looks cools. I for one would like to see the unfocused windows become partially transparent. It would effectively differentiate the focused windows from the unfocused windows. You might say that "we don't need something like that". And you are right. But if I had to choose between two functionally identical systems, with one of them being gorgrous and the other one being ugly, I would choose the gorgerous system.

There's nothing wrong

Re:Eye candy can make sense

[xtracto]

Yeah... you and me sure have very different tastes... [imageshack.us]. I prefer to squeeze every CPU cycle for the work I am doing :)

Re:Eye candy can make sense

[10Ghz]

Yeah, I need every bit of CPU-power to surf the web, draw images, check email... I guess I could reduce my compile-times by 0.3% if I eliminated all eye-candy. But OTOH, that would make my computer-usage a bit less enjoyable, so I fail to see the benefit.

And to be honest, that screenshot looks like crap and it's very unproductive IMO. Just because something looks like crap does not mean that it's "efficient". and just because something looks good does not mean that it's inefficient.

Re:Eye candy can make sense

[TheRaven64]

There are three schools of thought when it comes to this kind of thing:

1. Eye candy is pretty, and we need more of it.
2. Effects, used in moderation, can provide important visual clues to the user making interaction easier.
3. Eye candy distracts me from my work.

Microsoft tend to sit in the first camp, with a few lone voices in the second. Apple tend to be more in the second camp, but with a strong leaning towards the first. Most open source developers seem to be resolutely in either the first or third group.

Re:Eye candy can make sense

[miyako]

There is one instance when I've found transparency to be very useful in OS X- and that is with the terminal. It is incredibly nice to be able to code in a terminal window and have documentation open beneath the terminal so that you can simply look through the code to see you're documentation.
The thing about transparency isn't that you want to have all your windows transparent, it's that you want to be able to have one window open full screen and still be able to quickly reference another window.

Re:Eye candy can make sense

[pthisis]

As an alternative, you can have focus-follows-mouse and put the docs on top of the terminal.

One of many reasons I hate click-to-focus, autoraise, and other things that force the window with focus to also be the on top.

Finally!

[rsilvergun]

Real Transparency! But who's providing the hardware accel? This is still kinda sticky, right now your choices boil down to nvidia's closed source driver (not that I have a problem with that), ATI's bug fest (sorry, but it's true), or a really old Radeon. Oh yeah, while I'm idly wondering, what are the odds of this making it into mainstream desktops ( stock gnome/kde )?

Re:Finally!

[crwl]

The open source R300 drivers (http://r300.sourceforge.net/ [sourceforge.net] - now part of Mesa/DRM + X.Org source trees) for the 9600 and 9800 series of ATi Radeons seem to be currently at least somewhat usable.

I mean, at least Planet Penguin Racer (ex-Tuxracer) seemed to work fine, 3D acceleration and all..! :P

Re:Finally!

[SillyNickName4me]

I have played with those drivers (actually, I'm kinda stuck with the new xorg ati drivers and dri because the kernel I use doesn't work well with the 'old' dri module).

They are nice, tho fairly incomplete as far as r300 support goes. It is a real step forward tho, and the difference with pure software rendering is huge.

For those with slightly older cards, the difference is quite substantial as well. For the first time I have seen a 9200 perform at least good enough to be usable for things like enemy territo

Re:Finally!

[Anonymous Coward]

I think Nat Friedman was using a Centrino Vaio laptop with 512 mb of RAM and a GeForce 6xxx card for his preview demo of Novell Linux Desktop 10 at the Linux Solutions show last week in Paris (and it was pretty fluid). I don't know which driver he used though.

Re:Finally!

[PhilRod]

Oh yeah, while I'm idly wondering, what are the odds of this making it into mainstream desktops ( stock gnome/kde )?

Well, to some extent it's already there: KWin uses COMPOSITE to do translucency and shadows, for example.

There are plans to extend use of these features in KDE 4. Zack Rusin from KDE, has been working on this sort of thing (you can see an interview with him from the Summer [ox.ac.uk]). There's also the Plasma [kde.org] project, which has beauty and usability as its key aims built in from the start.

And best

Re:What kind of hardware is used?

[aussersterne]

They've always been rock solid (not to mention easy to install) for me, across multiple GeForce generations. This is on Red Hat and multiple incarnations of Fedora with SMP systems. Many, many hours of gaming, with FSAA and all effects on. I think I may have had what appeared to be a graphics hang *once* in all the time I've used them (about three years).

Re:What kind of hardware is used?

[drgonzo59]

Rock solid on Ubuntu all version of drivers : from GeForce to FX5700. NVIDIA was actually chosen consistently for upgrades because it had stable linux accelerated drivers.

Re:What kind of hardware is used?

[Sterling Christensen]

From my experience the nvidia drivers aren't very stable.

That's odd. What card(s)/motherboard(s)/kernel version(s)/nVidia driver version(s)?

They've always been perfectly stable with my GeForce 4 MX and GeForce FX 5700. A motherboard with Via AGP and an nForce 2 motherboard (all nVidia chipsets, nVidia AGP etc). Stable on Arch Linux, Gentoo Linux, kernels compiled with GCC 3.3.x, 3.4.x, and now 4.1 beta, and stable with both the kernel's AGP driver and the nVidia driver's built in driver.

The only trouble I

Re:What kind of hardware is used?

[arevos]

I found that hardware acceleration on X.org with a 5900 worked flawlessly, whilst a much older card (300 or something) crashed after only 5 minutes of hardware acceleration being switched on. There does seem to be stability issues with older NVidia cards.

Re:What kind of hardware is used?

[Henk Poley]

nVidia Corporation NV17 [GeForce4 MX 420] (rev a3) on an Asus A7N8X-X motherboard (nForce2 chipset). Versions around 6xxx began crashing on the KDE splashscreen. Current versions (just tried 8178) crash on Kopete's textballoons.

Besides that, they still don't work well together with the 2.6 kernel's slightly changed ACPI model. Which makes them crash the system at resume time when using Software Suspend 2 (the driver doesn't POST and reinitialise the card like it should do).

The system is otherwise rock solid

Re:What kind of hardware is used?

[Janek Kozicki]

I'd like to know what kind of hardware they used to create the demo's. From my experience the nvidia drivers aren't very stable.

I belive it's the problem with your hardware, since I had similar issues. My max. uptime was 19 days after that a total freeze of the system (or at least X lockup). After one or two months my GeForce6600 got badly damaged http://janek.kozicki.pl/z/karta.jpg [kozicki.pl], and the reseller had replaced it. But my system still was unstable, and after some investigation the power supply was rep

Re:What kind of hardware is used?

[FireFury03]

I'd like to know what kind of hardware they used to create the demo's. From my experience the nvidia drivers aren't very stable.

In my experience, stability hasn't been a problem for nVidia drivers released over the past few years (it was a problem 4 or 5 years ago but they seem to have sorted it). There are still some niggling bugs (not usually stability related) which would've been fixed a long time ago if the drivers were open though... I think a public bugzilla would also help so we can see the progress

Re:Use on thin clients?

[drnlm]

Xgl -> an Xserver running ontop of OpenGL. i.e. all the X11 drawing calls are converted to OpenGl calls executed on the underlying 3D hardware of the display. It's still just an xserver, so any remote client will still be able to connect and run.

Whoa

[strider44]

This is a great advertisement for Novell here - their servers have lasted something like ten minutes already after posting 4 videos on Slashdot!

A little preemptive.

[Stalyn]

"Xgl has already been checked into the public repositories, Compiz will be checked in after David Reveman's presentation at the X conference."

Which is Feb, 8th at 10am PST. [x.org]. Also the XGL code has been available for some time. Browse the CVS [freedesktop.org]. I'm somewhat expecting an update of the code tomorrow too.

Debian

[Saxophonist]

Wow! I can't wait until this hits Debian stable, probably in the Debian 15.8 release in 2028.

Re:Debian

[1310nm]

You give them too much credit.

I predict version 5 by that time, and Xgl will still be in an unstable apt repo.

Re:Debian

[Curtman]

"I predict version 5 by that time, and Xgl will still be in an unstable apt repo.

And packages.debian.org [debian.org] will still be broken, as will search.debian.org [debian.org]. Seriously, they can't have been working very hard on it. It'll be two years in May [archive.org].

Lazy asses.

Re:Debian

[Karora]

<TrollFodder>

Clearly this is contradictory. If you "can't wait" until it hist Debian stable then you are looking for a release which is less stable than Debian stable.

The reality is, of course much simpler. Odds are that given it's optional "runs on top of Xorg" nature it will be available in Debian testing within 3 months and will consequently be released next time the 16000 or so Debian packages are declared stable enough for a release.

</TrollFodder>

Re:Debian

[Jeff DeMaagd]

I guess the only way to point out the truth on this site is to work it into a joke.

The last couple times I expressed disappointment in how far behind Debian Stable can get, I was marked as a troll several times over. And no, I won't load unstable or experimental software onto a server or workstation if I can avoid it, I'm just saying that Stable can move a bit more more often and not get so behind.

Re:Debian

[muyuubyou]

That may be a valid point for libraries or server-related packages, but for anything that has to do with a windows manager, you're just wrong about your concept of stable. You're looking at "unstable" or "testing", or Ubuntu which isn't any more stable than any of those two BTW.

It's just that their choice of names is a tad misleading.

Re:Debian

[squoozer]

How about this for a solution. Debain make a stable server version and a stable desktop version. The server version can be as stable (or even more so) as the current stable releases. The stable desktop version would be released every 6 to 12 months and be pretty damn stable but not as stable as the server version. That way you get the benifit of most of the stability on the desktop without falling horribly far behind. I'm currently tracking unstable because I don't want to fall too far behind but I would pr

Come on guys, stop complaining!

[BerkeleyDude]

This is great news! Weren't we waiting for the Xgl?

Why is everyone complaining about Novell, graphics drivers, Debian, and lots of completely irrelevant topics?

Nothing can make Slashdotters happy...

Re:Come on guys, stop complaining!

[BerkeleyDude]

Now you'll need to add complaining about slashdotters' complaining to your list.

Damn... Not only that, but also slashdotters' complaining about my complaining about their complaining...

very pretty, but what does it do?

[semiotec]

I watched the demo movies, the last one (Spinning Cube) especially looks quite impressive.

However, I am wondering if the step from 2D to 3D desktop is as significant as say, going from commandline to GUI.

It doesn't seem like these 3D desktops actually offer much more functionality than existing 2D desktops. For example, the screen captures of Looking Glass 3d desktop from Sun doesn't seem to offer much more than just some eye candies. Or in case of the spinning cube demo, it doesn't seem to offer (functionally) more than virtual desktops, essentially a fancy way of changing from one desktop to another, which probably can still be done faster with some keyboard shortcut.

I am trying not to sound like some diehard stubborn conservative who wants to bring back the glory days of command line only interface, rather, I am asking if 3D desktops will change the way that we interact with computers, in the sense that barely anyone remember what it was like to work in DOS? Is this a step towards to (gasp shock horror) VR-based interfacing? Will a new hardware tool be needed like the mouse was necessary for the transition away from commandline?

Re:very pretty, but what does it do?

[ardor]

Well, its a new tool for UI design. As with all tools, one has to learn how to use it properly first. For example, OSX shows that alphablending can be useful.

The main advantage is the sheer responsiveness. Everything feels more fluent, and lags are no longer noticeable.

Re:very pretty, but what does it do?

[Lisandro]

Forget 3D desktops - the real beauty of Xgl is that allows the use of OpenGL to render parts of your desktop, which means your video card won't just be using 1% of its potential anymore. This is done by OSX and it means faster and sleeker graphical desktops.

Also, combined with the new X.Org extensions (Compositing, Damager, Cairo) it means, of course, eyecandy [novell.com] galore :)

Re:

[account_deleted]

Comment removed based on user account deletion

Re:very pretty, but what does it do?

[Lisandro]

Well, instead of having X.Org using system memory you'll have your video card using video memory - which on most laptops are the same thing. And even then, it's not like you can't disable it.

Re:very pretty, but what does it do?

[Lisandro]

I don't think so, no. Atleast, until real 3D displays become available. A 3D desktop like that Xgl demo is nice to look at, but doesn't really improve usability, IMHO. It's a solution for a problem that doesn't exist.

I recall trying an addon for Windows that placed the desktop on a sphere. Nice, but not really useful. The spinning desktop on the video is very similar to 3D-Desktop [sourceforge.net], which only adds a nifty way to switch between virtual desktops. It's really cool to look at, but, say, an horizo

Re:very pretty, but what does it do?

[oneandoneis2]

I had a few [oneandoneis2.org] thoughts [oneandoneis2.org]about desktops going 3D a while ago, if you're interested.

It basically says that, instead of making 2D windows go 3D, we should throw away the whole concept of "windows" and switch to multiple 3D layers instead

Re:very pretty, but what does it do?

[GauteL]

There are many things this can do. Functionally, the fastest way of minimising a window is to simply make it disappear. This, however, can be confusing because it is not obvious where the window went. A fancy window shrinking effect like on OS X thus improves usability. If done correctly you will not lose time on it either.

Functionally, the fastest way of switching virtual desktop is to simply make the old one disappear and the new one show up. This, however, makes most users think all their applications cr

Re:very pretty, but what does it do?

[dr.badass]

However, I am wondering if the step from 2D to 3D desktop is as significant as say, going from commandline to GUI.

This kind of thing isn't really 3D. Yes, it uses 3D visual effects and all, but the overal metaphor involved is still 2D. That's why you don't see much new functionality. Even the cube-rotation virtual desktop is just a visual cue for a 2D movement. Instead of thinking "that window is on desktop #2", the user can intuit "that window is to the right of where I am now". There's still a lot of

Re:very pretty, but what does it do?

[squoozer]

It's hard to say what the benifits are because we haven't really had the tools to play with yet. What I think history shows though is that given the tools we generally find something to do with them. I admit that we don't always find something good to do with them but that's part of research. I think in 5 to 10 years we will look back and wonder how we ever worked on 2D desktops. I wouldn't like to say what the final 3D interface will look like though - my guess would be that this is the first step towards

Windows and OS X versions

[idlake]

I think what will be more important than XGL will be the Windows and OS X versions; the currently available free X11 servers on those platforms tend to be slow and feature-limited. Apple's X11, for example, doesn't handle international keyboard input correctly, doesn't implement RANDR, and doesn't adapt to changes in screen resolution correctly.

Finally!

[sepelester]

I've been waiting a long time for this. And this [gnome.org], and this [beaglewiki.org], and this [nat.org].

I'd sure like to see 3d GTK+ widgets and window decoration, all following the same global illumination, complete with specular maps [3dtotal.com] and all the advanced pixel shader techniques available the desktop could become truly beautiful.

Re:Finally!

[ciroknight]

"I've been waiting a long time for this. And this, and this, and this."
GNOME Storage: Dead.
Beagle: Braindead.
Dashboard: oh dear christ.

The one thing about the whole GNOME project which is about to uproot me and make my move back to QT, is their extreme dependance on Mono. Not only does this put them in legal limbo, it doesn't fix the problems underneath, thus it's building a zoo on top of a house of cards.

I've played around with GNOME Storage, it was a disaster. (No wonder it died; installing a ke

Look is important

[William Baric]

I can't understand why there is so many posts saying that eye candy are not important. For people who can't judge the internal quality of a software, how it looks is what tell them if it's good or not. You can't impress a PHB with some C code, but you can sure impress him with a lot of eye candy. I need this very badly to be able to "sell" linux to my client as a desktop and I need it BEFORE Microsoft do it.

Target Vista

[cyberjessy]

The target surely seems to be Vista. If Linux did not do this it would have meant that Vista would have a free ride with fancy hardware accelerated 3D transparent glassy glossy grossy interfaces. For J6P, the OS is only as good as it looks.

Since Miguel is involved I sure hope we can target all this hardware accelerated goodness with Mono as well. Mono makes making Linux apps amazingly easy, atleast for those of us with years of Windows programming background. This step is absolutely essential for Mono while

What's a Composite Manager?

[Chris Pimlott]

I know what a window manager is, and I understand the idea of a resolution-independent GL display layer, but would someone mind filling me in on why we now need a composite manager as well as a window manager?

Re:What's a Composite Manager?

[thebluesgnr]

"My understanding while talking to David Reveman this past week was that the complexity of keeping a compositing manager as a separate process from the window manager was too high (too much bookkeeping that made it error prone, and there were some fundamental problems that he could not solve). So some time ago he abandoned his effort to patch Metacity and have a separate composition manager, reduced the complexity and eliminated a lot of bugs and the source of these bugs. That is what David explained to m

Re:

[account_deleted]

Comment removed based on user account deletion

Proprietary software

[Arandir]

From the article: "...we're not going to cede 3D graphics acceleration to proprietary software."

But will we be required to use a proprietary video driver to get it? It would be nice if Novell were putting its resources behind open source drivers or pressuring the release of hardware specs. Proprietary firmware doesn't bother me at all, but the drivers (both kernel and user mode) for open source systems need to be open source themselves.

Re:Videos?

[Organic_Info]

Can't be bothered to check the article links hey? Check the Novell link.

http://www.novell.com/linux/xglrelease/ [novell.com]

Re:OMG XINERAMA PLEASE!

[Organic_Info]

The project is fresh out development and your already whining for what it might not have.

And to think when the news first broke that this would be initially developed in house there was outrage, but you comment exemplifies why they started development away from the "community".

Question is are you going to do anything to help the project?

Re:OMG XINERAMA PLEASE!

[ooze]

You are aware that your sig line is originally attributed to Diogenes of Sinope. And Tyler and Diogenes have really really much in common (to the point where you could say Chuck wanted to create a Diogenes with a masterplan and cool fighting skills). Except that Diogenes was a real person (in both senses, he wasn't the imaginary evil twin of anyone and also not a character in some fictional work). At least there are more indications for Diogenes to have actually existed than for Jesus.

Not to take anything a

Re:OMG XINERAMA PLEASE!

[Organic_Info]

I didn't know that - thanks :)

Its a good day when you learn something new.

Re:OMG XINERAMA PLEASE!

[xtracto]

Just a comment, you should add that to Wikipedia [wikipedia.org], I found that interesting, but could not find any reference over there :-)

Re:OMG XINERAMA PLEASE!

[elleomea]

3D does work on ATI cards (at least using the open source driver) for large screen resolutions using MergedFB. You're correct that there is a limit to area for 3D support, but a higher resolution still works, it's just only applications within that region have working 3D acceleration (anything outside that region just appears black).

Re:Wow

[ardor]

Then again, guess I'll have to go get that high end video card just to run the next distro. :)

No, actually not. The rendering presented in the video does not need a 7800. This is basic 3D rendering most on-board graphics chipsets can handle. This functionality has been around for a decade in consumer cards.

Re:Wow

[Pecisk]

And don't forget to add that it is WHY XGL and XEGL is important - if we can show that Linux can use for example, those Intel 3D onboard cards (GraphicsExtreme2 or something) for such eye candy, well, it is as 10:0 in basketball in one quater. It IS important to get lot of new users, even advanced ones, to Linux/Free desktop bandwagon.

Re:Wow

[IamTheRealMike]

Using XVideo via 3D does require a card that supports pixel shaders though, and according to glitztest my GeForce4MX isn't really up to the task. So I'd have to upgrade at least.

Re:Wow

[SillyNickName4me]

I think that's a genuine danger - that you up the requirements for Linux

Seeing how pretty basic 3D hardware can do this, and how it takes load off of the cpu, it is actually more likely to lower the hardware requirements for building a nice looking and responsive desktop with Linux.

Re:Is this mean, I can finally enable Composite?

[ardor]

In xgl you should disable it, the extension is present anyway (no matter whats written in the xorg.conf).
Also, if you have a nvidia hardware, you should disable it in xorg.conf.

Re:Is this mean, I can finally enable Composite?

[m50d]

You mean you can't? With the nvidia binary drivers you have to add Option "AllowGLXWithComposite" "true" to the Device section since glx stuff isn't properly composited, but it still works.

Re:Is this mean, I can finally enable Composite?

[Lisandro]

Indeed. I've tried compositing on my XFCE desktop and a nNvida FX5200 with the binary drivers, and i had these beautiful window shadows and the ability to set window transparency. It works, and works now.

    Unfortunately, nVidia binary drivers still don't properly support glx (OpenGL) if compositing is enabled. The option you mention forces it, but you still get weird graphical glitches everywhere. For the time being, if you can live without glx, try compositing. Really cool stuff.

Re:Is this mean, I can finally enable Composite?

[m50d]

It isn't properly supported - any GLX stuff won't have transparency, and, because of how composite works, you may well find that if you hide glx windows the glx stuff is still visible on top of everything else. But it mostly works, and I know I only use glx for fullscreen things anyway.

Re:Is this mean, I can finally enable Composite?

[Mo6eB]

It is a bit more complicated than that. Xgl doesn't work all by itself - it relies on having a working OpenGL enviroment. In this case - Xorg. So you run Xgl on top of Xorg and Xgl implements RENDER and GLX, by passing relevant calls to the OpenGL system of the underlying Xserver. COMPOSITE is also turned on by default in Xgl, but it does NOT use the underlying server's COMPOSITE.

It will take some time until all this is finally merged into Xorg and we have an OpenGL-accelerated desktop without the need of

Re:Is this mean, I can finally enable Composite?

[Anonymous Coward]

No. GLX still doesnt play ball nicely with composite enabled, BUT, it doesn't have to. XGL is another X server running atop of Xorg's X server - so it has it's own composite implementation. In other words, you still have to disable the composite extension from xorg.conf, but it really doesnt matter, because XGL will be able to produce eye candy anyway.

Re:What?

[Bazzalisk]

Is it just me or does cadu, based upon that post, fail the Turing test? :)

Re:That's not progress

[Bazzalisk]

Just to point out that it can be quite beneficial to have a slight pause before submenus open - it prevents button-bounce from causing you to select the first item in the menu immediately instead of having a chance to choose one ... yes I have had that problem personaly when menu delays weren't setup correctly in a program and it was a real sumbitch to use the damned thing.

Moral of the story: best and most usable interface design is not necessarily obvious at first glance.

Re:That's not progress

[TheLink]

Button bounce? Well that hasn't been a problem for me.

In fact, you sure it's not caused by all those delays? Having to click more times due to the sub menus not opening immediately - and thus you clicking to open them. More clicks = more chances for errors.

If you have problems releasing fast enough, have you tried it Apple/Mac style? Keep holding the button down after click, and release only when the cursor is on top of the item you want to select.

Re:That's not progress

[sholden]

Because moving the processing to the GPU wastes so much CPU...

Still a waste.

[TheLink]

Whatever, it's still a waste and a disappointment.

I wouldn't mind except that it's been 30 years, and computers are thousands of times faster with magnitudes more storage.

And here we are getting excited about transparent wobbly windows?

OK, maybe Mr Englebart was way too advanced for his time. So lets call it 20 years since Apple, Amiga, Atari etc. If we have such low expectations no wonder we're still stuck with such crappy automotive and aerospace tech too.

Re:That's not progress

[Adnans]

Having animations and other silly stuff (like _pauses_ before actions)just adds latency, and wastes CPU.

What? I think you haven't tried the xcompmgr style setup at all, or else you wouldn't be making this IMHO very un-informed rant! How can offloading the compositing to hardware that actually has specialized circuitry to deal with is be a waste of CPU??? In my experience it actually save gobs of CPU for the simple fact that expose events are reduced to a fraction of what they currently are!! No excessive

Re:That's not progress

[TheLink]

" watching someone get through their daily grind faster "

How is all that animation stuff going to make things faster? It's faster to just display/vanish a window immediately, rather than draw the animations. You could of course do the animations in a "ghostlike/background" way, and allow immediate access to whatever is now actually on top, but the animations could still be distracting and get in the way.

Experienced[1] workers really wanting to do stuff faster should get rid of these "cutscenes".

Now, somethi

Re:competing with cairo?

[nickallen]

Cairo is a 2D graphics library for applications to draw things on the screen and Xgl is an X server that can process the cairo requests (usually through the XRender extension) and accelerate them through the graphics hardware. So they are completly different things and there is no waste of resources. In other words Xgl is an implementation of the X Window System and Cairo can output to many different windowing systems as well as X (eg MS Windows or Mac OS X).