Storing glyphs as Pixmaps

[Carl Worth]

Some of you know I've been working on a patch series to store glyphs
as Pixmaps. Here it is as an mbox that can be applied with git-am. One
could also fetch it from my repository with:

	git fetch git://people.freedesktop.org/~cworth/xserver glyph-pixmaps:glyph-pixmaps

I've written an excessively long-winded blog post about it here:

	http://cworth.org/exa/storing_glyphs_as_pixmaps/

And to save you some boredom, I'll quote parts of that here. First,
some potential problems with storing glyphs as pixmaps:

 1. Glyph images are sharable across the entire server, but Pixmaps
    are specific to each individual "screen" within the server.

 2. The X server uses the system-memory glyph data to compare when a
    glyph is uploaded by a client that is identical to a glyph
    uploaded previously by another client, (using a simple XOR-based
    hash to do fewer comparisons---but always falling back to a full
    compare after matching the hash).

 3. Recent work that Dave Airlie, Kristian Høgsberg, and Eric Anholt
    have been doing may result in there being a one-to-one
    relationship between Pixmaps and "buffer objects". And these
    buffer objects require page-alignment, so their minimal size will
    be 4k, (which could be quite excessive for small, 10x10 glyph).

And the solutions I'm proposing as I've implemented things so far:

 1. Per-screen Pixmaps: Suck it up for now. One, actually having
    multiple "screens" in the X server isn't common. Things like
    Xinerama that use one "screen" for multiple displays are much more
    common. So, I've written code that allocates one Pixmap per screen
    for every glyph. If this turns out to be a problem in practice, it
    would be quite trivial to create the Pixmaps lazily for all but
    one screen. And it would also be worthwhile, (but a much larger
    change), to lift the per-screen restriction for objects like
Pixmaps.

 2. System-memory data for avoiding hash collisions: The goal is to
    move the storage from system memory to a video-memory Pixmap. We
    lose, (by spending excess memory), if we still have to keep a
    system-memory image. To fix this, I've replaced the weak XOR-based
    hash with a cryptographically strong hash (SHA1) that will be
    (probabilistically) collision free. This does introduce a new
    dependency of the X server on the openssl library.

 3. 4k alignment constraints for buffer objects: This is likely a very
    real issue, but something I'd like to address later. Presumably we
    can alleviate the problem by pooling multiple glyphs within a
    single Pixmap, (or multiple Pixmaps within a single buffer
    object), or whatever necessary.

I've tested this patch series with an i965 card and things seem to be
working. I've mainly just been testing by running firefox, and usually
all the glyphs would be missing or scrambled or all the glyphs would
be correct. So I think it is mostly a case of everything working or
nothing working, and things do seem to be closer to everything working
now.

But I would still appreciate people reviewing the changes
carefully. This is really my first significant foray into the X server
code and I might have some things wrong. For example, I'm currently
creating both a Pixmap and a Picture, but then freeing just the
Picture. I'm guessing that's wrong, and I'll need to extract the
Pixmap from the Picture and destroy it first. (I hesitated only
because on the client side, I've run into X errors by freeing a Pixmap
before freeing a Picture that references it---which I think is a bug
actually, but that's a different topic.)

Also, there are lots of error-handling paths here, which I've tried to
deal with correctly, but obviously they haven't been tested at all. It
occurs to me that a good thing to do would be to use Chris Wilson's
valgrind-based, exhaustive malloc-failure injection tool along with
the X test suite and run that over the server before a release,
say. That's been extremely valuable in cairo development, and could be
quite interesting for X. Or did I hear that the server has been
through exhaustive malloc-failure injection testing in the past? If
so, how was that done? And has it been done recently at all?

The performance impacts (for i965) from this patch series are positive
for EXA, but not extremely impressive, (see blog post for more
details). But I'm hoping that this work will combine well with future
work for good improvements. And if nothing else, the performance
impacts don't seem to be negative at all, (tested with XAA and NoAccel
as well). But I've only tested i965 so maybe someone wants to take a
look with other cards.

Again, this is my first step into X server coding, so go easy, but I
am very interested in any feedback that anyone might have.

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: glyph-pixmaps.patchset
Type: application/octet-stream
Size: 39295 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070803/5a9f4f14/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070803/5a9f4f14/attachment.pgp>