Recent Features
| |||||||||||||
LFCS 2012: X and WaylandLFCS 2012: X and WaylandPosted Apr 20, 2012 7:30 UTC (Fri) by renox (subscriber, #23785)In reply to: LFCS 2012: X and Wayland by wmf Parent article: LFCS 2012: X and Wayland
> 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:
(Log in to post comments)
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-)
|
|||||||||||||