X.Org is the new kernel

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