| |||||||||||||
|
| |||||||||||||
what about....what about....Posted Feb 9, 2008 4:02 UTC (Sat) by mattdm (subscriber, #18)Parent article: LCA: Two talks on the state of X
Reducing network latency and unneeded overhead when using X over relatively slow network links? (A.k.a "what in the world do people keep using VNC for?")
(Log in to post comments)
what about.... Posted Feb 9, 2008 13:18 UTC (Sat) by liljencrantz (subscriber, #28458) [Link] Network transparency was dropped as a priority a long time ago. Just look at the new font rendering system. Basically, all text is rendered in the X client and sent ofer the socket to the server these days. This improves rendering performance of the brain dead widget implementations that insist on rendering text and then applying filters to that text client side before rendering on screen at the expense of network transparency.
what about.... Posted Feb 9, 2008 17:35 UTC (Sat) by nix (subscriber, #2304) [Link] Um, the entire purpose of the render extension is to make such things not-insanely-expensive. (It's certainly not noticeable bandwidth-wise to me, and almost all my X interaction is with remote clients.) X's real network problem is latency and roundtrips (especially when mapping windows), not bandwidth.
what about.... Posted Feb 10, 2008 12:21 UTC (Sun) by rossburton (subscriber, #7254) [Link] So you didn't see the ancient benchmarks which shows that Xft/Render is faster than core fonts then?
what about.... Posted Feb 10, 2008 13:49 UTC (Sun) by nix (subscriber, #2304) [Link] To be fair it is *dog* slow if your app only supports client-side fonts and your server is some old thing that doesn't support the render extension.
what about.... Posted Feb 11, 2008 8:31 UTC (Mon) by liljencrantz (subscriber, #28458) [Link] Like I said in my original post, rendering on the client side is faster in implementations that end up transfering the text back to the client anyway. Unfortunately, this includes GTK and QT.
what about.... Posted Feb 11, 2008 9:40 UTC (Mon) by jamesh (subscriber, #1159) [Link] Pretty much any application ends up needing font metrics on the client side to handle things like wrapped text, or sizing a widget to fit a string of text. The old font system had a number of problems related to this, namely:
Now if you are running into speed problems with client side font rendering to remote displays, there are a few things you should check. The most important one is to check if the display supports the RENDER extension. If it does not, then you should get a noticeable speed increase by disabling anti-aliasing. With anti-aliasing enabled but without RENDER, the X client downloads the background pixmap underneath where it will render the text, composites the text locally then sends the result back to the server. With anti-aliasing disabled, it can simply send the glyphs to the server to draw directly (which is comparable to what happens in the RENDER case, anti-aliased or not).
what about.... Posted Feb 11, 2008 20:45 UTC (Mon) by nix (subscriber, #2304) [Link] Why can't Xft (or Xrender) make this check for you at client connection time? There's really no excuse for requiring users to know this sort of black magic just because they want to connect to an old X server.
what about.... Posted Feb 12, 2008 2:31 UTC (Tue) by jamesh (subscriber, #1159) [Link] Well, running an application locally against an old RENDER-less X server gives reasonable performance, so it isn't clear that always disabling anti-aliasing is the best default on such servers -- it really depends on the bandwidth and latency. I guess the real answer to your question is that it isn't a high priority of the developers. They are putting their effort into improving performance when used against non-obsolete X servers (effort that helps in the remote X case as well). Given that there is only so much they can do, I don't blame them.
what about.... Posted Feb 12, 2008 8:19 UTC (Tue) by nix (subscriber, #2304) [Link] Oh yes, agreed: this is a whinge that's getting rapidly less important over time. Probably against the installed base of X servers it's entirely insignificant by now, not least because exceed and other incredibly obsolete X11R4/5 Windows-based X servers have been comprehensively outcompeted by Cygwin's X server :)
what about.... Posted Feb 11, 2008 23:11 UTC (Mon) by liljencrantz (subscriber, #28458) [Link] My bad, I was unclear in what I was saying. I did not mean to say that the old font system was superior, as it clearly lacked many features needed for fast high quality text rendering. What I do belive is that a font rendering system that rasterizes fonts on the server side but gives access to font metrics on the client side as well should be possible to create, thus giving you full performance and full access to graphical goodies. The best way to do this with as little latency as possilbe might be to allow the client to calculate font meterics but leave all actual rendering to the server.
what about.... Posted Feb 12, 2008 2:42 UTC (Tue) by jamesh (subscriber, #1159) [Link]
Sun tried this with STSF:
http://stsf.sourceforge.net/about.html
It was not exactly a success, but did offer some benefits over fontconfig/Xft if you were
running hundreds of X servers from a single machine. When running just a single X server,
these benefits were not apparent and the increased complexity for developers is a clear minus.
what about.... Posted Feb 14, 2008 9:21 UTC (Thu) by liljencrantz (subscriber, #28458) [Link] I completely missed the existence of stsf, thank you for the pointer. I read up a bit on why it failed, and the main reason (judging from mailing list posts, at least) seems to be that the various X hackers (e.g. Havoc Pennington and various GTK hackers) felt that fontconfig was good enough. And in all fairness, that is probably completely true if you don't care about network transparency. I've never heard any other serious criticism against fontconfig except for the client side rendering issue.
|
|
||||||||||||