| |||||||||||||
LFCS 2012: X and WaylandLFCS 2012: X and WaylandPosted Apr 19, 2012 21:25 UTC (Thu) by wmf (guest, #33791)In reply to: LFCS 2012: X and Wayland by renox Parent article: LFCS 2012: X and Wayland
That's why network transparency should be implemented once by Wayland itself in a toolkit-independent way.
(Log in to post comments)
LFCS 2012: X and Wayland Posted Apr 19, 2012 22:00 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Wayland is the wrong place for network transparency. When people speak of "network transparency" what they really mean is "efficient remote rendering", and Wayland does not define a rendering protocol. It is strictly a protocol for accessing the screen and input devices.
What we need is not a remote version of the Wayland protocol, which is inherently _local_ due to the use of shared memory, but general-purpose protocols for remote rendering and input, targeting Wayland for access to the hardware. For now, the X protocol can serve that purpose, as can single-window adaptations of VNC. Future protocols can take similar advantage of Wayland for the low-level hardware interfaces, and concentrate instead on remote rendering.
LFCS 2012: X and Wayland Posted Apr 22, 2012 16:48 UTC (Sun) by VITTUIX-MAN (guest, #82895) [Link]
Wayland is exactly the right place to implement network transparency, in XPRA way in a network aware compositor.
This does all the things we love in networked X, that is mainly rootlessness is the default and it would allow plugging into a running session, so connection problems would no longer close all open programs.
LFCS 2012: X and Wayland Posted Apr 22, 2012 17:16 UTC (Sun) by renox (subscriber, #23785) [Link]
> Wayland is exactly the right place to implement network transparency, in XPRA way in a network aware compositor.
For LAN yes, but as I said here (http://lwn.net/Articles/493461/), WAN will probably suck unless there are many changes.
In my understanding currently:
- Wayland has very limited server rendering, so to be able to have XRender-way to display text, you'd have to change it significantly, until then Wayland will use much more bandwith to display text than X (if the toolkit use the XRender extension of course).
LFCS 2012: X and Wayland Posted Apr 20, 2012 7:30 UTC (Fri) by renox (subscriber, #23785) [Link]
> That's why network transparency should be implemented once by Wayland itself in a toolkit-independent way.
Except that it isn't possible to have network transparency which works well in a WAN with Wayland, without changing radically how Wayland works.
Two examples:
LFCS 2012: X and Wayland Posted Apr 20, 2012 9:56 UTC (Fri) by cortana (subscriber, #24596) [Link]
Do modern (as in, recently written) X clients actually use this font caching mechanism? I thought they all used FreeType (through various wrapping layers) to render on the client side these days.
LFCS 2012: X and Wayland Posted Apr 20, 2012 11:45 UTC (Fri) by renox (subscriber, #23785) [Link]
You misunderstood what I wrote: they render the font on the client, send the image of the letters *once* on the server, and can now display text very efficiently from a bandwith POV (all this if the XServer has the XRender extension).
LFCS 2012: X and Wayland Posted Apr 20, 2012 12:04 UTC (Fri) by chris.wilson (subscriber, #42619) [Link]
With the Render protocol, glyph images are no longer generated by the server but rather by the client who uploads a set of glyph images for a font. Typically, the client does use FreeType to render the individual glyph images. The server de-duplicates those images across all the clients and maintains the glyph image for later use by the client. When the client then renders some text it converts the string of characters into a set of (font, glyph index, position) tuples and sends that as a rendering request along with the operator to use and source pattern to apply. That request is passed to the driver, which typically prescans the request and uploads unseen glyphs into a texture atlas cache (using random replacement of old glyph entries to maintain fairness across all clients) and then converts it into a command stream for the GPU. By using a texture atlas, the number of state changes required for the command stream is minimised, though still one or two extra are incurred in order to adhere to the Render semantics.
In contrast, the core protocol differs in that the server renders the glyph images itself, and so has a fixed concepts of fonts and glyphs and needs to inform the client of the font/glyph metrics, and in the various semantics of the operators and patterns. That the core fonts were only bitmaps and so were easier for hardware to implement and are still faster than compositing glyphs using Render, is an implementation detail.
LFCS 2012: X and Wayland Posted Apr 20, 2012 18:26 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> Except that it isn't possible to have network transparency which works well in a WAN with Wayland, without changing radically how Wayland works.
I really doubt that's true, maybe you are unfamiliar with remote rendering protocols other than X?
> Wayland developpers prefer CSD decoration: think about what this imply in term of latency when you want to move a window in a WAN vs server side management of windows.
I don't think client side decorations have anything to do with window management and I can't envision the problem you seem to be describing. I can't see how window move performance would be affected based on which process is drawing the border, in either case you have a rectangle that needs to be moved around. In fact I would expect the client side decorations to be faster because the current X architecture where window management and borders are in the same process requires extra round trips and coordination between the application, X and the window manger to make sure the borders are adjacent and not overlapping the window contents as it is being moved. This architecture also causes a lot of tearing, as the window contents and window border are drawn at different times by different apps.
> Also an X client can send an image of each letter only once on the server, cache it there, and then reuse it
As the people who are designing wayland (primarily a display protocol for local apps) are also the ones who designed the font caching you describe I think they can figure out how to make an efficient remote protocol if they apply themselves to it 8-)
|
|||||||||||||