Re: XEmacs 21.5 much slower remotely?

BTW, thanks for following up on this. This could lead to major improvements in the basic implementation of Xft for us. (Integration with customize is still the big blocker IMO, though.) Adam Sjøgren writes: I can think of a number of possibilities. (1) I believe that the Xrender extension caches "glyph collections" in the server (effectively, it caches fonts). So it should be as efficient as the server-side legacy fonts as long as glyphs are sent to the server "as needed". Maybe your server doesn't implement Xrender? (Look for RENDER in the list of extensions returned by xdpyinfo.) Nothing XEmacs can do about this; you'll have to live without Xft. (2) Font instances are supposed to be cached in XEmacs, but it looks to me like the same fonts are repeatedly instantiated. This would probably defeat the caching. I think this is unlikely to be the culprit, as this happens only a few hundred times (I think once per face creation, basically). But it could be that the cache is quite limited in size, and every time a new face comes in the old one's cache data gets overwritten. (3) Something about Xft is triggering redisplay aborts. The abort counter I suggested might tell you about that. (4) Something else. :-) The host running the mailing lists was attacked. Since they were planning to replace the hardware anyway, they're doing that at the moment with a clean install of a new OS (even a different distro). Should be back up today or tomorrow. http://www.xemacs.org/About/XEmacsServices.html has status, and there's issue567 in the tracker (which just points to the above page). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta