5:29 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Daniel" == Daniel Pittman
<daniel(a)rimspace.net> writes:
Daniel> The Xft library uses this structure for, among other
Daniel> things, keeping a cache of rendered characters in the
Daniel> server.
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
add
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,
rather
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
my
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
branch, BTW.
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
running instance.
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
21.5.22
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
rendering issues:
* 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
comments.
...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. :)
Daniel
9:39 a.m.
New subject: [SJT-XFT] Performance enhancement patch - cache the XftDraw structure.
>>>> "Daniel" == Daniel Pittman
<daniel(a)rimspace.net> writes:
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.
> I would call this "lazy initialization" rather than
"caching".
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.
7046
days inactive
7046
days old
1 comments
2 participants
participants (2)
-
Daniel Pittman -
Stephen J. Turnbull