"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Daniel" == Daniel Pittman
Daniel> The Xft library uses this structure for, among other
Daniel> things, keeping a cache of rendered characters in the
I'd been wondering about that; it takes forever even over ADSL, and I
bet the speed up will be noticable even on a local connection for a
moderately slow box.
I think so. It has certainly made rendering more snappy on my P4m-1.7,
which is a very over-powered machine for what it needs to do.
I guess I'm going to have to find the documentation for Xft and
that to the general-docs package, too, I just have no idea about the
stuff you're finding at this point.
There isn't any. The tutorial on Xft by Keith Packard is the closest to
documentation I could find. (google xft tutorial, if you don't already
know it. :)
For the other things, like the question of the expected XftDraw
life-span, I answer them by reading code. The Xft library, other Xft
applications, and so forth.
It isn't much fun, but it does work. Sadly, I cannot find *anything*
easier to do when working with this. I would join an Xft mailing list
and ask them, if I could find one. :)
Daniel> Retaining the object means that they stick around,
Daniel> than being recreated every time text needs to be drawn.
I would call this "lazy initialization" rather than "caching".
It seems to be a bit of both: Xft keeps a limited quantity of
Picture/Pixmap memory in the server to retain the rendered characters,
and seems to do other stuff in a lazy way. This object is related to
both, I think.
I've got your other patch in my development workspace now, but in
usage pattern it doesn't make any difference. I'll review and apply
this and push ASAP.
I found it by using WindowMaker to switch from one desktop to another,
showing and hiding XEmacs in the process. This forced a menubar redraw
which, in turn, leaked Pictures into the server.
I suspect that, normally, you wouldn't see this unless you actually used
the menu, and even that might only leak a little. Anyway, it really was
a nasty leak for me, so I am glad to have fixed it.
BTW, I'm seeing these:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 12 (X_ConfigureWindow)
Value in failed request: 0x0
Serial number of failed request: 11519370
Current serial number in output stream: 11519377
all the time when starting to compose mail or return to reading in
Gnus. Seems to have something to do with window configuration.
Uh-huh. I don't see them at all, but I seldom split windows and
certainly not into more than a couple of them. I do use Gnus under this
It does look to me like there may be another leak of Pixmaps somewhere
in the Xft branch, since they are slowly creeping up and up in my
Pictures are well under control, though, and the system stays nice and
responsive despite running more than 24 hours now.
Formerly, it would now be slow to the point I could see both complete
redraws done by redisplay. :)
I bet it's whatever Michael fixed a month ago, so probably a
release of the mainline and a synch of sjt-xft to that is in order.
At the moment I am still poking at the redisplay code to try and work
out what, if any, improvements can be made there.
The biggest irritation that the Xft code has for me is a set of
* characters, especially 'w', are clipped too aggressively, resulting in
the top right corner not drawing well. Oblique lower-case 'd' is
worse - it lost the entire stroke, so looks like a 'o' or 'a'...
* single pixel wide "droppings" are left all over the place when the
display scrolls. The easiest way to see it is:
- start zmacs selection
- move down with 'C-down' until the page switches
- watch some lines gain "underbars" in the colour of the zmacs region
I suspect that the later is related to the hacks used to address the
anti-aliasing bleeding outside the character cell you mention in
...the redisplay code is surely a mess, though. I am giving vague
consideration to attacking it the way I did a similar mess many jobs
ago. GUI toolkits all seem to end up this way inside. :)