X.Org is the new kernel

[avilella]

Hi,

I think now that we have a kernel that is pretty much the most advanced kernel in the world, what the OSS community needs is to make X.Org the best in the world as well.

I think Phoronix understood this, and they are paying a lot of attention to the developments of X.Org. I enjoy reading the X.Org posts on Phoronix, as I enjoyed reading about kernel developments some years ago, when the really exciting things were happening. Luckily, a lot of developers are turning their attention to X.Org-related development. I am sure we will see the same kind of success in X.Org development in the near future as we saw in kernel development in recent years.

I would like to see some more posts in Phoronix about X.Org and the current state of the technology compared to Apple's and Microsoft's graphic libraries. What is X.Org doing better than Apple? What does Apple OSX have that we don't enjoy in X.Org yet? How is Microsoft doing with Aero and future releases?

Cheers,

Albert.

[Huenengrab]

Interesting point. But isn't it quite hard to compare two closed-source developments with a pretty open one?

[avilella]

Interesting point. But isn't it quite hard to compare two closed-source developments with a pretty open one?

Yes, I agree. Still, one can compare the final product features, compare the performance, etc. Phoronix has been doing a great job at comparing performance with different versions of a given software, different OSes on the same hardware, etc.

There is also information coming from the experts in the field. I remember watching a seminar given by K. Packard and someone else on the current state of X.Org and the X server (FLOSS conference?), and they mentioned general features where X.Org is doing better than Apple's windowing system and other features where X.Org is doing worse. I found it really interesting and I could see Phoronix publishing more things like that.

[deanjo]

Interesting point. But isn't it quite hard to compare two closed-source developments with a pretty open one?

Actually most of OS X is opensource (including the kernel) and very well documented.

http://developer.apple.com/referencelibrary/index.html

http://developer.apple.com/referencelibrary/OpenSource/index.html#//apple_ref/doc/uid/TP30000943-TP40003594

[avilella]

Actually most of OS X is opensource (including the kernel) and very well documented.

http://developer.apple.com/referencelibrary/index.html

http://developer.apple.com/referencelibrary/OpenSource/index.html#//apple_ref/doc/uid/TP30000943-TP40003594

My understanding is that the OSX Window System is NOT opensource or BSD-licenced, but closed-source and kept with secrecy. I may be wrong. But yet, we can compare the features/performance of it to X.Org.

[avilella]

By the way, here is a 5 year old post comparing X and Apple's Quartz:

http://developers.slashdot.org/comments.pl?sid=75257&cid=6734612

Things we'd need to add/extend in X Window software (protocol+server+manager+fonts+...):

1) Extend font server and services to vend outlines and antialiased masks, support more font types, handle font subsetting.
2) Extend drawing primitives to include PS-like path operations.
3) Add dithering and phase controls.
4) Add ColorSync support for drawing and imaging operations, display calibration
5) Add broad alpha channel support and Porter-Duff compositing, both for drawing in a window and for interactions between windows.
6) Add support for general affine transforms of windows
7) Add support for mesh-warps of windows
8) Make sure that OpenGL and special video playback hardware support is integrated, and behaves well with all above changes.
9) We find that we typically stream 200 Mb/sec of commands and textures for interactive OpenGL use, so transport efficiency could be an issue.

[hmmm]

perhaps phoronix continue the current x-org articles with topics like:

evolution of x-org over the last 5 years compared top os-x (quartz) n windows (GDI -> WPF )

Short interviews with people like Keith Packard, Adam Jackson, Daniel Stone, Dave Airlie atc. Possibly even a regular column by someone at tungsten?

icc/colour correction/monitor calibration article dealing with little cms or similar techs like gegl.

[deanjo]

evolution of x-org over the last 5 years compared top os-x (quartz)

Any comparison to Quartz right now would be dated. 10.6 has some pretty radical changes coming under the hood.

[Thetargos]

Until it is released, any comparison is still valid. I'm not sure how long away is Snow Leopard (if the name will stick we'll have to see) still, but in the mean time, their current tech is 10.5, I think it would be possible to compare Xorg 7.4 (XServer 1.4) to Leopard.

I agree it would be an interesting comparison how do Quartz and Xorg compare... Without Window Managers (where Compiz is way beyond what both MacOS X and Windows)

[puelocesar]

Hi all, I registered just to ask why we can't have argb things on Xorg without composite, and mac users can have argb and even nice animations with windows with just a basic vga driver..

