Pango-enabled firefox is much slower

[David Finch]

Related to http://ubuntuforums.org/showthread.php?t=134627

The Firefox 1.5.0.1 that comes with Dapper is unbearably slow and jerky. I noticed this because 1.5.0.1 runs very fast and smooth on another system of mine with nearly identical hardware running CentOS and Firefox binaries downloaded from Mozilla's ftp site.

I've verified that it definitely is a lot slower and related to Dapper Firefox package, and not just the hardware or the distro in general, by downloading and installing the official Firefox 1.5.0.1 binaries from mozilla.org on Dapper. The problem went away entirely. Scrolling is smooth. Menus are responsive. All that good stuff.

Steps to reproduce problem:
Visit slashdot.org using the Firefox 1.5.0.1 that comes with Dapper
Scroll by dragging the scroll bar. Notice the jerkiness and low frame rate.

Workaround:
Download and install official Firefox 1.5.0.1 from mozilla.org
Install dependency libstdc++.so.5 (package libstdc++5, also depends on gcc-3.3-base)
Visit slashdot.org
Scroll. Enjoy the high frame rate and total non-jerkiness.

Same profile. Same settings. Same (lack of) plugins and extensions. All that's changed is the binaries.

Maybe it has to do with how they were each built:
Official ./configure options
--enable-application=browser --enable-update-channel=release --enable-update-packaging --disable-debug '--enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+' --disable-tests --enable-official-branding --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --enable-svg --enable-canvas --enable-static --disable-shared
Built with gcc version 3.3.2 20031022

Dapper ./configure options
--prefix=/usr '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --enable-default-toolkit=gtk2 --with-default-mozilla-five-home=/usr/lib/firefox --enable-pango --with-user-appdir=.mozilla --with-system-png=/usr --with-system-jpeg=/usr --disable-mailnews --disable-composer --disable-ldap --enable-postscript --disable-installer --disable-xprint --enable-crypto --enable-strip-libs --enable-canvas --enable-svg --enable-svg-renderer=cairo --enable-system-cairo --enable-mathml --disable-tests --disable-gtktest --disable-debug --enable-xft '--enable-optimize=-pipe\ -w\ -O2' --with-system-zlib=/usr --without-system-nspr --enable-xinerama --enable-extensions=default --disable-pedantic --disable-long-long-warning --enable-single-profile --disable-profilesharing --enable-gnomevfs --enable-application=browser --disable-installer --disable-updater
Built with gcc version 4.0.3 20060115

The following ./configure differences have caught my eye:
* '--enable-optimize=-pipe\ -w\ -O2' - The upstream doesn't have the \'s in there, because the spaces don't need to be escaped when surrounded by ' '. Probably a non-issue.
* -O2 - The upstream uses -Os, which is good for small caches like mine.
* --enable-system-cairo - This might have a big impact on performance, one way or another.

This system is a 1.8ghz Celeron with 512mb of ram.

[David Finch (ubuntu-mytsoftware)]

I wrote some simple benchmarks. One tests raw javascript performance, and the other three test scrolling performance with different types of content.

So far the main difference between the Ubuntu Dapper build and the official mozilla.org build of Firefox 1.5 in terms of performance has to do with text rendering. The Ubuntu build takes almost 3 times as long to complete the text scrolling benchmark as the mozilla.org build on my computer, 31.4 seconds versus 11.9 seconds. In the other benchmarks they came out almost equal. They're both using the same profile, same font, same version, etc. All that differs AFAIK is how they were built.

[Constantine Evans (cevans)]

Seems like pango to me. Try running the benchmarks with and without MOZ_DISABLE_PANGO=1. These ran at 5s vs. 10s for me, but pango in firefox has also caused font problems for me (giant font size everywhere, despite exact same config), so I had to decrease the text size in order to test.

[FooBar (ubuntu-mailinator-deactivatedaccount)]

Ubuntu Firefox is terribly slow. The browser, however, is one of the more important applications on a system and Ubuntu Firefox should therefore be fixed ASAP to match the performance of the original Firefox available from Mozilla.com.

[Dennis Kaarsemaker (dennis)]

Priority is for the developers to set. This bug is certainly not major since it's not a security, causes no data loss or does other really bad things.

[towsonu2003 (towsonu2003)]

we lost too many people with this similar issue in Breezy: changing priority to major.

[Dennis Kaarsemaker (dennis)]

Sigh...

[Luka Renko (lure)]

Did you try FasterFox plug it - I have it installed and I would not say it is slower than Mozilla version (I use on Breezy). Not sure which setting may cause the delays you are seeing.

[FooBar (ubuntu-mailinator-deactivatedaccount)]

It is definitely not a problem related to the connection/download speed, it is Ubuntu Firefox itself which is terribly slow, even with plugins such as Flash BTW...

[Vicks (v-levander)]

Disabling pango seems to work for at lot of people (including me). See #28 and onwards here: http://ubuntuforums.org/showthread.php?t=134627&page=3

[David (djst) Tenser (djst)]

I'm seeing this bug too and it's especially apparent when you try to zoom text. Delays of a few seconds are common.

[Victor (tirant)]

Ubuntu Dapper Flight 5 on Thinkpad T23.

Moving between tabs is also terribly slow, you have to wait at least a second for the text/page to refresh.

This bug is very important and should be polished with maxium priority. Firefox is the first app users are going to run in Ubuntu. It should feel fast and look good.

[Dimos Dimoulis (dimosd)]

export MOZ_DISABLE_PANGO=1

solved this for me. And I agree that the performance of Firefox should be a priority.

[Mike Perry (mike.perry)]

I have also observed a significate difference with pango disabled.

[M. (m-0x4d)]

The bug hasn't been fixed so far. How can I apply the aforementioned "fix" with export MOZ_DISABLE_PANGO=1?

[Dimos Dimoulis (dimosd)]

Pango improves rendering for some non-European languages, and thus it's inlikely that developers will disable this "feature" (suggestion - make it locale sensivive? One shouldn't pay for what he doesn't use)

I have posted this fix in Ubuntu wiki:

Add this line to /etc/environment

MOZ_DISABLE_PANGO=1

and then logout and login again.

[sledgehammer89 (sledgehammer89)]

Firefox is even very slow with MOZ_DISABLE_PANGO=1

If I choose another theme than "ubuntulooks" (eg. clearlooks or qtcurve), it will be a bit faster.

But Firefox on Dapper is far away (slower!) from Firefox on Breezy or on my 3rd (fastest) system "Slackware 10.2"

[kacheng (kacheng)]

I tried the Mozilla binaries, disabling IPv6, and disenabling Pango, but still encountered this problem.

I found a solution to this slowness problem that is in fact related to DNS.

It seems my resolv.conf file had a bad listing which led to a timeout conditions, considerably slowing down web browsing.

My resolv.conf originally looked like:
 search etob.phub.net.cable.rogers.com
 nameserver 192.168.1.1 <-- problem entry
 nameserver 24.153.22.67
 nameserver 24.153.23.66

I had changed my router address so it wouldn't conflict with my VPN and so 192.168.1.1 is no longer valid.

Changing my resolv.conf file to fixes the problem:
 search etob.phub.net.cable.rogers.com
 nameserver 192.168.17.1
 nameserver 24.153.22.67
 nameserver 24.153.23.66

Works great for me. Can anyone else confirm this solution?

[kacheng (kacheng)]

It would seem actually, that the Dapper version of Firefox also contributes to slowness.

The Mozilla binary for 1.5.0.1 is definitely faster.

[kacheng (kacheng)]

It would seem, actually, that the Dapper version of Firefox also contributes to slowness.

The Mozilla binary for 1.5.0.1 is definitely faster.

[Joe "Rotund" Tennies (joe-tennies)]

I find this interesting as Firefox seems SLOWER on my computer when I disable pango. Is it possibly something to do with the fact I have glitz and glitz-glx installed with an NVIDIA card w/ 3D accel?

[Alexandre Otto Strube (surak)]

This bug is a duplicate from https://launchpad.net/distros/ubuntu/+source/firefox/+bug/31141 - as it is newer than that one. It should be closed and reported on that one.

[Alexandre Otto Strube (surak)]

as this one is more complete, #31141 was marked as duplicate of this one.

[mannheim (kronheim)]

I share the problem experienced by the original reporter of the bug (and this problem must be unrelated to the DNS and networking issues others have experienced and reported here). The issue I experience is definitely with drawing the page.

1. Visit a thread in ubuntuforums.org.
2. Hit the page-down key.
3. Hit the page-up key.

On my system, Firefox (dapper) takes about half a second to respond to the page-up.

I tried the same thing in Epiphany, and in mozilla's official build of Firefox. In both other browsers, page-up is instantaneous.

My system has a 2.4Ghz pentium chip, a reasonable graphics card and plenty of ram.

[Constantine Evans (cevans)]

kacheng, your DNS problem is not related to this bug - you should file another one. As for the slowness compared to the official version, that is most likely due to Pango.

For Rotund, it is possible that Xgl makes a difference here. If I recall correctly, Xgl accelerates cairo - this might make pango faster. However, this does not fix the problem, as Xgl is far too unstable to be standard in Dapper, and I don't think it will be standard in Dapper+1 either.

For mannheim, please read the comments about Pango. That is most likely your problem.

[mikeandmore (mikeandmore)]

Every time i open a page firefox would use 100% for more than 5-6 sec.
but mozillaorg's binary won't.

as long as i know, the mozilla.org has it's own "cairo" to render the vector shape only.
so do not --enable-system-cairo

BTW : i'm not using XGL.i only use Xorg.
PS: what will happen if we --enable-composer --enable-mailnews ?

[GonzO (gonzo)]

