Around 8 o'clock on Mar 6, Brett Granger wrote:
> 1) Tiny-X vs. "standard" X -- all the emails I have seen in the various > archives on the subject indicate that the primary goal of tiny-X was > small compile size for putting in Flash ROM parts, and not necessarily > smaller run-time memory size, and that in return I would give up a fair > amount of configurability. Is that really/still true? Does tiny-X not > give much/any run-time memory advantage? If my priority is run-time > size vs text/code size, is there any advantage to one over the other? Run-time size includes code space, so kdrive-based X servers retain a slight advantage. I think it also benefits from using the regular loader instead of the custom XFree86 loader; text pages can be deleted from physical memory and paged directly from the executable where the XFree86 custom loader tends to modify most of the text pages forcing them to be either retained in memory or written to a swap file. > 2) tiny-x and xfs -- can tiny-x use a font server, should one be on the > network somewhere? Based on a couple web pages, it appears that I can > #define FontServerAccess YES even for a tiny-x build. Does that define > mean that tiny-x can use xfs and that it should "just work" with a -fp > in the command line? If not, since I got the impression that there is > no config file for tiny-x where I can set the FontPath, how do I have > tiny-x find and use a font server? Just use xset? Yes, font servers work just fine, and the standard X server -fp option works as expected. Note that kdrive also uses the built-in fonts so you can fallback to those in the absence of a functional font server (-fp built-ins,foo/:7100). While kdrive doesn't provide any configuration file, it does have a lot of command line options that provide similar functionality. I end up putting the "normal" X server startup into a shell script that passes all of the appropriate options to the X server. > 3) xfs vs Render/Xft -- I've seen the white papers on both render and > Xft and have stumbled across various small HOWTOs and config hints on > the web, but still am not entirely clear on how they relate to or > replace xfs. Xft provides a new API for applications to draw text using client-side fonts. When all applications are using client-side fonts, the server need provide only the two "required" fonts (fixed and cursor). As more applications move to client-side fonts, the need for any server side fonts (including those fetched from a font server) will diminish. I don't use any server-side fonts on my screen. One significant advantage of Xft is that it can limit X server memory usage by discarding infrequently used glyphs. This makes client-side fonts the preferred mechanism for limited memory systems. > So if all of my X client apps are based on GTK+-2.0 or other toolkits that > utilize Xft/render, or I write my own apps that use Xft, might I possibly > be able to get away without both server-side font support and xfs entirely? Yes, except for 'cursor' and 'fixed'. Those are both provided inside the X server with the built-ins font path; no external files are required at all. > Tiny-X does have the render extension, if I understand correctly, right? Oddly, yes it does. The Render extension is not required by Xft; legacy X servers are supported using core protocol requests. This works well enough as long as there's not a network between the application and the legacy X server. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Newbie mailing list [EMAIL PROTECTED] *** To unsubscribe , or change message options, see: http://XFree86.Org/mailman/listinfo/newbie
