Around 20 o'clock on Feb 25, Keyur Shroff wrote:
> In client side approach, since client has to find relative (x,y) position > for each glyph from GPOS table, a separate request need to be sent for each > character (or glyph?) code over the wire. It's not a separate request, the entire string can be set in a single request with appropriate offsets. In fact, for proper AA text display, the entire string must be sent as a single request to get overlapping glyphs rendered correctly. > For (b), again only one request need to be sent for each > run in the string. Client can maintain cache (as it is > doing in Gtk) so that we can send request for querying text > extents only when text string is modified. Here's the round trip I was concerned about -- you've now made text display a synchronous operation instead of asynchronous. X is like a processor with a deep pipeline; normal execution of requests is very fast, but stalls to get data from the X server back to the application are also very expensive; in the local case, you're looking at a delay waiting for the X request stream to empty and two context switches. The network case takes a complete round trip. To compute line breaks, applications must incrementally add characters to a string, computing the string metrics after each character; this will now require numerous round trips. > Also only part of the string will be queried (two or three request are > necessary at a time) to find new extents and update the cache. If the client isn't involved in text layout, there is no way it can tell what portion of the string needs to be retransmitted for the server to layout the glyphs. Languages like Devanagari require a significant amount of non-local context when editing text; how can the client known what text needs to be transmitted in this case? For Pango, the library and the application usually interact at the paragraph level with Pango holding the entire content of the document so that application editing can be properly reflected in the output. > For client side approach no request will be sent for finding text extents > but we have to send a separate request to draw glyph for all characters > starting from the modification point. Network traffic is almost irrelevant for X; it's all about round trips, not the size of glyph data on the wire. Glyph data will always be completely swamped by image data. If this weren't the case, we'd have a stored mode X protocol (like PHIGS) and we'd all spend our lives editing display lists. I'll take a hundred extra requests to save a single round trip. We have a lot of experience running text over the X protocol that shows it's not a performance problem; client-side text doesn't change the bulk of that data, it only eliminates round-trips at application startup while vastly improving the capabilities of the layout engine. I think the programmers experiences with PHIGS vs GL are quite relevant here. Structured graphics disappeared not because it wasn't "more efficient" or "faster" in the benchmarks, but because it required applications adopt the libraries model for the data, rather than having the application define the data structures and bolt the graphics library in at the right places. GL added a primitive stored mode just to meet the benchmark bigots, but I doubt any of you have ever seen it used in a production application. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
