I am pasting in mail I sent to carl worth about the idea and my initial results.

…
I recently installed Ubuntu (Hardy Heron) on my rather ancient desktop at home. This machine is mostly used by my wife to read email and to view YouTube. The machine is rather memory limited 512 MB ram and an ATI Radeon 9550 with 64MB video RAM. As you can see not a great machine, but Linux was fine on it until I installed Hardy; now the machine feels as pigishly slow as a windows machine – ah well. To cut to the chase, I thought that things might improve if I enable hardware accelerated graphics and in particularly xgl+compiz. The good thing about the software is that it can be set up very little effort and the and the desktop effects seem to work quite well. But mow Firefox rendering is really slow and scrolling is glacial. That is not the worst of it, most video playback li more like a slugging slide-show. Before you ask I am using the proprietary fglx driver. Most of the time xgl shows over 30% CPU utilization, now I think this is because most websites have flash videos in advertisements, and xgl really has a lot of trouble that those. On the plus side the window manager is very smooth them moving windows around the screen even with the wobble effect and there is no visible repainting of the exposed area when moving windows. Although it is not significant that every Linux distribution I have used previously used would show a ‘trailing’ effect in particular going over the firefox browser.

The Premise

Any down to business, I was reading about the improvements you have been making to the hardware rendering portion of X and XAA rendering was still twice as fast as the EXA rendering that you are implementing. In a video presentation you mentioned that if the hardware was infinately fast that the max rate for glyph drawing would be about 700K/s and you are getting around 125K glyphs per sec. I am sure you have thought about this, if instead of displaying one glyph at a time we cached sequences of multiple glyphs at a time, would that not improve the performance of glyph display. Since regular text has a awful number repeated text fragments and if one considers how much zip compression can reduce a text file size, this seems to be an effective line of enquiry.

Some experiments

Purpose: See if is effective to cache common sequesnces of glyphs instead of individual glyphs. The idea is an extension of all the individual glyphs in a single image. For example:

How the sequences are generated:

the text “this is a test”
would generate the following doule and tripple sequences.
=> “th”, “thi”, “hi”, “his”, “is”, “is “, “s “, “s i”,
” i”, ” is”, “is”, “is “, “s “, “s a”, ” a”,
” a “, “a “, “a t”, ” t”, ” te”, “te”, “tes”, “es”, “est”, “st”

Clearly not all of these sequences are useful. So we need some heuristic to keep only the one that would be useful.

As stated earlier there is a rather efficient method of building these sequences using a ‘trie’ data structure. We start of by building 2 character sequences. Every time we see the same sequence again we increment the use count. When the use-count exceeds a pre-determined threshold say 10, we start to extend that pair to include a third characte. Further we cache an image of the two glyph sequence.

Again an example woul be useful. Suppose we have the sequence ‘th’ we see this occuring 10 time, we create an image for ‘th’ and we also extending the sequence for ‘th’

Now we might get:
Seequence Occurance
‘the’ 10
‘tho’ 3
‘thi’ 10

we would now create an image for ‘the’ but not for ‘tho’ and ‘thi’.

Assumptionns:
1> The glyph sequences to cache should be computed dynamically
2> The process should be efficient both in compution power and memory usage
3> The maximum sequence lengths should be determined in advance
4> The solution should be esay to implement.
5> English text was used for these experiments, use the text form of books in project Guttenburg

From my half remeberd data structure courses at school, I assumes that the trie data structure would probably be the most efficient way of determining the best glyph sequences. These are many methods of implementing the TRIE structure and I did find a a really good paper on efficient trie implemenation “An Efficient Implementation of Trie Structures (1992) , Jun-Ichi Aoe, Katsushi Morimoto, Takashi Sato; Software — Practice and Experience”, I did not use that code for these experiments. The purpose of the experiments was to determing if this would be a useful line to follow. I am please to report that the results are ensouraging:

I use a simple Trie implemenation i Java that is not particularly efficient and certainly I would not suggest that that this implememtation should be transcribed to C. I chose Java so as to do these experiments quickly. Secondly, I have not done graphics programming in over 10 years and I have no experience with OpenGL, so I did not attempt to do any graphics in these experiments.

Summary

As you can see I have presented the results for caching 2, 3, 4 glyph sequences. The results suggest we get very good inprovement with images generated for glyph pairs, and a 35% improvement if we use glyph triples (but we have to cache a far greater number of images) but the extra space may be worth the overhead. Above 3 we get much smaller improvement for a great deal of extra processing time and image caching, this in my opinion would not be worth the effort.

Results:
Run on Ubuntu 8.04
1 GHz Dell Pentium PIII 512 MB Ram
JRE java 6 – sun 1.6.0.06

Test

Up to 3 glyph sequences
Generate a image after noticing 20 repeats
Time to Complete: 278 mili sec
Seq Len: Number of writes
1: 52248
2: 1172340
Total writes: 1224588
Total chars: 2396928
Total chars in file: 2396928
Improvement: 1.957334221795412
Images generated: 1358 (number of cached images of glyph sequence)
Nodes in Trie: 2396

—–
Up to 3 glyph sequences
Generate a image after noticing 20 repeats
Time to Complete: 564 mili sec
Seq Len: Number of writes
1: 47314
2: 132583
3: 694816
Total writes: 874713
Total chars: 2396928
Total chars in file: 2396928
Improvement: 2.740245086102527
Images generated: 5005 (number of cached images of glyph sequence)
Nodes in Trie: 15486
—
Upto 4 glyph sequences
Generate a image after noticing 20 repeats
Time to Complete: 1124 ms
Seq Len: Number of writes
1: 44938
2: 126648
3: 207050
4: 369386
Total writes: 748022
Total chars: 2396928
Total chars in file: 2396928
Improvement: 3.2043549521270767
Images generated: 10099 (number of cached images of glyph sequence)
Nodes in Trie: 39572

So thank you very much for this improvement, it is much needed!

Giacomo: There are a lot of factors that can affect things, and it’s hard to sort them out without seeing a profile. I would certainly wonder if you are seeing software rendering. Offhand, I wouldn’t expect libpciaccess to be important here: with or without my patch the commands and data are going through the DRM. But I’m not an expert in that area.