FC1 Linux xft/gtk2 29-Jan-2004 Opt: AthXP+SSE

Discussion about official Mozilla Thunderbird builds
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

Persist wrote:Enjoy, apparently it's very good. Thanks for posting the bug link, the toolbars on my builds are also icon free zones.


Great ending (well, I've known the ending for a long time) but a great movie for the most part :)

The bug has been fixed and checked in by Scott M.
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

happy holidays for whomever that has meaning, and here's another build.
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

26-Dec build
toblo
Posts: 48
Joined: March 7th, 2003, 2:26 am

Post by toblo »

Hi Yek, do you have any idea what'd happen if I run your AthXP+SSE build on Celeron?
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

I'm not sure. I think the march=athlonxp might screw you up and cause segfaults depending upon whether its really being used. There's about 19 or 20 instructions that're unique to the xp so running into a bad opcode could be a lot of trouble.

I've been thinking about knocking off the optimizations , except for generic, but since I started to use the latest gcc (well, latest fc2 beta 3.3.2-3), I'm starting to see much more of a difference in performance.

If you try it, let me know -- g/l
photon
Posts: 19
Joined: December 31st, 2003, 1:07 pm

Re: Unofficial: FC1 Linux xft/gtk2 29Dec03 Opt: AthXP+SSE

Post by photon »

Yek wrote:http://pryan.org/thunderbird/yek/TB-29Dec03-AthXP-SSE-GTK2-XFT.tar.bz2


Code: Select all


ac_add_options --enable-xft
ac_add_options --disable-freetype2
ac_add_options --enable-default-toolkit=gtk2



May I ask you if there's any particular reason to disable freetype2? You may have thought of it as redudnant. It's true of the screen rendering, but for printing, it is not. Disabling freetype2 disables not only the use of freetype2 in the screen rendering (that is redudant and inferior to Xft2 rendering) but also disables freetype2 printing (which is the best among three printing options in terms of the faithfulness of print-outs to the screen rendering by Xft [1]).

Would you consider enabling it next time you make a build? Thanks.

[1] To get a 'close-to WYSWYG' print-out, you have to let freetype2 code access the same set of truetype fonts as are available to Xft2 code. The way to do that is to specify all the directories <em>and subdirectories with truetype fonts</em> in your fontconfig font search path as <code>font.directory.truetype.$i</code>. For instance, I have the following in my prefs.js (<code>$HOME/.thunderbird/$SALTED_NAME/prefs.js</code>)

Code: Select all

user_pref("font.directory.truetype.1", "/usr/local/share/fonts/ttf");
user_pref("font.directory.truetype.2", "/usr/local/share/fonts/ttf/math");
user_pref("font.directory.truetype.3", "/usr/share/fonts/default");
user_pref("font.directory.truetype.4", "/usr/share/fonts/ko/TrueType");
user_pref("font.directory.truetype.5", "/usr/share/fonts/ja/TrueType");
user_pref("font.directory.truetype.6", "/usr/share/fonts/zh-TW/TrueType");
user_pref("font.directory.truetype.7", "/usr/share/fonts/zh-CN/TrueType");
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

photon,

I'd be happy to enable freetype2 on the next build (the cvs tree has a bad xul and dtd file at the moment). I've been through this before and if it makes a difference printing, then good. The thing that's confusing is that configure, with freetype2 enabled, does and xft-config --cflags, xft-config -libs, and freetype-config --cflags and freetype-config -libs, which both return the same things that're plugged into the c++ paths for building.

This makes it totally dependent upon having #DFREETYPE2 statements in each gcc, and I've yet to see one during a build. That's why I stopped bothering with it. I can see that there's code (especially under ~mozilla/gfx ) that would use the #ifdef FREETYPE2, if only it were specified, but I think it isn't.

In any case, I'm switching to freetype2 enabled because you say it improves your printouts. I'd just thought, as you said, it might be duplicitous.

Yek
photon
Posts: 19
Joined: December 31st, 2003, 1:07 pm

Post by photon »

Thanks for your prompt reply.

Yek wrote: The thing that's confusing is that configure, with freetype2 enabled, does and xft-config --cflags, xft-config -libs, and freetype-config --cflags and freetype-config -libs, which both return the same things that're plugged into the c++ paths for building.

This makes it totally dependent upon having #DFREETYPE2 statements in each gcc, and I've yet to see one during a build. That's why I stopped


I think the magic is hidden in gfx-config.h.in. With 'enable-freetype2', gfx-config.h.in is converted to gfx-config.h with MOZ_ENABLE_FREETYPE2 defined.

In any case, I'm switching to freetype2 enabled because you say it improves your printouts. I'd just thought, as you said, it might be duplicitous.


Thanks, again.

It's unfortunate that there's no way to disable only the screen rendering part of freetype2 while keeping the print out part. That way, you can avoid some redundancy in the screen rendering code with a better printout quality. Perhaps, I have to file a bug on that and work on it. Linux/Unix printing has a lot to be desired.

BTW, I realized that this board is for thunderbird build so that a 'faithful' replication of the screen rendering in the print-out is not so important as in firebird. Stiil, I guess non-Western-European users would like the print-out with freetype2.

Another BTW, you may refer to the following document for more information on printing on Linux/Unix (in Mozilla products):

http://www.mozilla.org/releases/mozilla ... l#printing
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

No problem. I figured out which bug checkin had caused the 31-Dec regression of tbird, so backed it out and have a build with freetype2 enabled. Uploaded it just now. Thanks for the link. I'll check it out.

The bug isn't for tbird, but for the trunk browser, so though its easy to figure out, its not clear why it spills over into tbird.

-- bug is http://bugzilla.mozilla.org/show_bug.cgi?id=223908
swalker
Posts: 267
Joined: June 12th, 2003, 6:18 am

Post by swalker »

Yek wrote:The bug isn't for tbird, but for the trunk browser, so though its easy to figure out, its not clear why it spills over into tbird.

-- bug is http://bugzilla.mozilla.org/show_bug.cgi?id=223908


The problem is the file in question and two others are being packaged into toolkit.jar instead of comm.jar.

Code: Select all

Index: jar.mn
===================================================================
RCS file: /cvsroot/mozilla/mail/base/jar.mn,v
retrieving revision 1.46
diff -u -r1.46 jar.mn
--- jar.mn      14 Dec 2003 23:49:52 -0000      1.46
+++ jar.mn      1 Jan 2004 18:49:39 -0000
@@ -104,13 +104,13 @@
     content/help/contents.rdf                       (content/help.rdf)
     content/help/contextHelp.js                     (content/contextHelp.js)
 *+  content/communicator/contentAreaClick.js        (content/contentAreaClick.js)
+*+  content/communicator/nsContextMenu.js           (content/nsContextMenu.js)
++   content/communicator/tasksOverlay.xul           (content/tasksOverlay.xul)
++   content/communicator/utilityOverlay.xul         (content/utilityOverlay.xul)

 toolkit.jar:
 *+  content/global/customizeToolbar.xul             (content/customizeToolbar.xul)
 *+  content/global/customizeToolbar.js              (content/customizeToolbar.js)
-*+  content/communicator/nsContextMenu.js           (content/nsContextMenu.js)
-+   content/communicator/tasksOverlay.xul           (content/tasksOverlay.xul)
-+   content/communicator/utilityOverlay.xul         (content/utilityOverlay.xul)

 en-US.jar:
 +   locale/en-US/messenger/start.html               (locale/start.html)
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

I submitted a patch a couple hours ago, then got outta here for awhile, but its strange that most of the changes on this bug were 'generic' enough to be in trunk/xpfe and the potential desired solution is proposed to make utilityOverlay.xul in the ~./mail tree look like the one in ~./xpfe. I think it'd be smarter to have it all in xpfe to prevent diverging 'fixes' on essentially the same file.
User avatar
Anthracks
Posts: 168
Joined: July 13th, 2003, 2:06 pm
Location: Boston, MA

Post by Anthracks »

Thunderbird shouldn't be picking up code from XPFE at all, should it? My understanding was that XPFE was the "old" GUI toolkit used by SeaMonkey, whereas Firebird and Thunderbird were built using the toolkit/ chrome/ browser/ and mail/ directories. Obviously they share a great deal of back-end code, but I don't *think* that changes in XPFE should affect Tbird. Or maybe I'm just nuts :).
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

I don't know for certain, but from my wanderings through bugs, I've seen many places where tbird picks up xpfe code. Not only that, but to make this thing even more tangled, tbird uses quite a bit of 'mailnews' (which is supposedely mozilla-regular). I wouldn't mind seeing it use ~./mail but either way, I'd like to see it choose a single way instead of having more than a single copy of a file that's supposed to be the same.
Yek
Posts: 463
Joined: December 10th, 2002, 8:23 pm

Post by Yek »

14-Jan build, see first in thread. (spellcheck crash appears ok now)
ntd
Posts: 44
Joined: January 15th, 2004, 1:30 pm

Post by ntd »

I just installed gentoo a couple days ago, can't wait to give this a shot, previously I had only used it on win32
Post Reply