User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: I have an OpenCL computation that runs in the background at all times. It loads the GPU pretty much fully. Actual results: Thunderbird 5 is extremely slow to respond to input and redraw the UI while the computation is running. If the computation is paused - the interface becomes snappy again. Expected results: Minor slowdowns were expected, but the application should've remained responsive. Thunderbird 3 and Firefox 5 do not seem to suffer from this issue.

hardware acceleration enabled by default. This looks like a dupe of bug 667989

(In reply to comment #1) > hardware acceleration enabled by default. > This looks like a dupe of bug 667989 It's not a dupe of that bug; that bug requests it be disabled because fonts look bad on some systems. This bug is about GPU performance. I'm not sure it's actually a bug or not. Maybe this is just a situation where a user should disable GPU acceleration. (However, I'm not sure why Firefox doesn't experience this problem.)

Display and rendering of fonts are okay, everything is just terribly slow... Where can it be disabled? Couldn't find anything in options or about:config.

I believe you need to set gfx.direct2d.disabled to true.

There are various other reports on similar performance issues posted as part of http://forums.mozillazine.org/viewtopic.php?f=39&t=2239667 thus it's not just an isolated problem. > I believe you need to set gfx.direct2d.disabled to true. That's one of them, others are layers.acceleration.disabled and layers.prefer-*

Disabling those settings improved things greatly. Thanks.

Confirming based on the number of complaints received in the forums, though this may still be resolved as a duplicate of some other bug.

(Quote from bug 668042 comment #6) > As a side note, on an alternative skin (Nuvola to be exact) - I only needed > gfx.direct2d.disabled [but not layers.acceleration.disabled] > I guess that skin doesn't use layering. (Quote from bug 668042 comment #7) > Interesting observation, so this may be related to some feature the new aero > theme is using...

This performance issue also occurs on WinXP when TB5 is started with -safe-mode. Therefore no aero is involved. Toggling config with: layers.acceleration.disabled = true gfx.direct2d.disabled = true layers.prefer-opengl = true ... only helps randomly, means, first it seems to help, but after reboot there are problems again. It's an very old PC with old with ATI Range Fury Pro with last available driver. With TB3 there were no problems. It seams to be a basic window rendering problem, because we noticed this performance inssue even when we want to open dropdown options from the preference menu. It doesn't appears on every movement or click but quite often. Another side effect which is observed (maybe another bug-item?) is: While changing between email-folder, the start-Window (with Items: E-Mail, Account, Properties) appears for a moment. This is easier to notice if your system is already slowed down ;-) , so people without this rendering problem won't notice this side effect. So if there is a general performance issue caused by hardware acceleration and something like a window opening problem, which always at the same time tries to open the start window and the aimed folder, there might be a kind of combined problem?

(In reply to comment #10) > Another side effect which is observed (maybe another bug-item?) is: > While changing between email-folder, the start-Window (with Items: E-Mail, > Account, Properties) appears for a moment. This is easier to notice if your > system is already slowed down ;-) , so people without this rendering problem > won't notice this side effect. Please for a while, forget this side-effect thing. I saw this once on a foreign PC. But can't reproduce this on my own on.

>This performance issue also occurs on WinXP when TB5 is started with -safe-mode. You don't see this bug if it happens in the safemode. The safemode disables hwa

(In reply to comment #12) > >This performance issue also occurs on WinXP when TB5 is started with -safe-mode. > You don't see this bug if it happens in the safemode. The safemode disables > hwa Okay, then there is obviously an other performance issue in the change from TB3 to TB5. Are there other mayor changes, which could cause 100% usage of one core from CPU (not GPU) and blocks TB5 for a while? Should I start a new bug report?

Impact is severe for those users who are affected. But based on gfsn feedback [1] it doesn't seem to have affected large numbers of users. [1] gfsn isn't totally triaged on this issue. But several reports have been consolidated into http://getsatisfaction.com/mozilla_messaging/tags/bug_668552

g.lamken, If safe mode doesn't help but the preferences resolve your issue, then I wouldn't file another bug report. One thing I don't understand - it is claimed in http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_5_0_slow#reply_6066279 that a theme change helps avoid the problem - can someone explain why that is (or can't be) true?

Wayne, see comment #9 and the respective duplicate.

(In reply to comment #15) > g.lamken, If safe mode doesn't help but the preferences resolve your issue, > then I wouldn't file another bug report. > > > One thing I don't understand - it is claimed in > http://getsatisfaction.com/mozilla_messaging/topics/ > thunderbird_5_0_slow#reply_6066279 that a theme change helps avoid the > problem - can someone explain why that is (or can't be) true? (In reply to comment #16) > Wayne, see comment #9 and the respective duplicate. Wayne and rsx11m thanks for following up my thread, but No, no 'aero' or additional TB-Skin is involved. Actually comment #10 is related to comment #9. And to confuse you completely: My colleague who suffers most of this bug confirmed my observation that sometimes happens what I called side effect: means for a glimpse moment the account start window appears instead of the view of a mail or folder, which was clicked. This seems to be important because we suspect that TB needs time to render things which actually aren't needed.

(In reply to comment #14) > Impact is severe for those users who are affected. But based on gfsn > feedback [1] it doesn't seem to have affected large numbers of users. It is affecting 4 of the 6 users in our office I have upgraded to TB5... This is a massively major bug that I hope will be fixed soon. TB5 is basically unusable with the TB process (these are older single core Athlon CPUs) pegged at 99%... Toggling the aforementioned prefs only fixes things temporarily - the next time TB is started, it happens again. Help!!

(In reply to comment #18) > This is a massively major bug that I hope will be fixed soon. TB5 is > basically unusable with the TB process (these are older single core Athlon > CPUs) pegged at 99%... Oh, and they are all XP sp3 machines,so no aero involved either.

(In reply to comment #18) > Toggling the aforementioned prefs only fixes things temporarily - the next > time TB is started, it happens again. would that not point then to something not happening correctly with your preferences? The preference settings should be permanent, and effective/working on every startup, unless something is causing those previous settings to be cleared or bypassed.

If you read the thread referenced earlier, this is happening to others as well - you change the pref, it works until TB is restarted, then the problem returns. This is a TB5 problem - TB3 simply does not have this problem.

(In reply to comment #21) > If you read the thread referenced earlier, this is happening to others as > well - you change the pref, it works until TB is restarted, then the problem > returns. If you known which thread it would help to cite the URL, or cite a bug# which covers that issue (since that problem is not _this_ bug). I skimmed the 3+ URLs posted in this bug and I don't find such a statement.

The first comment on page 2: http://forums.mozillazine.org/viewtopic.php?f=39&t=2239667&start=15

(In reply to comment #23) > The first comment on page 2: > > http://forums.mozillazine.org/viewtopic.php?f=39&t=2239667&start=15 Thanks. If you see issue yourself - "Toggling the aforementioned prefs only fixes things temporarily - the next time TB is started, it happens again." - and it happens in safe mode, please file a new bug under preferences component. Also check if there is something in Error Console.

Actually, I can do you one better... I have isolated the problem down to having the Lightning extension installed. If I remove it, everything is back to normal. It may also be related to the Provider for Google Calendar - but since all of our Calendars are Google Calendars, I can't troubleshoot further without a lot more time/work, which I probably won't be able to do until next weekend (I'm moving this weekend - ugh)... So, what I'm saying is, it may be either *just* the Lightning extension causing it, or the combination of Lightning *and* the Provider for Google Calendar+a Google Calendar configured.

In that case, please file a bug for Calendar in the "Lightning Only" component as that issue is apparently independent from whatever is discussed here.

(In reply to comment #26) > In that case, please file a bug for Calendar in the "Lightning Only" > component as that issue is apparently independent from whatever is discussed > here. Please remember, This problem also occurs with -safe-mode what means no hardware acceleration or Lightning. Maybe simply the 'switch-off' of hardware acceleration doesn't work?

>This problem also occurs with -safe-mode You are commenting at the wrong bug report in that case. This bug is specific to the hardware acceleration and hwa is disabled in the safemode.

(In reply to comment #28) > >This problem also occurs with -safe-mode > You are commenting at the wrong bug report in that case. This bug is > specific to the hardware acceleration and hwa is disabled in the safemode. That's the point I'm not convinced of. But if you have checked the specific code, or have everything already in mind, I have to believe this.

workaround: * gfx.direct2d.disabled to "true", restart TB and then if that doesn't work - set layers.acceleration.disabled preference to "true" and then again restart Thunderbird * or try different theme gfsn topics amount to approx 40 users - http://getsatisfaction.com/mozilla_messaging/tags/direct2d - though it seems like a lot more. There are also crash reports [1], >75% are nvidia, based on examination of crash-stats comments [1] https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&keywords=crash%2C%20&keywords_type=allwords&list_id=1296613&field0-0-0=short_desc&type0-0-1=anywordssubstr&field0-0-1=status_whiteboard&type1-0-1=allwordssubstr&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&value0-0-1=direct2d%20hwa%20d2d&type0-0-0=anywordssubstr&value0-0-0=direct2d%20hwa%20d2d&field1-0-0=short_desc&product=Core&product=MailNews%20Core&product=Thunderbird&field1-0-1=short_desc

Mac issue ... Bug 646043 - Hardware acceleration seems to require discrete GPU on Macs with two GPUs

I am tracking a similar bug for Firefox in bug 692736. May be related.

Simple Workaround I noticed that to continue to work normally I can drag the working window with the mouse: the system returns immediately responsive. I hope that this behavior can help identify the cause of the bug.

Hardware acceleration has now been disabled for TB 9 by bug 689742.