I think that's sad, because I installed hackintosh some time ago and even when it didn't recognized my video card, I had nice animations like "place", "show desktop", "dashboard", and even shadows, and with linux I need to turn on composite that's very slow on some configurations..

[avilella]

Interesting. Is this the same as "Alpha compositing"?

http://en.wikipedia.org/wiki/Alpha_compositing

One of the points in the slashdot post about "why Apple doesn't use X.Org" is:

5) Add broad alpha channel support and Porter-Duff compositing, both for drawing in a window and for interactions between windows.

I think this is a very interesting discussion. So, am I right in thinking that X.Org does has alpha channel support using the composite but not without it?

I googled a bit and found a blog post about ARGB support for Qt:
zrusin.blogspot.com/2006/10/argb-windows.html

not sure if this is with composite on or off...


Hi all, I registered just to ask why we can't have argb things on Xorg without composite, and mac users can have argb and even nice animations with windows with just a basic vga driver..

I think that's sad, because I installed hackintosh some time ago and even when it didn't recognized my video card, I had nice animations like "place", "show desktop", "dashboard", and even shadows, and with linux I need to turn on composite that's very slow on some configurations..

[Thetargos]

Hi all, I registered just to ask why we can't have argb things on Xorg without composite, and mac users can have argb and even nice animations with windows with just a basic vga driver..

I think that's sad, because I installed hackintosh some time ago and even when it didn't recognized my video card, I had nice animations like "place", "show desktop", "dashboard", and even shadows, and with linux I need to turn on composite that's very slow on some configurations..

Actually, you CAN have a basic set of effects with Xorg, and true, thanks to the Composite extension, with 2D drivers only. However Xorg doesn't do that by itself, it requires an application to actually make use of these capabilities. Compiz one such application, that does its magic through OpenGL hardware acceleration, using the 3D pipe on a GPU, however Composite doesn't require this. Other Composite managers can achieve nice effects as well, on 2D. For example, XFWM4 (XFCE 4 Window Manager) has a composite manager embedded in itself, and supports a wide arrange of effects, all done in 2D, such as Shadows, window opacity, and I believe they are working on advanced animations. Metacity has had a composite manager in it, for some time, but has been largely unused... Until recently, some distributions have it enabled by default as of late, even in absence of 3D drivers, as it can work with only 2D drivers.

However, what you say is true: Composite performance is very dependent on the speed of the actual 2D drivers, and to compensate "software" composite eats up more CPU cycles than for instance, Compiz (provided good driver support, of course), however with mild effects (shadows, for instance) the overhead may be negligible.

MacOS X's drawing method is more refined and as far as I know, they also do much of their stuff in "software", not necessarily in "hardware" (in the traditional way), but that has more to do with the window manager or Desktop Environment than purely the windowing system.

[puelocesar]

Thanks for the answering!

Now that you say, I remembered some time ago that I used kcommpmanager (or something like that) to get drop shadows with kwin3

But it was bugged as hell..

So if I understood you, the problem is not with with Xorg, because it's supports composite with 2d. The problem is with the lack of composite managers?

I'm asking because I'm great fan of shadows and the window effects of mac, like Exposè, but compiz or kwin4 is takes too much resources on some machines to be usable..

I'll google a bit about this composite manager in xfwm4

[TechMage89]

The other thing to remember about MacOS is that they have the advantage of tying their stuff closer to the hardware, because they know exactly what configurations their OS will be running on.

Also, the Metacity compositor works in Gnome 2.22 (it can be enabled in gconf), but right now it suffers from performance problems (I think it makes too many pixmap copies before drawing onscreen.)

[puelocesar]

The other thing to remember about MacOS is that they have the advantage of tying their stuff closer to the hardware, because they know exactly what configurations their OS will be running on.

Also, the Metacity compositor works in Gnome 2.22 (it can be enabled in gconf), but right now it suffers from performance problems (I think it makes too many pixmap copies before drawing onscreen.)

Well, it indeed seems a good advantage, but, and a big 'but' there, I already installed hackintosh on some machines, and even when it didn't supported the graphics card and failed to vga driver, it had very nice animations like dashboard, exposè, show desktop, and very nice shadows.. well, at least it has the most beautiful failsafe I already saw :P lol

I was looking for the xfwm4 compositing stuff, and I found this:
http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency#KDE4

I specially liked the phrase: "I didn't spotted _any_ speed lowering."

