Behdad Esfahbod's daily notes on GNOME, Pango, Fedora, Persian Computing, Bob Dylan, and Dan Bern!

My Photo
Name:
Location: Toronto, Ontario, Canada

Ask Google.

Contact info
Google
Hacker Emblem Become a Friend of GNOME I Power Blogger
follow me on Twitter
Archives
July 2003
August 2003
October 2003
November 2003
December 2003
March 2004
April 2004
May 2004
July 2004
August 2004
September 2004
November 2004
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
October 2008
November 2008
December 2008
January 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
November 2009
December 2009
March 2010
April 2010
May 2010
June 2010
July 2010
October 2010
November 2010
April 2011
May 2011
August 2011
September 2011
October 2011
November 2011
November 2012
June 2013
January 2014
May 2015
Current Posts
McEs, A Hacker Life
Tuesday, October 16, 2007
 Episode VI: Return of Federico

Federico:

Funny, how I read your post after Boston Summit, and I've had in fact discussed both issues with Owen Taylor while there. Lets see:

First, increasing cairo scaled font cache size: You saw a 230 KB process size increase when increasing cache size from 256 to 2048. Well, here's a little secret I decided not to disclose until someone notices it, and you kinda qualify now: Cairo doesn't free glyph renderings after uploading them to the X server! You definitely need them if you are using the image surface, but most processes don't. So, you've got the smart X server hashing and reusing glyph renderings, and cairo-using processes keeping a copy around, for no good. Fix that and happily increase cache size to 2048 without 230 KB size increase!

Next, time spent in HarfBuzz, and particularly recreating and enlarging buffers all the time. As my summit hacking project I took on optimizing HarfBuzz. In short, I did:
All in all, in my measurements, these three made repeated text layout 10 to 20 percent faster for 1) very long paragraphs, and 2) using fonts with many many looksup like Nafees Nastaliq (more than 100). They made no difference for regular small text+font combinations.

Mandatory screenshot of Nafees Nastaliq after I fixed a bug to tolerate a font bug in the GDEF table. I'm surprised how good actually it worked with the synthesized GDEF Pango put together for it, but now it works perfect (again):

Nafees Nastaliq in Pango

Labels: , , , ,

Comments:
Carl really wants a scaled font cache that is shared across all fonts, not a per-font one like Cairo has right now. I believe Wu Peng from our Beijing office will work on that in his spare time :)

... Though I don't know the code in Cairo very well. What is it that is keeping the rendered glyphs around? And how does the X server know how to share its own copy of the rendered glyphs? How does it know when to free them?
 
Oh, BTW... the 230 KB increase was for Chinese, which of course manages to fill up the 2048 entries the cache pretty quickly.

I ran a test for Spanish and the memory increase was much smaller (didn't really have a difference from the 256-entry cache); it makes sense that Spanish does not need as many glyphs to be kept around.

It would be *very* interesting to get pango+cairo+X checkpointed to the different Pango versions, and run pango-profile for each of them. For Pango 2.14 (I think) you should see the huge increase in CJK timings, and they will probably go down slowly after that version.

This doesn't sound hard to do for a quality afternoon with jhbuild. Hint, hint :)
 
Sure, a better cache is always appreciated, but making cairo not keep glyph bitmaps around unnecessarily makes a lot of sense anyway. Going to submit a patch today. It's quite trivial now that I checked the code.

As for the X server, it hashes the bitmaps and reuses a bitmap if it already has it, and it keeps a refcount I assume for lifecycle management.
 
Also, Wu Peng may want to check out Xft sources. It has a cache like the one we want in Cairo.
 
CRULP announces successful deployment of Pango Rendering Engine onto Symbian mobile development platform. This engine allows rendering of complex writing systems through Open Type fonts. [29/10/2009]

http://crulp.org/research/Project-Details/ALSMP.htm
 
Post a Comment



<< Archive
<< Home