Disabling pango = awesome speed boost. Blind men can see it. It's pretty amazing. Perhaps this should be set as a default?

[Kristoffer Lundén (kristoffer-lunden)]

Woah! Disabling Pango makes it go like greased lightning, while before it was so slow and painful I actually thought I had hardware problems for a while. Whatever the underlying solution is, this needs permanent fixing.

[David Finch (ubuntu-mytsoftware)]

I reran my benchmark on this system to test pango enabled vs disabled:
Dapper build, with pango enabled: 32.3 seconds
Dapper build, with pango disabled: 25.0 seconds, noticeably faster
Official linux build from Mozilla: 12.7 seconds, a 2x improvement over disabling pango

There may be more to the problem than pango, it seems.

[towsonu2003 (towsonu2003)]

is it possible this is due to how extensively everything depends on firefox in Dapper? What if a devel tried to tweak so epiphany replaces firefox in that role, although firefox is still the default browser? would this work by any chance? (brain storming)

also, is it possible this is due to the use of system files (/usr) instead of mozilla provided files (that are in the tar.gz)? Could using mozilla-provided files increase the speed instead of system files/tools? (still brain storming)

and finally, is it possible this is related to Dapper using cairo? but than, I guess mozilla's firefox would be slow as well? or wouldn't it? (more brain storming)

[ian marcinkowski (ianmarcinkowski)]

My problem with firefox seemed to be an excessive strain on the X server. I'd frequently get 60%+ CPU usage from the X server and the remaining %age would be devoted to firefox. While this may not be exactly related to this bug, the symptoms were the same.

I have just fixed my Firefox slowness problems by properly configuring my xorg.conf file. This is an nvidia-specific fix, as far as I can tell.

