Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 59

Thread: Wayland's Weston Now Handles Full-Screen X Windows

  1. #41
    Join Date
    Mar 2012
    Posts
    83

    Default

    Quote Originally Posted by silenceoftheass View Post
    But currently with remote X applications for each glyph draw you are chatting to and and from the X server for that server side draw operation right?
    [cut]Waylands "remoting" isn't fixed in stone so it's a little early to tell, but I think the gnashing of teeth is a little pre-emptive, to be honest.
    Totally wrong, in one X request you can draw several things.
    As for Wayland remoting, adding an XRender's style operator on top of current Wayland's operation would be a major design change..

  2. #42
    Join Date
    Sep 2012
    Posts
    363

    Default

    Quote Originally Posted by renox View Post
    Totally wrong, in one X request you can draw several things.
    As for Wayland remoting, adding an XRender's style operator on top of current Wayland's operation would be a major design change..
    Wayland should support server side rendering by linking with freetype, cairo, pango, etc.
    Last edited by JS987; 02-15-2013 at 05:58 PM.

  3. #43
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,278

    Default

    Quote Originally Posted by elanthis View Post
    GLAMOUR takes a rendering model that is inherently antagonistic to how modern GPUs work and tries to mske it fast. Toolkits need to intelligently render their widget graphs in a GPU-efficient manner, not use bad 2D APIS with some expectation of a lower level making it all right. I think Qt is moving there; GTK has a lot of work to do. To be fair though Windows' myriad of toolkits are generally just as bad; even ones using D2D generally use it wrong and end up slower than CPU-based rendering in many cases. Even many games just use Scaleform, which is helluva inefficient compared to what a knowledgeable dev with enough time/budget can do.

    GPUs are all about minimizing state changes and batching draw calls. Rendering many individual "primitive" 2D elements and using non-atlased pixmaps/glyphs is just bad. The lower layers can do some auto-magic batching, but the toolkit can do way more, and can expose a more appropriate drawing API to apps/themes. Clutter hence is way more interesting than GLAMOUR.
    While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

    So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.

  4. #44
    Join Date
    Oct 2008
    Location
    Finland
    Posts
    59

    Default

    Quote Originally Posted by Ericg View Post
    He's referring to compositing in the terms of desktop effects. Which in reality what he's referring to is Indirect Rendering.

    Indirect Rendering:
    Code:
    Input -> X Server -> X Client -> X Server -> Compositor -> X Server -> Image is displayed
    Direct Rendering:
    Code:
    Input -> X Server -> X Client -> X Server -> image is displayed
    Wayland Rendering:
    Code:
    Input -> Wayland Server -> Wayland Client -> Wayland Server -> Image is displayed
    Since the Wayland Server IS the compositor (kwin, mutter, compiz) There's no performance drop unless they hit a slow code-path or bug in the compositor.

    With indirect rendering there's a slow down (What he's talking about), with Direct rendering there's no slowdown. And with Wayland rendering there may even be a speedup in rendering time, and therefore better FPS, because they dont have to work around all of X's bloat and cruft and legacy crap.
    No, you are not describing indirect rendering here. All cases you describe can equally well be direct or indirect rendering, since you (nor I) ever mention who does the actual rendering of the client's image: the client or the X server. We were just talking about client provided images, not how they are originally created.

    Compositing or desktop effects have nothing to do with indirect rendering.

    The compositing manager in X might be (have been? Wasn't this limitation lifted?) limited to use indirect rendering for its own rendering only, but that has nothing to do with normal X clients.

    But that one is true that Wayland has less overhead: no indirect rendering (because all clients render full frames themselves, not pushing rendering commands to a server), and no communication with a third process (compositing happens within the server).

    Quote Originally Posted by JS987 View Post
    Disabled compositing - direct rendering using overlay.
    Wayland doesn't support overlays, but it seems it will be fixed.
    http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE
    Your comment makes no sense. All rendering on Wayland is always direct rendering. There is no indirect rendering, because Wayland does not have a rendering protocol.

    Quote Originally Posted by JS987 View Post
    Wayland should support server side rendering by linking with freetype, cairo, pango, etc.
    This comment makes no sense on its own. You would have to invent also a rendering protocol, which is an unimaginably hard task to do well.

  5. #45
    Join Date
    Mar 2012
    Posts
    83

    Default

    Quote Originally Posted by curaga View Post
    While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

    So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.
    1) Not all applications do this kind of rendering.
    2) You can cache several different glyphs for one character..
    I think that the ideal solution would be to have a 'duplicated identical cache' between the client and the server: at first the client and the server agree on a cache size (empty at the beginning), then the client send glyphs which are stored both in the client and the server cache, client and server use *identical* algorithm to manage the cache, so when a client see that a glyph is in its cache it knows that the server also has it in its cache and then it can send only a draw this glyphs references.
    The hard part is handling resynchronisation in case the server needs to reduce the cache size..

  6. #46
    Join Date
    Sep 2012
    Posts
    363

    Default

    Quote Originally Posted by pq__ View Post
    Your comment makes no sense. All rendering on Wayland is always direct rendering. There is no indirect rendering, because Wayland does not have a rendering protocol.
    Wayland without overlays does compositing using GL, which causes rendering to be indirect.
    The addition of atomic page flip to the kernel should allow the configuration of overlays within a frame boundary. This allows KMS Wayland compositors, such as Weston, to use overlays seamlessly. In this talk we'll cover how Weston assigns different surfaces to overlays and other planes, to reduce the portion of the screen that is composited using GL.
    http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE

  7. #47
    Join Date
    Feb 2013
    Posts
    51

    Default

    Quote Originally Posted by JS987 View Post
    Wayland without overlays does compositing using GL, which causes rendering to be indirect.

    http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE
    two pass rendering != indirect rendering

    GL indirect rendering means that the application is unable to talk to graphic hardware - thus GL calls have to be submitted to the server which in turn submit them to the gpu (as it's the only one with hw access privilieges) - hence AIGLX

    compositing means that an application IS able to operate on the gpu (within the device context it has been assigned), hence direct rendering - but since only the compositor/wm/server knows about windows from ALL active applications, they render offscreen textures that the compositor then renders on screen
    hence a 2 pass rendering, or redirected (direct) rendering

    which may have some overhead over rendering directly to screen in a single pass, but if you think about it the latter would apply only to full screen applications and overlays

  8. #48
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,278

    Default

    Quote Originally Posted by renox View Post
    1) Not all applications do this kind of rendering.
    2) You can cache several different glyphs for one character..
    I think that the ideal solution would be to have a 'duplicated identical cache' between the client and the server: at first the client and the server agree on a cache size (empty at the beginning), then the client send glyphs which are stored both in the client and the server cache, client and server use *identical* algorithm to manage the cache, so when a client see that a glyph is in its cache it knows that the server also has it in its cache and then it can send only a draw this glyphs references.
    The hard part is handling resynchronisation in case the server needs to reduce the cache size..
    It's not enough to cache several iterations of some letter. They can also overlap (and the overlap can change just as the shape) and can change dynamically, meaning you would have to cache the overlap data, and with the possibility of per-letter changes, the amount of permutations becomes rather unwieldy.

  9. #49
    Join Date
    Sep 2012
    Posts
    363

    Default

    Quote Originally Posted by curaga View Post
    While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

    So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.
    For Arial one texture per font size is enough.
    http://imageshack.us/photo/my-images...rendering.png/
    click image to view in original size

  10. #50
    Join Date
    Sep 2012
    Posts
    363

    Default

    Quote Originally Posted by silix View Post
    two pass rendering != indirect rendering
    2 pass rendering is indirect rendering.

Posting Permissions

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