I will see if I can enable this (or hope that kubuntu packages are compiled with that flag)

[puelocesar]

Sorry to flood the topic, but I just tried xrender on kwin4 and I have to say that's freaking kool! I can get all that effects (exposè, show desktop, dim inactive, translucency, and even desktop grid) without a 3d driver at all (tested with nv driver)

here a shot: http://puelocesar.deviantart.com/art/Kool-Desktop-4-88502608

The only thing I miss is the shadows, but Lubos Lunak commited this month a patch that solves the problem :) Just need to wait for 4.1 beta2 now :)

Well, thanks for the people here who opened my eyes to this solution :D I'm pretty happy right now with my linux box

[Jade]

Hi, I think now that we have a kernel that is pretty much the most advanced kernel in the world, what the OSS community needs is to make X.Org the best in the world as well.
Would you trust the people who will not let Reiser4 into the kernel, not only have control over filesystems, but also have control of graphics drivers.

The Linux saboteurs (see http://www.phoronix.com/forums/showthread.php?t=9509) have sabotaged Linux's best filesystem. What makes you think they will not sabotage graphics drivers as well.

But maybe it doesn't matter, as the open source graphics drivers are already completely sabotaged (and have been for many years).

[StringCheesian]

What Xorg needs is to be useful enough to graphics driver developers that they don't feel the need to reimplement parts of Xorg inside their drivers.

What is up with that anyway? I've heard the nVidia driver has its own internal alternatives to all kind of Xorg stuff. And Intel having to write GEM to replace TTM... Was Xorg just not designed for 3D or something?

[Aradreth]

Would you trust the people who will not let Reiser4 into the kernel, not only have control over filesystems, but also have control of graphics drivers.

The Linux saboteurs (see http://www.phoronix.com/forums/showthread.php?t=9509) have sabotaged Linux's best filesystem. What makes you think they will not sabotage graphics drivers as well.

But maybe it doesn't matter, as the open source graphics drivers are already completely sabotaged (and have been for many years).
Why must you spam that link whenever something to do with the kernel comes up. It's pointless the few people who actually want to read your "theories" know where to go so you don't need to keep pointing it out.

[bridgman]

What Xorg needs is to be useful enough to graphics driver developers that they don't feel the need to reimplement parts of Xorg inside their drivers.

What is up with that anyway? I've heard the nVidia driver has its own internal alternatives to all kind of Xorg stuff. And Intel having to write GEM to replace TTM... Was Xorg just not designed for 3D or something?

That's pretty much the case -- Xorg was not designed for modern 3d -- but most of the work going on right now is intended to improve the integration between X (which has been primarily 2d) and 3d (which has primarily been used through DRI for the last 10 years). DRI largely operates outside X (for speed) but has just enough hooks (the DRI infrastructure) to keep it in sync with what X is doing.

AIGLX (and to a lesser extent XGL) were very important steps to start moving the DRI and X worlds closer together. The remaining steps are underway now, but yes there is debate about all of them ;

- memory management needs to move from X into the kernel driver (drm) and become more versatile so that 3d and 2d can share memory buffers more effectively (TTM, GEM)

- either applications need to stop using direct rendering and switch to using AIGLX instead (slight performance hit) or DRI needs to be extended to allow the use of DRI to continue but have the application windows all move around together (DRI2, RDR)

There are other initiatives underway to make other aspects of the user experience better (Gallium gives us a newer, faster, and more versatile 3d driver, kernel modesetting makes seamless graphics and reliable suspend/resume/vt switch much easier) but the two above are the main ones for bringing 3d and X closer together.

[Vighy]

Why must you spam that link whenever something to do with the kernel comes up. It's pointless the few people who actually want to read your "theories" know where to go so you don't need to keep pointing it out.

oh! let him write what ever he wants! we live in democracy (somehow), so everyone can say what he thinks!

....and he is so funny!!! :-D

[Jade]

oh! let him write what ever he wants! we live in democracy (somehow), so everyone can say what he thinks!

....and he is so funny!!! :-D
So you think it is funny that various parts of Linux have (obviously) been sabotaged?

[Vighy]

So you think it is funny that various parts of Linux have (obviously) been sabotaged?

No that's horrible (if it's proved), it's funny the strength of your conviction :-)
I love to read all your posts... that's why it's funny! :-P

...and, as a ReiserFS estimator I would like to see Reiser4 fixed and in the mainstream, too.

[clint999]

Any comparison to Quartz right now would be dated. 10.6 has some pretty radical changes coming under the hood.

[avilella]

- either applications need to stop using direct rendering and switch to using AIGLX instead (slight performance hit) or DRI needs to be extended to allow the use of DRI to continue but have the application windows all move around together (DRI2, RDR)

This is a very interesting point that hasn't been covered in much detail in Phoronix. What is the state of AIGLX? I remember Redhat/Fedora went the AIGLX way when it started years ago, and there was a bit of a dichotomy for a while between AIGLX and XGL(?), but I haven't seen any more news in Phoronix recently. What do you mean by "have the application windows all move around together"?

[bridgman]

This is a very interesting point that hasn't been covered in much detail in Phoronix. What is the state of AIGLX? I remember Redhat/Fedora went the AIGLX way when it started years ago, and there was a bit of a dichotomy for a while between AIGLX and XGL(?), but I haven't seen any more news in Phoronix recently. What do you mean by "have the application windows all move around together"?

What I was *trying* to say was that Redirected Direct Rendering (which uses DRI2 and a memory manager) is the next step in letting 2D and 3D windows be composited together.

I have no idea what "all move around together" means, other than that I need to stop posting before the coffee kicks in.

[mtippett]

What I was *trying* to say was that Redirected Direct Rendering (which uses DRI2 and a memory manager) is the next step in letting 2D and 3D windows be composited together.

I have no idea what "all move around together" means, other than that I need to stop posting before the coffee kicks in.

Just to clean up a little bit.

The first thing to realize is that what is fundamental to a complete compiz (or any other compositing manager) is full COMPOSITE extension support for *all* parts of the driver. That is why the application is called compiz, and they are called compositing managers.

When COMPOSITE is enabled, applications are expected to render to an off-screen window surface. The compositing manager can then rendezvous with these offscreen surfaces and combine them in any way that they want.

The *all* parts of the driver includes 2D, 3D an video. 2D is easy, for example, XAA falls back to SW. Xv has some information in the callbacks for the buffer to render to, but then comes 3D. 3D currently renders to where it believes the window _should be_. This means it renders to the pixels on the screen, then compiz renders, then the 3D app renders. When you apply the transforms like the cube and wobbly windows, the app doesn't get new window information until after the transform is complete. The transform itself quite happily renders a blank window (assuming that the contents come from the app).

AIGLX is technically not required for compiz, but for DRI based drivers, it is the simplest path for getting the window contents into an OpenGL texture.

Now with DRI in it's current form, getting this buffer (or redirect buffer as some call it) is very difficult (but not impossible) to achieve.

DRI2 includes sufficient infrastructure to make this possible, an advance memory manager (GEM, TTM, etc) is also needed to allow buffer information to be shared throughout the driver.

(I believe that "Following the Window around" means that GL application is included in the wobbly windows or cube rotation. This is the user-experience - beyond the pixel fighting that occurs between GL and compiz - sometimes called flashing. The redirected direct rendering does push the rendere content into the window. Due to the confusion brought in by redirected direct rendering vs hw accelerated indirect rendering I tend to use the term OpenGL support for COMPOSITE when talking about this.

Regards,

Matthew

[bridgman]

Ahh yes, that's what I meant :D

[some-guy]

Just to clean up a little bit.

The first thing to realize is that what is fundamental to a complete compiz (or any other compositing manager) is full COMPOSITE extension support for *all* parts of the driver. That is why the application is called compiz, and they are called compositing managers.

When COMPOSITE is enabled, applications are expected to render to an off-screen window surface. The compositing manager can then rendezvous with these offscreen surfaces and combine them in any way that they want.

The *all* parts of the driver includes 2D, 3D an video. 2D is easy, for example, XAA falls back to SW. Xv has some information in the callbacks for the buffer to render to, but then comes 3D. 3D currently renders to where it believes the window _should be_. This means it renders to the pixels on the screen, then compiz renders, then the 3D app renders. When you apply the transforms like the cube and wobbly windows, the app doesn't get new window information until after the transform is complete. The transform itself quite happily renders a blank window (assuming that the contents come from the app).

AIGLX is technically not required for compiz, but for DRI based drivers, it is the simplest path for getting the window contents into an OpenGL texture.

Now with DRI in it's current form, getting this buffer (or redirect buffer as some call it) is very difficult (but not impossible) to achieve.

DRI2 includes sufficient infrastructure to make this possible, an advance memory manager (GEM, TTM, etc) is also needed to allow buffer information to be shared throughout the driver.

(I believe that "Following the Window around" means that GL application is included in the wobbly windows or cube rotation. This is the user-experience - beyond the pixel fighting that occurs between GL and compiz - sometimes called flashing. The redirected direct rendering does push the rendere content into the window. Due to the confusion brought in by redirected direct rendering vs hw accelerated indirect rendering I tend to use the term OpenGL support for COMPOSITE when talking about this.

Regards,

Matthew
You forgot that the GLX_EXT_texture_from_pixmap extension is also required

[avilella]

another feature that Phoronix could delve into is "resolution independence". Both OS X and Windows have been improving this feature in recent releases. What is the current state of resolution independence in X.org applications?

[NeoBrain]

DRI2 includes sufficient infrastructure to make this possible, an advance memory manager (GEM, TTM, etc) is also needed to allow buffer information to be shared throughout the driver.


Just wondering, will DRI2 achieve the same level of performance as DRI or will it be slightly/a bit/much slower when running windowed/fullscreen games?

[TechMage89]

DRI2 will be slightly slower, because it involves an extra step (drawing from the offscreen buffer to the screen).

However, unless there's something that needs to apply effects to the buffer, that shouldn't be necessary. Does anyone know if there's a mechanism for switching between direct-to-framebuffer and redirected rendering?

[some-guy]

Just wondering, will DRI2 achieve the same level of performance as DRI or will it be slightly/a bit/much slower when running windowed/fullscreen games?
It will be very slightly slower, but once the driver is using gallium, it should be faster since the game/app should be taking advantage of the newer openGL features (and better quality)

[Ex-Cyber]

another feature that Phoronix could delve into is "resolution independence". Both OS X and Windows have been improving this feature in recent releases.Did Microsoft come up with some way to work around all the broken Windows apps whose layouts get nutty with "Large Fonts" (120 dpi)? It turns out that a lot of apps are laid out for the Windows convention of 96 dpi, with fixed window/control sizes, and if the fonts are enlarged it can push things out of the visible area of the window/control. For me, that's the single most annoying "resolution independence" issue in Windows. Incidentally, do many Linux apps have a similar problem? I haven't noticed any, but I also haven't generally felt the need to change default font sizes outside of web browsers...

[Redeeman]

KDE does not have that problem.

[nhaehnle]

Just wondering, will DRI2 achieve the same level of performance as DRI or will it be slightly/a bit/much slower when running windowed/fullscreen games?
Obviously a DRI2 + Compositing setting will be a bit slower, since windows have to be rendered into an off-screen surface, and then the off-screen surface is rendered onto the screen, applying whatever effects you want.

DRI2 without compositing should be just as fast as DRI without compositing.

Fullscreen games should disable compositing while running to get the same performance under DRI2. I'm not sure how that works.

[elanthis]

Did Microsoft come up with some way to work around all the broken Windows apps whose layouts get nutty with "Large Fonts" (120 dpi)? It turns out that a lot of apps are laid out for the Windows convention of 96 dpi, with fixed window/control sizes, and if the fonts are enlarged it can push things out of the visible area of the window/control. For me, that's the single most annoying "resolution independence" issue in Windows. Incidentally, do many Linux apps have a similar problem? I haven't noticed any, but I also haven't generally felt the need to change default font sizes outside of web browsers...

It's usually up to the toolkit. The classic Windows GUI toolkits are all based on fixed position layouts. The GUI editors give you a grab that you drag and drop your widgets onto to line them up and such. That obviously breaks when the widgets change size due to font size changes.

GTK+ uses a box model (similar in spirit to the HTML DOM). You tell the toolkit what the relationship between widgets are instead of giving it specific pixel positions. When a widget changes size, the toolkit recalculates all necessary layout information.

Qt is pretty much the same, as is the Firefox GUI (being derived from the DOM box model, that's not much of a surprise). I don't know about OpenOffice. Most other toolkits use a similar model.

Individual applications may have bugs, especially those using custom widgets or making heavy use of canvas widgets. I know Firefox had/has some bugs regarding the size of windows, as some of them (especially the Preferences window) behaved like the window size was set to a specific pixel size, and if the elements in the window become bigger, they'd no longer fit in the window. Hopefully the latest version resizes the window automatically to fit the window contents.

Most GUIs these days are designed with a box model approach, mostly due to the overwhelming number of designers and developers starting out with HTML/CSS and then moving on to native toolkits.