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.

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

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

[Redeeman]

KDE does not have that problem.

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

[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)

[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?

[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?

[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?

[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