text and compositing

[Keith Packard]

Around 16 o'clock on Apr 23, Jon Smirl wrote:

> If this is going to work right with server side window transforms doesn't the
> hinting have to be done server side?

If you want the hints to apply in the actual pixel space instead of the 
'virtual' pixel space, then yes, the full transformation would have to be 
applied before any hinting.  Note that hinting can only deal with scaling 
transforms, so any kind of shear, rotation or projection would have to be 
applied post-hinting in any case.

> It is hard to transmit the glyph outline and the hint program to the server? 

Not hard, but specifying the hint program format would seriously constrain
what kinds of fonts we could support.  We've already been through about 5
different font formats over the life of the X server; codifying a specific
format at this point seems like a compatibility-limiting move.

Also, I worry about how well the server-side tesselation would match that 
generated by the client-side implementation, especially if the client side 
had a different understanding about the final transformation matrix.

> For example I'm thinking about the case of using a magnify tool to blow up
> pieces of an app's window. Vector things like text and drawings should
> scale smoothly in the tool's view.

In this case, you really want the glyphs to retain their original shape to 
preserve the illusion of magnification.  This is a perfect example of why 
the outlines should be hinted on the client side in some nominal pixel 
space and then rasterized after being transformed by the final matrix; 
when displayed at that nominal size, they look sharp, but when 
transformed, they look "the same", if a bit fuzzier.

Actually, now that I consider things a bit more, I'm really wondering 
whether we shouldn't just hand the window->screen transformation matrix to 
the client and let it deal with things.  You can see how server-side 
processing raises all sorts of interesting (and complex) issues.

We can look into moving functionality into the server to optimize the
system as we find the need, but frankly, if we assume a direct rendering
model for most applications, then we really have to do this entirely in the
client anyway -- there's no hook to stick the transformation into the
system at another level.

So far, network bandwidth has not been a problem for the geometry 
information needed to render 2D graphics; it's just not a significant 
fraction of the bandwidth used; almost everything sent over the wire (by 
byte count) is images.

Just bailing back to the client side reduces the problem from a full
server-side stored(/retained)-mode graphics system to a convention for
passing the projective transformation matrix from the compositing manager
to the application.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xserver/attachments/20040423/5b19fc02/attachment.pgp