Page 4 of 4 FirstFirst ... 234
Results 31 to 37 of 37

Thread: X.Org is the new kernel

  1. #31
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    364

    Default

    Quote Originally Posted by mtippett View Post
    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?

  2. #32
    Join Date
    Jul 2007
    Posts
    402

    Default

    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?

  3. #33
    Join Date
    Apr 2008
    Location
    /dev/random
    Posts
    218

    Default

    Quote Originally Posted by NeoBrain View Post
    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)

  4. #34
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by avilella View Post
    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...

  5. #35
    Join Date
    Oct 2007
    Posts
    370

    Default

    KDE does not have that problem.

  6. #36
    Join Date
    Aug 2008
    Posts
    77

    Default

    Quote Originally Posted by NeoBrain View Post
    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.

  7. #37
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by Ex-Cyber View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •