gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] gnustep/core/back Headers/xlib/XGGState.h Sourc...


From: Adrian Robert
Subject: Re: [Gnustep-cvs] gnustep/core/back Headers/xlib/XGGState.h Sourc...
Date: Thu, 19 May 2005 10:31:44 -0400


On May 19, 2005, at 7:37 AM, Fred Kiefer wrote:

Adrian Robert wrote:
CVSROOT:        /cvsroot/gnustep
Module name:    gnustep
Branch:         
Changes by:     Adrian Robert <address@hidden>    05/05/12 13:41:58
Modified files:
core/back/Headers/xlib: XGGState.h core/back/Source/xlib: XGGState.m GSXftFontInfo.m Log message: cache Xft draw state in XGGState and use this to speed glyph rendering in GSXftFontInfo

There seems to be a small problem with these XFT support changes. The auto-configuration has a couple of XFT related setting, the ones of interest here are HAVE_XFT and HAVE_LIBXFT. Now the new code uses the later to flag areas which should only be included if XFT is present. But this seems to be a flag left over from a very old version, the configuration currently sets the first one if XFT is found. At least this is the case for me. At the moment I am not able to compile the xlib backend cleanly because of this. My suggestion is to replace all usage of HAVE_LIBXFT in XGGState.m and XGGState.h with HAVE_XFT.

Oops, I had looked at this, but not closely enough I guess. What I saw were a number of HAVE_LIBXXX #defines, including HAVE_LIBXFT, and then also the HAVE_XFT. Because the former was consistent with several others, I thought HAVE_XFT was the odd man out and was added by mistake at some stage. I had been planning to excise it later if no problems arose..

Now looking again I see that HAVE_LIBXFT occurs in 'configure' but not 'configure.ac'..

We should get rid of one and stick with the other. Are there any reasons to prefer XFT or LIBXFT? Currently the LIBXXX pattern is used for Xmu and Xext, while the XXX pattern is used for GLX.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]