Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:12 UTC (Tue) by etienne (guest, #25256)
In reply to: Wayland - Beyond X (The H) by renox
Parent article: Wayland - Beyond X (The H)

> one could imagine the display server would have a cache for the applications fonts managed by the client

I sometime wonder how much data is exchanged in between client and server, where both the server and the client have identical data locally stored.
For instance, why send fonts over the network, when both client and server have a local copy of the same font file (maybe because both are standard installation of the same Linux distribution).

to post comments

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:30 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

For instance, why send fonts over the network, when both client and server have a local copy of the same font file (maybe because both are standard installation of the same Linux distribution).

You have reinvented the X font server and core fonts. It turns out to be a pointless optimization: you gain the ability to remove one transfer of those glyphs of the font which are used (and only those glyphs) across the network. In exchange, you lose accurate client-side metrics, client-side compositing when needed (GlyphSets don't have to be composited on the server side, they just normally are); in current implementations the server has to pull the whole font in glyph by glyph so it's horribly slow with large Unicode fonts; you gain failure modes from the fonts claiming to be identical but not actually being pixel-identical, and validating that requires horrible hash-transfer handshakes...

Optimizing to speed up a transfer of a few hundred or a few thousand characters that occurs once in the life of a client is a waste of time. You're optimizing initialization! More important is that we not lose the ability to distinguish repeated units (like glyphs) and composite them on the server side... and judging from other comments here Wayland throws that baby out with the bathwater, leaving us with a protocol that must necessarily be far less bandwidth-efficient than X when displaying difficult images like a black-background xterm containing lots of text all in the same font. Because that trivial and common case is too hard to optimize! (boggle.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:48 UTC (Tue) by jonabbey (guest, #2736) [Link] (3 responses)

On the other hand, text on a solid background should be massively compressible, no? I suppose it would depend on the intelligence of the batching and delta protocol?

What bit-blitting for text rendering loses on a character-by-character basis it should presumably be able to gain in scrolling?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:05 UTC (Tue) by renox (guest, #23785) [Link] (2 responses)

The thing is: you want to do very fast compression..

On a system point of view, it's very stupid to loose all this information provided by the application: converting text to an image and then trying to compress the images generated..

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:35 UTC (Tue) by gioele (subscriber, #61675) [Link] (1 responses)

> On a system point of view, it's very stupid to loose all this information provided by the application: converting text to an image and then trying to compress the images generated..

On the other hand if you do not send rasterized text as image, you need to send text + fonts + other bits of information. In the past this approach has been found as limited and replaced by the current client-side font handling.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:51 UTC (Wed) by renox (guest, #23785) [Link]

You misunderstood me: I didn't advocate the old X way to do this, the XRender way to do fonts is quite good (client side glyph generation and a cache in the server): flexible and efficient for network transparency.

What I was saying that with Wayland the compositor will just see an image of the Window, so from a networking point of view this is not very efficient..

"Compressing" a window would be much more efficient if the background and the text were handled separatedly.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:37 UTC (Tue) by renox (guest, #23785) [Link]

Good remark, an interesting "corner case" optimisation but note that to be 100% sure that what the client and the server have is the same, you cannot trust filenames or version numbers: you'd need to checksum the content of the "supposedly shared" data..
Note that even when the client and the server have the same font files, there is a latency issue: the server doesn't know which font will be used, which means the first time a client refers to a font the server would need to access to a disk and disks are slow!