Pango-enabled firefox is much slower

Bug #32561 reported by David Finch on 2006-02-23
98
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Baltix)
Undecided
Unassigned
firefox (Ubuntu)
Medium
Unassigned
firefox-3.0 (Ubuntu)
Undecided
Unassigned

Bug Description

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.

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.

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.

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.

Changed in firefox:
status: Unconfirmed → Confirmed
Dennis Kaarsemaker (dennis) wrote :

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) wrote :

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

Dennis Kaarsemaker (dennis) wrote :

Sigh...

Luka Renko (lure) wrote :

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

I have also observed a significate difference with pango disabled.

M. (m-0x4d) wrote :

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

Dimos Dimoulis (dimosd) wrote :

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.

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) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

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) wrote :

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

mannheim (kronheim) wrote :

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) wrote :

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) wrote :

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) wrote :

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

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.

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) wrote :

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)

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.

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) wrote :

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) wrote :

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) wrote :

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

try it out!

mikeandmore (mikeandmore) wrote :

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) wrote :

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) wrote :

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.

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.

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.

Matt Zimmerman (mdz) on 2006-04-25
Changed in firefox:
assignee: nobody → ijackson
Ian Jackson (ijackson) on 2006-05-03
Changed in firefox:
status: Confirmed → Fix Released
Changed in firefox:
status: Confirmed → Fix Released
71 comments hidden view all 150 comments

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.

(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.

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

The method signature changes wrt string types are bug 351135.

Download full text (5.8 KiB)

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 ...

Read more...

(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.

> 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?

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 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.

Download full text (3.4 KiB)

(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...

Read more...

(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.

(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.

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

(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.

(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

Download full text (3.6 KiB)

(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...

Read more...

(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.

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".

> - 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....

(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.

(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.

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

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

(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).

(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.

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.

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.

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) wrote :

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

jimveta (jimveta) wrote :

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) wrote :

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".

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) wrote :

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

Changed in firefox:
status: Fix Released → New
Vytas (vytas) wrote :

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

Alexander Sack (asac) wrote :

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

Changed in firefox:
assignee: ijackson → nobody
status: New → Confirmed
jojo4u (bugzilla-freedom-x) 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.

Alexander Sack (asac) wrote :

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

Changed in firefox-3.0:
status: Incomplete → Fix Released

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.

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.

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) wrote :

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

Changed in firefox:
status: Confirmed → Won't Fix
status: New → Invalid
Changed in firefox:
importance: Unknown → Medium
Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing
Displaying first 40 and last 40 comments. View all 150 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.