[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree-fonts
Subject:    Re: [Fonts] Complex text layout and mapping screen coordinates
From:       Keith Packard <keithp () keithp ! com>
Date:       2002-02-26 5:29:18
[Download RAW message or body]


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
Fonts@XFree86.Org
http://XFree86.Org/mailman/listinfo/fonts
[prev in list] [next in list] [prev in thread] [next in thread]