The default /etc/X11/xorg.conf listed my display driver as 'nv' instead of 'nvidia' (which is found in the "device" section. I also added a couple lines to this "device" section:

        Option "RenderAccel" "true"
        Option "AllowGLXWithComposite" "true"

And the following at the very end of my xorg.conf:

Section "Extensions"
        Option "Composite" "Enable"
EndSection

I'm not exactly sure why this has fixed my problem. Maybe I'm crazy.

[ian marcinkowski (ianmarcinkowski)]

i should have been a little more thorough with my last comment. I have found that the extra lines I added to my xorg.conf file have no effect on Firefox's performance; changing the device driver to 'nvidia' is what has caused the improvement.

[Constantine Evans (cevans)]

Ian, this bug is about the Dapper build of Firefox being slower than the official mozilla build. Please don't add unrelated issues here - file another bug if necessary.

[Constantine Evans (cevans)]

David - I can reproduce your results on official vs pango-disabled dapper. I get times of around 2-5 seconds for official, and 7-10 seconds for dapper with pango disabled. Just for fun, Epiphany gets around 10-12. If I have time tomorrow, I might try rebuilding the dapper package with various options to see if I can pinpoint the problem.

[mikeandmore (mikeandmore)]

--disable-system-cairo --disable-pango

try it out!

[mikeandmore (mikeandmore)]

Say I found a lot of site where when you enabled cairo and pango you will crash.

for example
http://www.easywine.org/bbs/forumdisplay.php?fid=6
will crash when using the dapper binary(which enable pango and cairo)

one of my friends told me that mozilla.org themselves are using cairo to render,
if you enable the cairo again it will render one more time.

so that's why 12.7/25.0=1/2 and don't enable pango cuz the layout has also been done by mozilla.org

[Gary Coady (garycoady)]

I tried just taking one page, and scrolling up/down it quite a few times (www.huffingtonpost.com as it happens):
For mozilla.org builds:
X usage was 74%
Kernel was 25%
firefox CPU usage was < 1%

For ubuntu builds:
X usage was ~45%
Kernel was ~12.5%
firefox CPU usage was 46%

Within firefox, 41% of that came from libgfx_gtk.so.
Dividing that up, ~8% from gdk_draw_layout_line
~2% from gdk_rgb_xpixel_from_rgb
~1% from gdk_draw_rectangle
~25% from libpango

Within that 25% from libpango:
11% comes from FcFontSort (fontconfig) - this percentage would be a lot higher if I hadn't temporarily disabled most of the fonts installed on the system. With all the default fonts installed, plus around 100 extra in my ~/.fonts directory, FcFontSort used closer to 45% of total CPU.

(data taken using sysprof)

[Gary Coady (garycoady)]

Note that for the previous comment, all percentages are percentages of the full 100% CPU used by all processes.

Some low-hanging fruit *might* be for pango to cache the results of FcFontSort. But there's been some discussion about this upstream without any progress yet AFAICS, so it might be more involved than that.

[Ian Jackson (ijackson)]

mikeandmore writes ("[Bug 32561] Re: Firefox in Dapper much slower than official upstream builds"):
> Say I found a lot of site where when you enabled cairo and pango you
> will crash.

That's probably due to buggy plugins (eg, Flash).

What I say in response to most Firefox crash reports is this:

 Thank you for your report that Ubuntu's firefox crashes for you under
 some circumstances.

 The vast majority of firefox crashes are caused by buggy plugins -
 notably, the Macromedia Flash player. These crashes cannot be solved
 by the Ubuntu team because Flash is not Free Software: Macromedia do
 not allow us to read and understand the source code for their Flash
 player, nor to redistribute modified versions if we should somehow be
 able to fix bugs anyway.

 If you prefer to have a stable web browser, we recommend that you do
 not install Flash, or other plugins that are not Free.

 If your firefox has no plugins, extensions, themes or other non-Ubuntu
 software installed and still crashes repeatably with a fresh profile
 in the most recent version from Ubuntu's development release, then we
 are very interested and would greatly appreciate it if you would
 reopen this bug report. _Do_ say that you have a vanilla Firefox,
 quoting the version number, and that you have tried moving your
 profile aside, and describe in detail how to reproduce the problem.

 Alternatively, you might like to consider using Ubuntu's online
 support request system instead of filing a bug report. The Ubuntu
 community can help to try to solve your problem and clarify any bugs
 which may exist in the Ubuntu software.

> for example
> http://www.easywine.org/bbs/forumdisplay.php?fid=6
> will crash when using the dapper binary(which enable pango and cairo)

It works just fine for me.

Regards,
Ian.

[GonzO (gonzo)]

Hm. I think this bug has been hijacked with speak of Xdrivers and crashes... that's not what this is about.

This is not about firefox crashing (at all) or the changes that happen when one uses nVidia's binary driver instead of Xorg's nv driver. This is about Ubuntu's firefox performing _slowly_ compared to official mozilla builds.

I for one, would like to know if its possible to just disable pango as a default, given the ginormous performance increase that takes place from this.

[L. David Baron (dbaron)]

In a few days of using Cairo builds, I've noticed that, despite bug 333251's dependencies being fixed, the builds are still unusably slow on many Web sites.

It probably doesn't help that I have a lot of fonts installed (see below) -- basically all the truetype font packages that come with FC5, plus a few others.

One example of this is the following steps to reproduce:
 1. load http://www.mozilla.com/ in one tab
 2. load http://www.mozilla.com/firefox/all.html in another tab
 3. switch between the tabs using Ctrl-PgUp/PgDn

It takes a few seconds to switch from tab to tab.

A realtime jprof profile (which includes some idle time) shows that:
 * 76% of the time is spent painting
   + presumably mostly the HTML documents
 * 13% of the time is spent reflowing
   + entirely the XUL document for the browser

 * 82.5% of the time is spent within gfxPangoTextRun::EnsurePangoLayout
   + this happens both during painting and reflow
   + 64.5% of the total time (78% of EnsurePangoLayout) is in FcFontSort
 * 11% of the time is spent within XftLockFace
   + all of that is within painting

So I'd make the observation that there are at least two dependencies to making this perform acceptably:

 1. fixing whatever rearchitecture needs to happen so that we don't need to redo all of this work for every paint

 2. porting bryner's work in bug 223813, which avoids unneeded calls to FcFontSort (plus followup regression fixes, of course), to whatever's doing our interaction with fontconfig (currently pango)

I'm switching back to non-cairo builds because of this, and I seriously question whether cairo should be turned on for our GTK2 builds as long as these performance problems are present.

[L. David Baron (dbaron)]

Oh, a few more details:
 + I should have been clearer that XftLockFace is also within EnsurePangoLayout (but not within FcFontSort -- I originally had listed only FcFontSort there)
 + 98.5% of the time within reflow is in EnsurePangoLayout
   + 89.5% of the time within reflow is in FcFontSort
 + 91.4% of the time within painting is in EnsurePangoLayout
   + 69.2% of the time within painting is in FcFontSort
   + 14.3% of the time within painting is in XftLockFace

[Dennis Jacobfeuerborn (dennisml)]

I cannot reproduce the behaviour described above but then I only have the regular fonts that come with a normal FC5 installation. Can adding some fonts really have an impact of a few seconds in this case?

[Vladimir Vukicevic (vvuk)]

So I put a patch in bug 330064 that was fixing something similar; it hasn't gone anywhere yet, but I'm thinking about just checking it in. You might want to try with that patch, and see how much of a difference it makes.

The freedesktop.org bug that I've filed, https://bugs.freedesktop.org/show_bug.cgi?id=6227 , has been ignored since I filed it (which is pretty typical).

[Constantine Evans (cevans)]

GonzO, I've been telling people to stop adding unrelated things in comments to this bug, but most people don't seem to care.

I would appreciate it if a developer would respond to this issue, and at least tell us if nothing is going to be done. I doubt that it is possible to disable pango in Firefox by default, since it helps with language support, but it consistently makes firefox much slower, as can be seen in the comments here, and breaks MathML (see bug 19066). But since Xgl isn't default in dapper, would it be possible to disable cairo, if this would help? In addition, it would be nice to have an option to disable pango that was automatic or discoverable, since most people would just think that Firefox is really slow rather than go searching for possible problems like this. Could MOZ_DISABLE_PANGO be set/unset depending upon what language support packages are installed/locales are generated? While language support is an important part of Ubuntu, does that mean we should cause major problems like these for its sake?

[towsonu2003 (towsonu2003)]

> While language support is an important part of Ubuntu, does that mean we
> should cause major problems like these for its sake?"

I need to say "yes" to this. Language is more important than the browser. But this will take us offtopic.

I too would like to hear from the devels what the possibilities are...

[mikeandmore (mikeandmore)]

well at least. disabling pango and cairo has no bad effect on CJK language,for i'am a native speaker.I think it's ok for chinese language if you disable pango and cairo

see the attachments.

for the crash problem.It's my fault,yeah it's the driver's problem and has nothing to do with firefox.

[mikeandmore (mikeandmore)]

firefox with chinese without pango

[Marco Cimmino (cimmo)]

> I need to say "yes" to this. Language is more important than the browser. But this will take us offtopic.

this is true if pango helps all languages, but this is another case.
The truth is: a lot of languages has poor performance with no benefits... this is not so nice.

[Mark (nix4me)]

Is this ever going to get fixed?

Its been forever since Firefox has been broken.

Even Debian Sid and Etch have a better Firefox, if there is such a thing.

This is a VERY important bug. The default Web Browser for Ubuntu is horribly broken! Seems like its being ignored?

[Matt Zimmerman (mdz)]

On Sat, Apr 22, 2006 at 02:16:11AM -0000, Mark wrote:
> This is a VERY important bug. The default Web Browser for Ubuntu is
> horribly broken! Seems like its being ignored?

Another more likely explanation is that it is working well for others
(myself included).

--
 - mdz

[Kristoffer Lundén (kristoffer-lunden)]

> Another more likely explanation is that it is
> working well for others
> (myself included).

Got a really, really fast computer or something?

"Horribly broken" is too strong a word, as it does work, but there is a really big difference in performance. Since I use several *very* different computers and see it on all of them, I must ask what you mean by "working well": Do you really notice no difference, is your computer enough to handle it, or are you just satisfied with the current speed?

[ChristofferS (ubuntu-curo)]

I can't believe this.

How can one disregard benchmarks?

It seems that this is not taken seriously. If we report bugs and they are not taken seriously we will not report bugs anymore. It is as simple as that.
I don't want that to happen because otherwise I have to go back to Debian.

[Matt Zimmerman (mdz)]

I'll try to provide some authoritative answers here on behalf of the development team:

In general, functionality (such as being able to render complex languages) is a higher priority than performance.
The Firefox builds provided by Mozilla address this problem by having separate downloads for different languages, but this approach doesn't work very well for distributions like Ubuntu which attempt to support a variety of languages.

We are fortunate in this case to be able to make a choice at runtime as to whether the heavier pango engine is needed.
However, the web is a multilingual environment, and it is not necessarily appropriate to assume that it is OK to render some languages incorrectly based on the default language of the system. I'm not entirely opposed to the idea of selectively enabling pango, but it requires some careful consideration.

Meanwhile, here's how you can help us to address this issue:

Help us to find out which languages require pango for correct rendering (I believe this includes at least all right-to-left languages, but is certainly not limited to those). The various localization teams within Ubuntu may be able to provide some assistance.

Stop claiming that Firefox is horribly broken, and changing the severity of this bug; it is purely a performance issue. Severity "Normal" appropriately reflects that this bug is significant, as most performance bugs would be classified as Minor. I've also added it to the list of bugs which will be considered for attention during the beta period. This is no guarantee that we will be able to solve it, but we will see what can be done.

[Matt Zimmerman (mdz)]

Another way to help (as I've just demonstrated): research upstream and in other distributions to see how others are addressing this issue. #334064 in bugzilla.mozilla.org seems to be referring to the same issue, and some potential solutions are discussed there.

I'd be interested to know what other distributions are doing about this conflict.

[Matt Zimmerman (mdz)]

On Sat, Apr 22, 2006 at 12:14:01PM -0000, Christoffer Sørensen wrote:
> I can't believe this.
>
> How can one disregard benchmarks?
>
> It seems that this is not taken seriously. If we report bugs and they are
> not taken seriously we will not report bugs anymore. It is as simple as
> that. I don't want that to happen because otherwise I have to go back to
> Debian.

This kind of talk doesn't bring us any closer to a solution. Besides, you
might be interested to know that Debian's firefox has precisely the same
issue. The reason pango is enabled by default in Ubuntu is because it is
this way in Debian.

--
 - mdz

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

https://bugzilla.mozilla.org/show_bug.cgi?id=334064 is unrelated to this issue, since it only refers to the new cairo-gtk2 rendering on mozilla trunk.

As for a list of locales that do need pango, Epiphany 2.14.1 uses this one: http://cvs.gnome.org/viewcvs/*checkout*/epiphany/data/epiphany-pango.schemas?rev=1.1.2.1
which in turn was taken from the mozilla.sh.in file in suse's firefox src.rpm.

[Constantine Evans (cevans)]

chpe, while the commenters and reporter are referring to cairo-gtk2 builds, the problem they are having is with pango - note the function calls. Note also that cairo is enabled in the Ubuntu builds. I never found this bug in my search because of the strange title, but this appears to be the same issue. Gary Coady noted earlier that the FcFontSort due to a large number of fonts is at least a somewhat significant factor in this case. If this is in fact caused due to a poor default, as is suggested, it should be very easy to fix. Has anyone tried the patch from 330064 which is linked from 334064? It essentially just changes XftMaxFreeTypeFiles when pango is being initialised, which amount to four lines of code or so. I will try this if I have time.

I don't actually think that this is a major bug. It would be nice if it were faster, but it still runs at a decent speed. I am more concerned with pango completely breaking MathML (bug 19066), but I am probably one of a very small group of users who care about this rather obscure feature.

[Mark (nix4me)]

"This kind of talk doesn't bring us any closer to a solution. Besides, you
might be interested to know that Debian's firefox has precisely the same
issue. The reason pango is enabled by default in Ubuntu is because it is
this way in Debian."

Are you sure its in Debian? I use Debian Etch and this problem does not show up there.

Also, i understand comments that this is not Critical however i offer this. Firefox in Ubuntu is definatley slow due to pango, thats a fact. My comment earlier about horribly broken is based on the fact that a web browser is probably the most used application on the Desktop. With that being said, this 'performance issue' affects everyone! And I take issue with those of you who say its not that noticable. Just open epiphany or galeon or run Firefox on Debian or Windows and it IS very noticable.

Seems to me the solution is to dump pango support in Firefox until the problem is resolved, or offer 2 firefox versions, with and without pango. Im just throwing out ideas here but the current Firefox is going to cause alot of commentary if included in Dapper Final.

Mark

[Matt Zimmerman (mdz)]

Thanks, chpe, for that list; it's very helpful.

Ian, please use similar logic in the firefox wrapper to selectively enable Pango, and solicit feedback from the community as to whether we're missing any languages from that list.

[Constantine Evans (cevans)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems that the epiphany solution is to enable or disable pango
depending upon the locale. It might be a better idea to look at the
installed language support or generated locales instead. I would imagine
that there are quite a few users who use one language for the system but
want to view websites in another, and using the locale doesn't take this
into account.

Matt Zimmerman wrote:
> Thanks, chpe, for that list; it's very helpful.
>
> Ian, please use similar logic in the firefox wrapper to selectively enable Pango, and solicit feedback from the community as to whether we're missing any languages from that list.
>
> ** Changed in: firefox (Ubuntu)
> Assignee: (unassigned) => Ian Jackson
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFETry8aejd/sU2TVARAhmbAJ91qydOBpOeoQ44NFQGN8/pWlunFQCeIP8N
7ntx8c6bqRGqTqSvuRj8D94=
=yt5s
-----END PGP SIGNATURE-----

[Matt Zimmerman (mdz)]

On Wed, Apr 26, 2006 at 12:20:12AM -0000, Constantine Evans wrote:
> It seems that the epiphany solution is to enable or disable pango
> depending upon the locale. It might be a better idea to look at the
> installed language support or generated locales instead. I would imagine
> that there are quite a few users who use one language for the system but
> want to view websites in another, and using the locale doesn't take this
> into account.

Looking at the generated locales seems like a reasonable compromise.

--
 - mdz

[towsonu2003 (towsonu2003)]

> It seems that the epiphany solution is to enable or disable pango
> depending upon the locale. It might be a better idea to look at the
> installed language support or generated locales instead. I would imagine
> that there are quite a few users who use one language for the system but
> want to view websites in another, and using the locale doesn't take this
> into account.

why don't you try it (generated locales etc), and than place a call on ubuntuforums.org and its locales (ubuntu-tr.com etc) for people to heavily test firefox in foreign sites, and post their findings briefly to this report, or to the forums as poll or something.

I'm pretty sure this would be appreciated by the community, rather than getting stuck with a slow firefox (like the one in Breezy). Thanks :)

[Vytas (vytas)]

The benchmark was interesting, but unfortunately it does not reflect the reality. I get around 9 secs for Pango enabled Firefox, and ~10-11 secs for epiphany, but when visiting my favourite portal, the visual difference is immense -- epiphany feels much much faster when scrolling text. So does pango disabled ff. IMHO this should be marked of a major priority, cause firefox usage has grown to 20-30% in Europe, and I think people migrating to linux expect it to be as smooth as on windows.

[P (p92)]

I'm really happy not to feel alone with a very slow firefox in dapper. I used the original firefox 1.5 from mozilla.org with breezy and was absolutly fascinated by the speed gain of 1.5. Now in dapper version I'm back to 1.4 low speed with another tightly coupled problem : from time to time when switching desktops (in kde) and masking the one where firefox lives, my cpu goes to 100%. Looking at top display I can see X taking near all the CPU. When I switch back to the desktop containing firefox, I can see firefox won't refresh its window content DURING 5 TO 10 MINUTES OR MORE ! Now I really think THIS is a major issue for dapper, because firefox in UNUSABLE during all this time and the system power largely consumed.

I tried with a fresh kde user and an entirely new firefox profile (so no plugins nor extenion nor themes installed) and it is the same issue, though more difficult to trigger.

I think it is related to this bug report because stracing firefox during its loop show lots of font related system calls.

As soon as I can give an strace extract I'll post it here.

My method to trigger it is having several desktop configured, open several TABS in firefox, then switch desktops going back and forth to the one where firefox is. Just try it.

Dapper availability with such an issue would really be avoided.

[P (p92)]

my installed fonts :

# dpkg -l '*font*' | grep 'ii'
ii fontconfig 2.3.2-1.1ubuntu11 generic font configuration library
ii gsfonts 8.14+v8.11+urw-0.2 Fonts for the Ghostscript interpreter(s)
ii latex-xft-fonts 0.1-5 Xft-compatible versions of some LaTeX fonts
ii libfontconfig1 2.3.2-1.1ubuntu11 generic font configuration library (shared l
ii libfontconfig1-dev 2.3.2-1.1ubuntu11 generic font configuration library (developm
ii libfontenc1 1.0.1-0ubuntu2 X11 font encoding library
ii libxfont1 1.0.0-0ubuntu3 X11 font rasterisation library
ii msttcorefonts 1.2ubuntu2 Installer for Microsoft TrueType core fonts
ii ttf-bengali-fonts 0.4.7 Free TrueType fonts for the Bengali language
ii ttf-devanagari-fonts 0.4.7 Free TrueType fonts for languages using the
ii ttf-freefont 20060126b-2ubuntu1 Freefont Serif, Sans and Mono Truetype fonts
ii ttf-gujarati-fonts 0.4.7 Free TrueType fonts for the Gujarati languag
ii ttf-indic-fonts 0.4.7 Metapackage for free Indian language fonts
ii ttf-kannada-fonts 0.4.7 Free TrueType fonts for the Kannada language
ii ttf-malayalam-fonts 0.4.7 Free TrueType fonts for the Malayalam langua
ii ttf-oriya-fonts 0.4.7 Free TrueType fonts for the Oriya language
ii ttf-punjabi-fonts 0.4.7 Free TrueType fonts for the Punjabi language
ii ttf-tamil-fonts 0.4.7 Free TrueType fonts for the Tamil language
ii ttf-telugu-fonts 0.4.7 Free TrueType fonts for the Telugu language
ii x-ttcidfont-conf 20ubuntu1 Configure TrueType and CID fonts for X
ii xfonts-100dpi 6.8.2.1-5 100 dpi fonts for X
ii xfonts-75dpi 6.8.2.1-5 75 dpi fonts for X
ii xfonts-base 6.8.2.1-5 standard fonts for X
ii xfonts-konsole 3.4.3-0ubuntu6 fonts used by the KDE's Konsole
ii xfonts-scalable 6.8.2.1-5 scalable fonts for X
ii xfonts-utils 6.8.2.1-5 utilities for X font packages
ii xfontsel 1.0.1-0ubuntu1 X client - xfontsel
ii xlsfonts 1.0.1-0ubuntu1 X client - xlsfonts

[Matt Zimmerman (mdz)]

On Wed, Apr 26, 2006 at 08:32:27PM -0000, PascalCavy wrote:
> I think it is related to this bug report because stracing firefox during its loop show lots of font related system calls.

You can easily test this by disabling pango as described in the earlier
comments. It may be an unrelated problem.

> My method to trigger it is having several desktop configured, open several
> TABS in firefox, then switch desktops going back and forth to the one
> where firefox is. Just try it.

This is my usual way of using firefox, and while it sometimes takes a few
seconds to refresh, I've never seen anything excessive like you describe.

--
 - mdz

[P (p92)]

Well, I have this kind of cpu loop on 2 different machines with 2 different video cards. Can someone have a look at the strace I took during such a CPU hogg loop of firefox to make an idea of what firefox is doing ?

 http://pcpc.vmfacility.fr:8008/

[Marco Cimmino (cimmo)]

Sorry but the solution can be this:
disable pango for language that is not useful and PUT a GUI interface to enable or disable pango so all people who have a language in its system but need to read other languages with pango enabled con do it easy.

Can be done?

[P (p92)]

MOZ_DISABLE_PANGO=1 does a lot of speed improvement for me.LANG=fr_FR.UTF-8
LANGUAGE=fr_FR:fr:en_GB:en
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

But I certainly have another problem with firefox when it receives expose X events to refresh itself, as my strace tries to show up. With pango disabled it happens less, and takes less time to recover from the 100% cpu hogg.

[Ian Jackson (ijackson)]

I have implemented the suggested workaround (turning off pango if no locales are built which we think need it) in 1.5.dfsg+1.5.0.2-0ubuntu2. The list of locales seems rather arbitrary and it would be nice to have some feedback.

I've confirmed using kn.wikipedia.org that pango enable/disablement does make a difference. But I wasn't able to install language-pack-kn due to Malone 42630.

[towsonu2003 (towsonu2003)]

I went a little overboard and posted this: http://ubuntuforums.org/showthread.php?p=979881#post979881
to get some user feedback.

and a question: which exact packages should I upgrade from Dapper Beta2 LiveCD so that I will be testing this? So sorry, but have slow slow dial up... thanks :)

[GonzO (gonzo)]

Thanks for implementing this! Awesome.

[Paul (woanderer)]

great. much better. thanks.

[towsonu2003 (towsonu2003)]

sorry, but in my system (Beta LiveCD Dapper), this made it slower in page rendering and changing tabs. The only things I upgraded in the default LiveCD were:

~$ ls /var/cache/apt/archives/
firefox_1.5.dfsg+1.5.0.2-0ubuntu2_i386.deb
firefox-gnome-support_1.5.dfsg+1.5.0.2-0ubuntu2_i386.deb
libnspr4_2%3a1.firefox1.5.dfsg+1.5.0.2-0ubuntu2_i386.deb
libnss3_2%3a1.firefox1.5.dfsg+1.5.0.2-0ubuntu2_i386.deb

so this didn't work for me :(((((

MOZ_DISABLE_PANGO=1 firefox was working. I do not have any locales except those preloaded in default LiveCD boot, except the keyboard layout (set to Turkish Q), which isn't supposed to affect this :(

[L. David Baron (dbaron)]

I filed a bug on pango:
http://bugzilla.gnome.org/show_bug.cgi?id=348825 to make the same optimization we made in bug 223813.

[Mwsteele (mwsteele)]

Created attachment 233172
Xft gfxTextRun fallback for the ASCII path

This still abuses pango for font selection but avoids it for measuring.

[Noumaan Yaqoob (noumaan)]

It seems that the fix released is actually stopping web pages in Urdu Fonts to display correctly in Firefox, Epiphany, Mozilla Thunderbird. However it does not effects Galeon.

When I tried Firefox after adding:

MOZ_DISABLE_PANGO=0 in /etc/environment

It started rendering Urdu web pages perfectly. What does it mean? Well whatever it does, it is surely stopping a whole lot of people who read Urdu web pages using Firefox, seeing that their beloved web browser in Ubuntu doesn't display their language they would prolly switch back.

another interesting thing that happened after trying this solution was that Galeon inherited firefox's behavior.

[Constantine Evans (cevans)]

BBCUrdu seems to be rendering without any obvious (eg, boxes) problems for me with Pango disabled (though I know nothing about the language), but we probably should err on the side of safety here. Ian, could you consider adding Urdu to the list of locales requiring Pango?

[Noumaan Yaqoob (noumaan)]

Actually what firefox does is that it displays the page with out Pango most urdu pages remain readable but firefox uses someother font like Tahoma (if installed) and it even renders Tahoma badly for urdu.

I don't quite understand how this patch works. I assume that by Installing Urdu language packs from Language Selector we would be able to use pango system wide?

[Matt Zimmerman (mdz)]

On Sun, Aug 20, 2006 at 01:27:35AM -0000, Noumaan Yaqoob wrote:
> Actually what firefox does is that it displays the page with out Pango
> most urdu pages remain readable but firefox uses someother font like
> Tahoma (if installed) and it even renders Tahoma badly for urdu.
>
> I don't quite understand how this patch works. I assume that by
> Installing Urdu language packs from Language Selector we would be able
> to use pango system wide?

This isn't about the performance issue; please file a separate bug about the
Urdu issues.

--
 - mdz

[Noumaan Yaqoob (noumaan)]

Matt actually our problem is directly related to the patch applied here. If we enable Pango by adding:

MOZ_DISABLE_PANGO=0

We would be able to render Urdu Pages but our Firefox would be a lot more slower and consuming 100% cpu resources at times. I have noticed that with Pango enabled firefox crashes quite often and that it is certainly not an acceptable compromise.

We already have a bug report filed #54091. But the solution to our problem lies right here. How Ubuntu decides to deal with this bug directly affects the Urdu Font rendering and Firefox performance issues for us.

[Rui Matos (tiagomatos)]

On Dom, 2006-08-20 at 20:54 +0000, Noumaan Yaqoob wrote:
> We already have a bug report filed #54091. But the solution to our
> problem lies right here. How Ubuntu decides to deal with this bug
> directly affects the Urdu Font rendering and Firefox performance issues
> for us.
>
I think an important variable to know here is how does the upstream
binary version of firefox copes with Urdu font rendering? And what about
its performance doing so?

[Matt Zimmerman (mdz)]

On Sun, Aug 20, 2006 at 08:54:50PM -0000, Noumaan Yaqoob wrote:
> We already have a bug report filed #54091. But the solution to our
> problem lies right here. How Ubuntu decides to deal with this bug
> directly affects the Urdu Font rendering and Firefox performance issues
> for us.

Thank you; please continue any discussion in bug #54091 and refer to this
bug there fro background.

--
 - mdz

[Pavlov (pavlov)]

Comment on attachment 233172
Xft gfxTextRun fallback for the ASCII path

remove the printfs. we should get this in to the tree.

[Vladimir Vukicevic (vvuk)]

Comment on attachment 233172
Xft gfxTextRun fallback for the ASCII path

>
>+#define XFT_MEASURE 1
>+
>+gfxTextRun*
>+gfxPangoFontGroup::MakeTextRun(const nsACString& aString)
>+{
>+#ifdef XFT_MEASURE
>+ return new gfxXftTextRun(aString, this);
>+#else
>+ return new gfxPangoTextRun(NS_ConvertASCIItoUTF16(aString), this);
>+#endif
>+}

Call this something other than XFT_MEASURE -- maybe USE_XFT_FOR_ASCII or something.

Looks fine otherwise, though.

[Bzbarsky (bzbarsky)]

I tried testing that patch, but it doesn't compile (presumably needs merging to tip?):

../../../../mozilla/gfx/thebes/src/gfxPangoFonts.cpp:180: cannot allocate an
   object of type `gfxXftTextRun'
../../../../mozilla/gfx/thebes/src/gfxPangoFonts.cpp:180: because the
   following virtual functions are abstract:
../../../dist/include/thebes/gfxFont.h:202: virtual nsrefcnt
   gfxTextRun::AddRef()
../../../dist/include/thebes/gfxFont.h:202: virtual nsrefcnt
   gfxTextRun::Release()

I'd love a working version of the patch to run on some testcases...

[Masayuki (masayuki)]

Can this patch drawing the intl text? (CJK, complex scripts and RTL text)

[Mwsteele (mwsteele)]

Created attachment 235325
Update the previous patch to handle more cases.

Strings passed down from layout as ASCII or strings passed as Unicode in the ASCII range will be handled faster with this patch. The rest are handled by the original Pango path. The updated patch adds a check to the Unicode path for compatible strings to steal to the Xft path.

[Vladimir Vukicevic (vvuk)]

Comment on attachment 235325
Update the previous patch to handle more cases.

>Index: gfx/thebes/src/gfxPangoFonts.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/gfx/thebes/src/gfxPangoFonts.cpp,v
>retrieving revision 1.30
>diff -u -r1.30 gfxPangoFonts.cpp
>--- gfx/thebes/src/gfxPangoFonts.cpp 9 Aug 2006 21:36:37 -0000 1.30
>+++ gfx/thebes/src/gfxPangoFonts.cpp 24 Aug 2006 23:16:56 -0000

>@@ -530,7 +597,7 @@
> mMetrics.subscriptOffset = mMetrics.xHeight;
>
> pango_font_metrics_unref (pfm);
>-#endif
>+ #endif

^ broken

>+ } else {
>+ printf ("SPACE ME!\n");
>+ }
>+

I'd remove this printf, or at least make it dependant on DEBUG. It doesn't do anything more than a // XXX fixme would do, though.

[Mwsteele (mwsteele)]

Created attachment 235341
Fix stupid whitespace droppings.

[Pavlov (pavlov)]

patch checked in.

[Bugzilla-dolphinling (bugzilla-dolphinling)]

I love you all.

Is this actually completely fixed, or is there still more work to be done? (Or is what still needs to be done getting the Pango and XFT bugs fixed?)

[Pavlov (pavlov)]

i'm sure there is more to do but this makes a huge difference. I would say it is no longer "unusably slow"

[L. David Baron (dbaron)]

...for users with Latin-based languages only?

[Bzbarsky (bzbarsky)]

For ASCII users only. Any text fragment that has a non-ASCII char gets the old slow code.

[Mozilla-behdad (mozilla-behdad)]

I confess I'm totally lost. Are you using PangoXft with cairo?!

[Mwsteele (mwsteele)]

(In reply to comment #18)
> I confess I'm totally lost. Are you using PangoXft with cairo?!
>

No. The file is possibly misnamed now. The intention was to add a fast path that (at the very least) *avoids* using Pango for measuring the types of strings we need to measure. This second path was wedged in with the existing Pango code but it uses Xft alone to measure and get the glyph indices. Glyphs are then (still) rendered with the cairo font API.

[Masayuki (masayuki)]

This patch breaks Japanese text that has ASCII characters...
If the text is:
aaaaaaBBBBBBB

Assume that the 'a' is an ASCII character, and 'B' is an Japanese character.
If selecting as following:

aaaaaaBBBBBBB
  |<---->|

The first fragment is rendered by Xft. But the 'a's of the second fragment are rendered by pango. I think that we should not separate the gfxTextRun. I think that we should merge the gfxTextRuns after bug 339513.

[Mozilla-behdad (mozilla-behdad)]

(In reply to comment #19)
> (In reply to comment #18)
> > I confess I'm totally lost. Are you using PangoXft with cairo?!
> >
>
> No. The file is possibly misnamed now. The intention was to add a fast path
> that (at the very least) *avoids* using Pango for measuring the types of
> strings we need to measure. This second path was wedged in with the existing
> Pango code but it uses Xft alone to measure and get the glyph indices. Glyphs
> are then (still) rendered with the cairo font API.

I perfectly understand that. But it doesn't change a thing. You are using PangoXft (pango_xft_font_get_font for example) and cairo, bridging in between yourself, instead of using PangoCairo. I won't comment on the level of pain that brings, and let alone what a broken design it is, but it does mean that I can't and won't spend time making it faster as all my focus is in PangoCairo...

[Mozilla-behdad (mozilla-behdad)]

For the record, this approach means duplicate caches (in cairo and in Xft), and not enjoying the optimization work that Federico and I did in pangocairo last fall, *including* a very fast cache for glyph extents in pangocairo.

[L. David Baron (dbaron)]

If defeating a very fast cache makes us much faster, then the very fast cache doesn't seem to be much help in this case.

[Mozilla-behdad (mozilla-behdad)]

(In reply to comment #23)
> If defeating a very fast cache makes us much faster, then the very fast cache
> doesn't seem to be much help in this case.

No, you don't get it. From what I see and feel, you are not using PangoCairo at all. I will feel a lot better if proved wrong.

[Bzbarsky (bzbarsky)]

You're correct that PangoCairo is not used, except on BeOS. We'd love to use it, but aren't in a position to do so due to the requirements it has. We'd love for those requirements to change so we can use it.

Specifically, last I checked PangoCairo needs pango 1.10 or higher. See bug 305649 comment 8. For reference, FC4 ships with pango 1.8. FC3 shipped (as recently as end of 2004) with pango 1.6. Our current code (using CairoXft) requires pango 1.6, which is still a huge jump in requirements over what we require for Gecko 1.8, but we're _really_ not in a position to require that all of our Linux users upgrade to FC5 or newer.

If you can make PangoCairo work with pango 1.6, we should be able to use it, and that would be very nice. If it requires 1.8, we can at least think about it.... But the current runtime requirements of PangoCairo simply make it unusable for our purposes. So we've had to work around that by using PangoXft for fonts, with resulting problems all around.

[Mwsteele (mwsteele)]

I would suggest that it's not a very strong position to jump in to a thread with "I confess I'm totally lost." and then follow up with a "No, you don't get it.", but that's perhaps a style choice.
I think it's a good time to reiterate something that's been mentioned several times in this thread, including once when specifically asked: the intention was to avoid using Pango.
If the gripe was "yes, but you're still (mis)using a piece of API", then perhaps something more constructive could have been added to this bug. Yet even if that were the case, the point of this patch has been missed completely since, *obviously*, that all could have been implemented (and has been!) with purely fontconfig & Xft calls. It turns out it's faster and more interesting in the short term for several reasons to use the same code paths that the other Pango code is eventually forced to use. After all, this optimization is a *special case* for only a few languages. If this "design" still bothers you, consider it an work-in-progress experiment. Instead, the post went out of its way to say "I won't comment" and "I won't make it faster".
I'll have to assume this is in reference to
http://bugzilla.gnome.org/show_bug.cgi?id=348825 the cache-miss-as-norm behavior of the fontset cache that is very clearly exhibited with with the slightest experimentation (You've done some right? How is that sorting several times per page going?).
If this is the case, the hostile attitude is very unfortunate for users of Pango, especially obscure corner cases like, you know, web browsers.
It's especially important to remember that this particular cache is the very same cache that misses many times per page load *using* PangoCairo, which impairs page load times even WITHOUT drawing a single string. Additionally, pango_shape also stands way out. So, it turns out you're right in that point that I was NOT enjoying the optimization work done last fall!
So, one more time, there are performance wins because this patch largely *avoids* using Pango to measure. It's an unfortunate side note that it was only after this that a comment on Pango performance was made from someone working on Pango.
Since I'm such a glass-is-half-full type, I see this as a great opportunity for rapid improvement, at least for users on future platforms!

[Bzbarsky (bzbarsky)]

For what it's worth, I profiled the testcases on bug 64858 with this patch. Overall cairo time is now only about 20% slower than GTK2/XFT time (down from 400% slower). nsThebesFontMetrics::GetWidth is now only about 2.5x slower than nsFontMetricsXft::GetWidth (down from 100x or so).

The breakdown for nsThebesFontMetrics::GetWidth is about like so:

gfxXftTextRun::Measure takes about 20% more time than nsFontMetricsXft::GetWidth (and seems to be doing about the same things).

gfxXftTextRun::~gfxXftTextRun and gfxPangoFontGroup::MakeTextRun together take almost as much time as gfxXftTextRun::Measure. Caching text runs in nsTextFrame or something (like we plan to, right?) would be a nice win there.

There seems to be a lot of string object creation and destruction around, with temporary nsDependentCSubstrings floating about. If the "call gfx with char pointer" case is the common one (and I think it is), would it make sense to make gfxXftTextRun::gfxXftTextRun take an nsDependentC?String& as an arg and make the member a nsDependentC?String reference instead of an actual object? Or give it constructors that take char* and length? I guess the problem is that MakeTextRun takes an nsAC?String. But maybe we should change that (e.g. add other signatures)?

[Bzbarsky (bzbarsky)]

We should file separate bugs on any concrete plans along those lines, btw.

Behdad Esfahbod, please do let me know what the dependency story of PangoCairo is; e-mail me if you don't want to clutter the bug up with it. We'd really like to use whatever is being most worked on and most optimized, if we can.

[L. David Baron (dbaron)]

(In reply to comment #27)
> Or give it constructors that take char* and length? I guess the problem is
> that MakeTextRun takes an nsAC?String. But maybe we should change that (e.g.

New APIs should not take nsAC?String. They should take nsC?Substring (or nsC?String, if appropriate). nsAC?String exists only for backwards compatibility with the old string API; nsC?Substring is equivalent, but without the vtable pointer magic.

[Mwsteele (mwsteele)]

I noticed the string object overhead myself too after the first version of patch. It was easier to see this sticking out in profiles with the patch speedup and I changed the nsCString to nsDependentCString. As these strings are just (uni)char * up in nsTextFrame, I was wondering if we couldn't just use those straight through. Should this move to a new bug?

[Bzbarsky (bzbarsky)]

Yeah. Mark, you want to file? If it doesn't happen by Monday, I'll do it, but I'm basically offline starting now and until then.

[Vladimir Vukicevic (vvuk)]

(In reply to comment #27)
> gfxXftTextRun::Measure takes about 20% more time than
> nsFontMetricsXft::GetWidth (and seems to be doing about the same things).

I'd guess this is due to us forcing layout to do word-by-word measurement; going around pango seems to be an overall win though, and we can probably wait until the textframe rewrite is done to see what happens to the numbers.

There's some code to use pango-cairo in the tree right now, enabled by a #define; I'm not 100% sure it still works, but it would be interesting to fix it up and get performance numbers for using pango-cairo for everything. If we can get those numbers to be in line with the Xft numbers, then we can investigate going down the somewhat painful route of doing runtime pango version checking and using pango-cairo if it's available, otherwise falling back to pango-xft. This would mean we could have the "new-world" code in the tree, already being used and tested, letting us just jettison the old code at some point post-gecko 1.9/1.10/2.0/whatever once we're ready to increase our linux platform requirements.

[Jwalden+bmo (jwalden+bmo)]

(In reply to comment #30, comment #31)

The method signature changes wrt string types are bug 351135.

[Mozilla-behdad (mozilla-behdad)]

Sorry for the long delay.

(In reply to comment #25)
> You're correct that PangoCairo is not used, except on BeOS. We'd love to use
> it, but aren't in a position to do so due to the requirements it has. We'd
> love for those requirements to change so we can use it.
>
> Specifically, last I checked PangoCairo needs pango 1.10 or higher. See bug
> 305649 comment 8. For reference, FC4 ships with pango 1.8. FC3 shipped (as
> recently as end of 2004) with pango 1.6. Our current code (using CairoXft)
> requires pango 1.6, which is still a huge jump in requirements over what we
> require for Gecko 1.8, but we're _really_ not in a position to require that all
> of our Linux users upgrade to FC5 or newer.

Well, pangocairo is as old as cairo itself, and requires a pango version of the same age. It may be possible to use pangocairo with older versions of pango if someone does the job of backporting it, but from the upstream point of view, pangocairo is part of the pango distribution and released with pango. there have been three stable versions of pango shipping with it now: 1.10, 1.12, and 1.14.

I would argue that by the time that Firefox want so ship with pangocairo, FC5 is not such a huge requirement. Earlier Fedora versions don't have cairo either afterall. I know mozilla currently has its own cairo copy, but isn't the plan to remove that and use upstream when all the patches are merged (almost there)?

> If you can make PangoCairo work with pango 1.6, we should be able to use it,
> and that would be very nice. If it requires 1.8, we can at least think about
> it.... But the current runtime requirements of PangoCairo simply make it
> unusable for our purposes. So we've had to work around that by using PangoXft
> for fonts, with resulting problems all around.

So, if I understand it correctly the code paths in question use Pango unconditionally, right? In the Firefox 1.5 series that Pango is optional, requiring pangocairo is not such a big deal I assume.

Anyway, basing your future rendering on the cairo+pangoxft set of libraries doesn't sound right to me.

Also, about the patch in this bug, it will make a difference in rendering of Latin. Pango now enabled OpenType Layout processing for Latin fonts. This means, the Xft measurements don't take into account things like ligatures, while the pango path does.

(In reply to comment #26)
> I would suggest that it's not a very strong position to jump in to a thread
> with "I confess I'm totally lost." and then follow up with a "No, you don't get
> it.", but that's perhaps a style choice.

I didn't know that expressing my confusion may be offensive. Put it on me being totally shocked.

> I think it's a good time to reiterate something that's been mentioned several
> times in this thread, including once when specifically asked: the intention was
> to avoid using Pango.
> If the gripe was "yes, but you're still (mis)using a piece of API", then
> perhaps something more constructive could have been added to this bug. Yet even
> if that were the case, the point of this patch has been missed completely
> since, *obviously*, that all could have been implemented (and has been!) with
> purely ...

[Pavlov (pavlov)]

(In reply to comment #34)
> I would argue that by the time that Firefox want so ship with pangocairo, FC5
> is not such a huge requirement. Earlier Fedora versions don't have cairo
> either afterall. I know mozilla currently has its own cairo copy, but isn't
> the plan to remove that and use upstream when all the patches are merged
> (almost there)?
>
afaik, the plan is for us to ship our own version of cairo with our builds. What upstream distributors do is up to them and the Firefox trademark guidelines.

> ... ligature stuff ...
While having support for ligatures from pango would be nice, we simply can't take a 500% slowdown for them. We want to special case any non-complex text to avoid pango entirely because it is so slow for so little gains. The slowness is pango_shape and pango_itemize. I realize these certainly aren't the easiest functions to optimize, but they are where the performance problems live. I don't want to speculate how to fix them as I haven't looked at the code in a long long time and haven't looked at recent performance profiles.

> ... pangocairo vs pango+xft stuff ...
The pangocairo vs pango+xft argument should really go in a seperate bug. As far as I know it has no real performance implications. We'll move to using pangocairo once at least our developers have machines that have pangocairo installed on them which wasn't the case when we stopped using pangocairo. I would like to see distributors ship updated pango versions to their older releases so that we can use pangocairo on them. Dropping some % (not going to speculate on numbers here) of potential linux users for something we can work around seems silly, even if pangocairo is clearly what we want.

[Bzbarsky (bzbarsky)]

> I would argue that by the time that Firefox want so ship with pangocairo

This would be in 6 months, right? And all developers would need to have such machines right now?

> FC5 is not such a huge requirement.

Ah. You're one of those people who're so common in the Linux distro world who assumes everyone upgrades their OS as soon as the next version comes out. Sorry, but that's just not the case. There's no way we can ship in 6 months requiring FC5, imho.

> isn't the plan to remove that and use upstream when all the patches are
> merged

We'll continue shipping cairo libs with our product until such a time as they're widely available as part of OSes, as I understand. I think pavlov covered the details here.

> the code paths in question use Pango unconditionally

Yes.

> requiring pangocairo is not such a big deal I assume.

If it gets backported, sure. There's a big difference between requiring an OS that shipped sometime in the last 3 years (what we plan to do now) and an OS that shipped sometime in the last 9 months (what you're proposing we do). So yes, as things stand requiring pangocairo would be a big deal.

> basing your future rendering

We'd be happy to base our rendering on the "right thing" if the "right thing" actually existed in users' OSes. If it doesn't, we can't until such a time as it does. It's really that simple.

> This means, the Xft measurements don't take into account things like
> ligatures

For what it's worth, last time I profiled the pango measurement path (just the measurement) was about 120 times slower than the Xft path. This is on FC4 here, with PangoXft. Pageload performace was 400% slower with pango than without. I clearly can't test PangoCairo because I'd need to upgrade my OS first.

Ligatures are nice (in fact, anything that gets us closer to what TeX does is generally nice), but not with this sort of perf hit....

Again, it's unfortunate that as things stand we're unable to profit from your PangoCairo performance work. Anything that would change that situation would be welcome.

> earlier than this past July (ie, three months ago.)

That's about when we started actually trying to figure out why the builds using pango were so slow. We didn't start using pango much before that; and before that we were using Xft directly.

> So, what should I do? Open a bug "please use pangocairo"?

Get pangocairo backported into pango versions that are actually shipped to an overwhelming majority of Linux users so we don't have to give people the "to use our browser you MUST update your operating system" crap that will make them simply not use our browser?

[Roc-ocallahan (roc-ocallahan)]

A few extra points...

Distributors (e.g., Redhat and SuSE) have in the past been forced to update Firefox to new major versions even on their stable (supported for several years) product lines, in order to keep up to date with security fixes. This may or may not happen again, but it seems wise to keep the dependency requirements at a minimum just in case it does.

Let's not lose sight of vlad's comment #32. We can use pangocairo if available at runtime, if there's a benefit.

Just in case some people aren't aware, the Redhat Pango patch for FF1.5/2, and our current trunk cairo/Pango code, abuse Pango badly. They create Pango objects every time we draw a string or measure text *word by word*. The new textframe code should help a lot, by letting us create Pango objects just once, for large chunks of text (per text node), and thus considerably reduce the 400% pageload hit that Boris quoted. So it's premature to draw specific conclusions about the whole-browser performance impact of Pango ... but it will still be significant, for sure.

I would really really really like to have a solution for non-complex text that gives us ligatures and kerning with good performance, and I don't care what it's called or who owns it. As an eternal optimist, I refuse to believe it's impossible.

[Ian Jackson (ijackson)]

Ian Jackson writes ("Re: [Bug 32561] Re: Pango-enabled firefox is much slower"):
> I'll check to see if the latest betas have the patch discussed there
> included; I'm not sure, because it's listed as `Trunk'. If so then we
> could turn off our hack (which en/disable pango depending on the
> locales).

I'm afraid that 2.0b2 doesn't even have the files mentioned in the
patch on the upstream bug (Mozilla Bugzilla 334064, attachment id
233172). So we can't drop our pango-disablement change yet.

Ian.

[Mozilla-behdad (mozilla-behdad)]

(In reply to comment #35)
> (In reply to comment #34)
> > I would argue that by the time that Firefox want so ship with pangocairo, FC5
> > is not such a huge requirement. Earlier Fedora versions don't have cairo
> > either afterall. I know mozilla currently has its own cairo copy, but isn't
> > the plan to remove that and use upstream when all the patches are merged
> > (almost there)?
> >
> afaik, the plan is for us to ship our own version of cairo with our builds.
> What upstream distributors do is up to them and the Firefox trademark
> guidelines.
>
> > ... ligature stuff ...
> While having support for ligatures from pango would be nice, we simply can't
> take a 500% slowdown for them. We want to special case any non-complex text to
> avoid pango entirely because it is so slow for so little gains.

I appreciate it if you point me to benchmarks such that I can reproduce the 500%. The Pango-based Firefox shipped in Fedora is definitely not 500% slower. Not from benchmarks I've seen. There's the fontset caching problem, but that's been improved and I'm still working on it. And like Robert pointed, the pango backend in Firefox 1.5 is doing really bad things with Pango.

(In reply to comment #36)
> > I would argue that by the time that Firefox want so ship with pangocairo
>
> This would be in 6 months, right? And all developers would need to have such
> machines right now?

Is it? http://www.mozilla.org/projects/firefox/roadmap.html says "Q1 2007?", but then the same page also says "2 late Q2/early Q3 2006 Final Release". Do you expect me to believe that page?

> > FC5 is not such a huge requirement.
>
> Ah. You're one of those people who're so common in the Linux distro world who
> assumes everyone upgrades their OS as soon as the next version comes out.

I'm not. I'm just a developer. If you expect someone like me to fetch and compile the developmental Firefox versions (which takes a one or two gigs) to test and optimize it, why can't Firefox developers install a three tiny libraries that are glib, cairo, and pango?

> Sorry, but that's just not the case. There's no way we can ship in 6 months
> requiring FC5, imho.

You can ship with internal copies of glib and pango and gtk+.

> > This means, the Xft measurements don't take into account things like
> > ligatures
>
> For what it's worth, last time I profiled the pango measurement path (just the
> measurement) was about 120 times slower than the Xft path. This is on FC4
> here, with PangoXft.

That's such a bold statement. Do you have any benchmarks? I'm very interested in checking them out.

> Pageload performace was 400% slower with pango than
> without. I clearly can't test PangoCairo because I'd need to upgrade my OS
> first.

If you, a developer, need to upgrade your OS first to get a non-ancient Pango, why do you think all your users install Firefox on ancient operating systems?

> > So, what should I do? Open a bug "please use pangocairo"?
>
> Get pangocairo backported into pango versions that are actually shipped to an
> overwhelming majority of Linux users so we don't have to give people the "to
> use our browser you MUST update your operating sy...

[Pavlov (pavlov)]

(In reply to comment #38)
>
> Suppose that I backported pangocairo to work with pango-1.8. How are your
> users going to get that pangocairo library?

Ideally, the distros would ship updates to their users.

[Mozilla-behdad (mozilla-behdad)]

(In reply to comment #39)
> (In reply to comment #38)
> >
> > Suppose that I backported pangocairo to work with pango-1.8. How are your
> > users going to get that pangocairo library?
>
> Ideally, the distros would ship updates to their users.

Distros just don't do that. Not to include a new library.

[Carl Worth (cworth)]

Am I understanding the approach correctly:

"Mozilla must bundle cairo because not all users of interest have it already."

"Mozilla must not use pangocairo because not all user of interest have it already."

If that's an accurate statement of the current thinking, then what's the distinction between cairo and pangocairo here?

As for performance bugs, I'm quite sure we all just want to get them fixed. Let's continue working together on that.

-Carl

[Pavlov (pavlov)]

(In reply to comment #41)
> Am I understanding the approach correctly:
>
> "Mozilla must bundle cairo because not all users of interest have it already."
>
> "Mozilla must not use pangocairo because not all user of interest have it
> already."
>
> If that's an accurate statement of the current thinking, then what's the
> distinction between cairo and pangocairo here?
>

The distinction is that we _have_ to ship with cairo. We don't have to ship with pangocairo. In fact, I'm not sure what it buys us except for perhaps slightly easier to deal with and more headaches.

Again, pangocairo nonsense talk should be moved to another bug.

[Carl Worth (cworth)]

(In reply to comment #42)
> The distinction is that we _have_ to ship with cairo. We don't have to ship
> with pangocairo. In fact, I'm not sure what it buys us except for perhaps
> slightly easier to deal with and more headaches.

I would think it would be an obvious win to work together with pango upstream for doing pango/cairo integration as efficiently as possible.

I think that that's all that Behdad meant when saying he "can't and won't spend time making it faster". If mozilla does its own custom integration of pango with cairo, then mozilla owns it, and there's obviously little that pango maintainers can do about that.

-Carl

[Bzbarsky (bzbarsky)]

(In reply to comment #38)
> I appreciate it if you point me to benchmarks such that I can reproduce the
> 500%.

Sure. Take trunk builds from before the patch for this bug landed, both cairo and non-cairo. Load the testcases in bug 64858. You might need to edit out the JProfStartProfiling/JProfStopProfiling calls unless you're actually profiling with jprof. Look at the reported times. I get about 4x better performance with the non-cairo builds, with the vast majority of the time difference being text measurement performance.

As Robert said, a lot of this is impedance mismatch between what pango wants to do and what current trunk is trying to get it to do. But that doesn't help the fact that right now trunk was unusable for daily browsing. The more text, the less usable. Once we rearchitect our layout code around what pango and such want, we'll have to remeasure, of course; at that point we should revisit the changes made in this bug.

> The Pango-based Firefox shipped in Fedora is definitely not 500% slower.

I can't speak to what changes Fedora made and what they use pango for. Our real concern is trunk going forward.

> Is it? http://www.mozilla.org/projects/firefox/roadmap.html says "Q1 2007?",

That would be in like 3 months. I'm giving it some slack here. ;)

> Release". Do you expect me to believe that page?

Not at all. I don't believe it myself. ;)

> I'm not. I'm just a developer. If you expect someone like me to fetch and
> compile the developmental Firefox versions

When have I ever asked you to do that?

> (which takes a one or two gigs)

Non-debug builds don't one or two gigs... And those are all you need for optimization (profiling) purposes. But that's neither here nor there.

> why can't Firefox developers install a three tiny
> libraries that are glib, cairo, and pango?

In brief, because the package systems on Linux suck. For example, I can't install an updated pango without updating hundreds of other packages, due to the RPM dependency mess. Worse yet, users would have to have the updated pango too, which means either the distros need to ship it or we need to.

> You can ship with internal copies of glib and pango and gtk+.

We could, but that's something we'd like to avoid. Given that all the paths forward seem to suck, we're going to got with what we see as the lesser evils.

> That's such a bold statement. Do you have any benchmarks? I'm very
> interested in checking them out.

See beginning of this comment.

> If you, a developer, need to upgrade your OS first to get a non-ancient
> Pango,

I'm not a pango developer. I'm a pango user. I'm developing on my own machine, part-time, and the machine is used for a whole lot of things other than Firefox development.

> why do you think all your users install Firefox on ancient operating systems?

First of all, a year old is not exactly ancient. Second of all, when did I say "all"? I'm not saying all Linux users use FC3 or FC4 or equivalent. I'm saying not all use FC5. Please don't put made-up words in my mouth.

> Suppose that I backported pangocairo to work with pango-1.8. How are your
> users going to get that pangocairo library?

Like I sa...

[L. David Baron (dbaron)]

(In reply to comment #38)
> You can ship with internal copies of glib and pango and gtk+.

There may be legal obstacles to doing that. glib, pango, and gtk+ are not licensed under the MPL, as far as I am aware.

[Mozilla-behdad (mozilla-behdad)]

Ok, going to shut up here. Just:

  - I've been defensive, because I was attacked upon. Doesn't matter though.

  - Unless you use Pango the way it is supposed to be used, please stop saying "pango is slow".

[Bzbarsky (bzbarsky)]

> - Unless you use Pango the way it is supposed to be used,

The problem is that the way it's "supposed" to be used isn't very compatible with rendering web content. Consider, for example, trying to render the following simple HTML + CSS with pango:

  <div> This is
    <span style="letter-spacing: 0.5em">so<span
       style="font-size: large">me</span> text</span>
    that has simple styling.
  </div>

(this is not particularly contrived markup; in the "real" world you get stuff like this all the time, esp. with font changes).

Pango seems to assume that what you're rendering are large paragraphs of text, all with the same styling. For a typical website, that's not what's being rendered....

[Mozilla-behdad (mozilla-behdad)]

(In reply to comment #47)
> > - Unless you use Pango the way it is supposed to be used,
>
> The problem is that the way it's "supposed" to be used isn't very compatible
> with rendering web content. Consider, for example, trying to render the
> following simple HTML + CSS with pango:
>
> <div> This is
> <span style="letter-spacing: 0.5em">so<span
> style="font-size: large">me</span> text</span>
> that has simple styling.
> </div>
>
> (this is not particularly contrived markup; in the "real" world you get stuff
> like this all the time, esp. with font changes).
>
> Pango seems to assume that what you're rendering are large paragraphs of text,
> all with the same styling. For a typical website, that's not what's being
> rendered....

Not at all. First, Pango has two levels of API. 1) PangoLayout, 2) bare pango_itemize, pango_shape, pango_break. And both of these support all the styling in your example. Slightly different perhaps, but quite possible to match. Pango supports that using attributes. It even has a convenience markup language. In Pango markup speak, your example can be rendered using:

  pango-view --markup --text 'This is <span letter_spacing="6144">so<span size="large">me</span> text</span> that has simple styling.'

The letter-spacing attribute in Pango takes an absolute size, but that's something that can be fixed if need be.

[L. David Baron (dbaron)]

(In reply to comment #46)
> - Unless you use Pango the way it is supposed to be used, please stop saying
> "pango is slow".

Are you saying that pango isn't supposed to be used without pangocairo, or that pango isn't supposed to be used without holding on to pango objects, or something else? We're planning to fix the latter, but even with that change some of the performance problems (e.g., font sorting) are probably still going to be a problem.

[Bzbarsky (bzbarsky)]

> And both of these support all the styling in your example.

In a way that is 100% compatible with the CSS specification?

[L. David Baron (dbaron)]

(In reply to comment #50)
> > And both of these support all the styling in your example.
>
> In a way that is 100% compatible with the CSS specification?

I'd be hesitant to leave such support to OS libraries in any case. Having the same bugs across platforms makes us an easier target for Web developers, and being able to advance faster than operating systems gives us the ability to move the Web forward faster than the OS-upgrade cycle (which is probably significantly slower on operating systems that people pay for).

[Mozilla-behdad (mozilla-behdad)]

(In reply to comment #50)
> > And both of these support all the styling in your example.
>
> In a way that is 100% compatible with the CSS specification?

I don't know. But you can set the attributes whatever way you want, to match whatever you want.

[Mozilla-behdad (mozilla-behdad)]

Created attachment 238095
pangocairo-lite

Attaching a ripped off pangocairo. It's dead easy to get it working with pango 1.8. The only new API it uses that is not in 1.8 is pango_font_get_font_map, but if you can track what it's used for, it's very easy to work around it.

[Roc-ocallahan (roc-ocallahan)]

We'd be lucky if Pango's implementation of letter-spacing matches CSS's in terms of exactly where spacing is allowed and where it's placed (not really dictated in CSS yet, but will be). Ditto for word spacing, justification spacing, tab expansion. There's also non-text elements in lines, relative positioning, CSS borders, hyphenation ... Even if we have lots of luck, we can't expect Pango and CSS to always match for all time, and designing for that would be foolish. Even more so when you bring other platforms into the equation.

[Matt Zimmerman (mdz)]

On Tue, Sep 12, 2006 at 06:07:23PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Bug 32561] Re: Pango-enabled firefox is much slower"):
> > I'll check to see if the latest betas have the patch discussed there
> > included; I'm not sure, because it's listed as `Trunk'. If so then we
> > could turn off our hack (which en/disable pango depending on the
> > locales).
>
> I'm afraid that 2.0b2 doesn't even have the files mentioned in the
> patch on the upstream bug (Mozilla Bugzilla 334064, attachment id
> 233172). So we can't drop our pango-disablement change yet.

OK, thanks for looking into it.

--
 - mdz

[John Moser (nigelenki)]

(alternately, form teams and conduct an undercover mission to determine what Pango is up to and why it's so slow...)

[jimveta (jimveta)]

A late Hello... just curious.. has anyone addressed or investigated David Finch's issue of the Mozilla build being significantly faster even with Pango disabled? Or should this be a seperate bug?

====================================================
I reran my benchmark on this system to test pango enabled vs disabled:
Dapper build, with pango enabled: 32.3 seconds
Dapper build, with pango disabled: 25.0 seconds, noticeably faster
Official linux build from Mozilla: 12.7 seconds, a 2x improvement over disabling pango

There may be more to the problem than pango, it seems.
====================================================

[jojo4u (bugzilla-freedom-x)]

I'am affected on Xubuntu 7.10 (upgraded from 7.04). Firefox version is 2.0.0.6+2nobinonly-0ubuntu1.
Disabling pango by MOZ_DISABLE_PANGO=1 doubles speed on a local copy of http://scragz.com/tech/mozilla/test-rendering-time. That means from 6.8 s to 3.2 s. My /etc/environment says: LANG="en_US.UTF-8".

[Alexey Spiridonov (snarkmaster)]

I am seeing this on 7.10 Gutsy Gibbon, Firefox 2.0.0.11, and it showed up in a very nasty way. I have an e-mail (see attachment) with lots and lots of text (data files). Opening this e-mail in its original context -- Yahoo mail with its CSS and JS and tables -- caused the browser to effectively hang. It remained non-responsive and at 100% CPU for over 5 minutes. The sanitized version does eventually render, but takes over a minute on my computer. In contrast, with pango disabled (I started with mozilla.com's stock builds, then tried the MOZ_PANGO_DISABLE=1 hack, both work fine), the original e-mail renders in about 15 seconds. The sanitized version renders in about 3. So, using Pango is over 20 times slower for me!

On the other hand, the font rendering without Pango does not match the rest of the system (fonts are different/larger; some are badly hinted). So, it's ugly without Pango, and unstable (yes, unstable, because such a hang makes me kill the browser) with. :(

Can I do something to help get this fixed?

[Vytas (vytas)]

I second that.

I did the same test like jojo4u, I get 9.9 sec with Pango and 5.3 sec without.

Also, Firefox is very slow when multiple tabs with flash are open (might be different bug, might be related).

Gutsy, FF 2.0.0.11

[Vytas (vytas)]

FWIW, the extreme slowness with multiple tabs seems to be gone with MOZ_DISABLE_PANGO=1 too

[Alexander Sack (asac)]

On Sat, Dec 29, 2007 at 01:04:15PM -0000, Vytas wrote:
> FWIW, the extreme slowness with multiple tabs seems to be gone with
> MOZ_DISABLE_PANGO=1 too
>

ok

 affects ubuntu/firefox
 status confirmed

can you please test if firefox-3.0 works better

 affects ubuntu/firefox-3.0
 status incomplete

Thanks,

 - Alexander

[jojo4u (bugzilla-freedom-x)]

3.0~alpha8+nobinonly-0ubuntu1 is not affected. Both settings of MOZ_DISABLE_PANGO bottom out at 2.6 seconds with quite a bit variation upwards.
Firefox 2.0.0.11 is 3.7/1.8 seconds and Swiftfox is 1.4 seconds at the moment.

[Alexander Sack (asac)]

On Fri, Jan 11, 2008 at 03:06:31PM -0000, jojo4u wrote:
> 3.0~alpha8+nobinonly-0ubuntu1 is not affected. Both settings of MOZ_DISABLE_PANGO bottom out at 2.6 seconds with quite a bit variation upwards.
> Firefox 2.0.0.11 is 3.7/1.8 seconds and Swiftfox is 1.4 seconds at the moment.
>

OK, then lets say this is fixed in firefox 3

 affects ubuntu/firefox-3.0
 status fixreleased

Thanks,

 - Alexander

[vontrapp (von-fugal)]

Regarding the list of languages that require pango, Cambodian is one of them. Also known as Khmer, the two letter code is 'kh'.
Any other language based on sanskrit would probably need it. I think Thai was already listed.
I guess this is the place to say this. If there's somewhere/someone else I should tell, please let me know.

[Alexey Spiridonov (snarkmaster)]

I looked at firefox-3.0 also. The results are not bad, but not perfect either:

1) The original e-mail renders quickly and correctly, regardless of MOZ_DISABLE_PANGO (it's unclear if the switch has any effect at all now)
2) The sanitized e-mail that I attached "renders" fast. However, it produces a gigantic area of "no refresh" on the screen. As in, there's a part of the message that just keeps whatever was on that part of the screen before Firefox. And then, when you scroll, that part gets smeared around.

[Alexander Sack (asac)]

On Sun, Jan 13, 2008 at 11:21:24PM -0000, Alexey Spiridonov wrote:
> I looked at firefox-3.0 also. The results are not bad, but not perfect
> either:
>
> 1) The original e-mail renders quickly and correctly, regardless of MOZ_DISABLE_PANGO (it's unclear if the switch has any effect at all now)
> 2) The sanitized e-mail that I attached "renders" fast. However, it produces a gigantic area of "no refresh" on the screen. As in, there's a part of the message that just keeps whatever was on that part of the screen before Firefox. And then, when you scroll, that part gets smeared around.
>

This sounds like a X driver bug. Do you use XAA as accellmethod on
your xorg.conf? if you have a driver that can do EXA, try that and let
us know if your issues goes away.

Thanks,

 - Alexander

[Alexander Sack (asac)]

ffox 2 won't see any non-critical fixes anymore.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/32561