Re: [SJT-XFT] Performance enhancement patch - cache the XftDraw structure.

Daniel> There isn't any. The tutorial on Xft by Keith Packard is Daniel> the closest to documentation I could find. (google xft Daniel> tutorial, if you don't already know it. :) Wonderful. Oh well. Daniel> It isn't much fun, but it does work. Sadly, I cannot find Daniel> *anything* easier to do when working with this. Keep notes, I'll write a manual. Daniel> Retaining the object means that they stick around, rather Daniel> than being recreated every time text needs to be drawn. Daniel> It seems to be a bit of both: Xft [...]. Sure. My point is just that XEmacs definitely wants to keep this object around, and there's no provision for throwing it away or recreating it if it gets corrupt, somehow. _Xft_ caches, _XEmacs_ has a (persistent) member in the frame structure. Daniel> It does look to me like there may be another leak of Daniel> Pixmaps somewhere in the Xft branch, since they are slowly Daniel> creeping up and up in my running instance. Well, there could be leaks anywhere for Pixmaps, since they're used in XEmacs in several places. Note that there's no such thing as a weak specifier (and can't be, in the nature of things), so I can imagine that image specifiers might accrete multiple copies of the same image, etc, if LISP code weren't carefully written. Daniel> Formerly, it would now be slow to the point I could see Daniel> both complete redraws done by redisplay. :) Try it over the network, and you'll realize that not only are there two complete redraws, but there are many false starts in each. I think this is due to weirdness in the implementation of subwindows. Daniel> * characters, especially 'w', are clipped too Daniel> aggressively, resulting in the top right corner not Daniel> drawing well. Oblique lower-case 'd' is worse - it lost Daniel> the entire stroke, so looks like a 'o' or 'a'... I'm not sure how to deal with that. I didn't look terribly hard, but I haven't noticed any way to get "oblique correction" information. Daniel> * single pixel wide "droppings" are left all over the Daniel> place when the display scrolls. The easiest way to see it Daniel> is: In ordinary use. ;-) Actually, for me it depends on the font. Some fonts are horrible, others are OK. Also, it only happens in whitespace for me at this point. I think there are some issues with cursor geometry, too. Daniel> I suspect that the later is related to the hacks used to Daniel> address the anti-aliasing bleeding outside the character Daniel> cell you mention in comments. No, I think it's the other way around. The hacks are mostly working; it's in the whitespace, where the hacks have no effect, that it doesn't. It's possible that Xft uses a different origin or something like that, too. Daniel> ...the redisplay code is surely a mess, though. I am Daniel> giving vague consideration to attacking it the way I did a Daniel> similar mess many jobs ago. That would be very nice. I've thought about it, but I'm not really competent nor do I have time to do a good job on it. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.