I've been using trunk builds as my primary browser for years, and the enabling of cairo on Linux has made me consider changing that. But if I'm considering changing that, that means many of our users probably are too. And the amount of trunk testing that we get is low enough already -- there are many obvious layout regressions that don't get filed for weeks. When I use a cairo Linux build, it freezes for 1-3 seconds at a time whenever chrome has to be painted. This includes switching tabs, loading pages, going back and forward, etc. Not only does it freeze itself, but it freezes *other* apps more than I've ever seen a program do in any situation other than using up all the memory on the system and swapping intensively. I see this both in my own build and in the 2006-04-08-04-trunk nightly. I suspect a large part of the problem is bug 333249 and bug 333250. I think cairo should be turned off as the default on Linux until this is fixed.
Can you post your X server version and which gfx driver you're using? How much of this is native theme rendering? That is, if you disable native theme, is it usable again?
If I disable native theme, the performance is usable, although the GUI really isn't since Firefox's default theme really depends on native theme. I'm using the X server on Fedora Core 5 (xorg-x11-server-Xorg-1.0.1-9) with the radeon driver (xorg-x11-drv-ati-184.108.40.206-4).
(In reply to comment #2) > If I disable native theme, the performance is usable, although the GUI really > isn't since Firefox's default theme really depends on native theme. Yeah, I filed a bug a while back on making non-native-theme builds usable, just needed some tweaks to our default chrome CSS. But ok, that's a good data point -- if we can improve native theme stuff, that would go a long ways towards improving things, right?
(In reply to comment #3) > -- if we can improve native theme stuff, that would go a long ways towards > improving things, right? Yep. And I supect the native theme stuff is mostly the 2 bugs I mentioned in comment 0.
Yes, looks very much as if the very major part of this is native theming. I used a cairo-gtk2 SeaMonkey trunk build today and it was unusably slow and almost made me cry, when I realized that switching from Classic to Modern theme changed the experience completely: With Classic (native theming, in my case even via the gtk-qt-engine so that it fits with my Qt theme), I'm seeing what dbaron was talking about in comment #0 with CPU use being 100% most of the time. With Modern (no native theming), the build feels as speedy as a 1.8 branch build.
Summary: cairo-gtk2 builds are unusably slow → cairo-gtk2 builds are unusably slow due to native theme code
I filed bug 333187 for this yesterday so one of these bugs should be marked as duplicate. The bug contains some hardware/driver related information if that helps.
Given that I don't see how either of the problems I described are video-driver-specific, I'm marking this a duplicate of the other one, since I may well have misdiagnosed it. I'm quite surprised that it's actually fast for some people, though. (I think it was slow for vlad, and he's the one who decided to turn it on.) *** This bug has been marked as a duplicate of 333187 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 333187 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Given that I don't see how either of the problems I described are > video-driver-specific, I'm marking this a duplicate of the other one, since I > may well have misdiagnosed it. I'm quite surprised that it's actually fast for > some people, though. (I think it was slow for vlad, and he's the one who > decided to turn it on.) It's "slower" for me, but nowhere near unusable.. so hardware/drivers certainly seem to play a part. Maybe we have a different tolerance level of "unusable", we should compare on Monday :)
Also unusable on SuSE 10: xorg-x11-server-6.8.2-100.4 nVidia drivers with MX-200
Seems to work well using gtk-qt-engine, so it's probably GTK+-specific (i.e. Qt doesn't experience the problem).
With the latest nightly build containing the patch for bug 333250 performance has returned to normal for me and interactivity has slightly improved.
I'm still seeing serious problems with current builds, but I've filed them as bug 334064, since they're related to fonts rather than native themes.
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.