Closed Bug 1697999 Opened 4 years ago Closed 2 years ago

Slow, choppy scrolling in folder pane on Mac

Categories

(Thunderbird :: Folder and Message Lists, defect)

Unspecified
macOS
defect

Tracking

(thunderbird_esr78 wontfix, thunderbird_esr91+ wontfix)

RESOLVED WORKSFORME
Tracking Status
thunderbird_esr78 --- wontfix
thunderbird_esr91 + wontfix

People

(Reporter: press, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs, )

Details

(Keywords: perf)

User Story

* Leo (reporter) - v78  macOS 11.2, 10.15
* Joshua (bug 1675697) - 78 (all versions) 10.15.7, 90.0b2 and 91 is NOT a problem
* Josh (bug 1717385) - v90.b2, v94 (but not 91.2.1) "after upgrading to Big Sur from Catalina"
* John Hood - v78, worse with 91, better with gfx.webrender.all
* Paul Hart - 78.13.0, iMac, catalina
* Alex (Bug 1677380) - v78, catalina, BETTER with 91

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.192 Safari/537.36

Steps to reproduce:

Scroll up/down the folder pane with mouse wheel on Mac.

TB 78.x. There were no issues in earlier versions.
macOS 11.2, 10.15

Actual results:

Scrolling is choppy and slow.

Expected results:

Normal scrolling as in pre-78 versions.

Keywords: dupeme, perf

Hi - I'm having a similar issue after upgrading to Big Sur from Catalina. There were no issues before updating. Scrolling in the folder pane is now slow and choppy. I have quit all other programs, rebooted, etc. with no changes. No other programs have any issues.

(In reply to Josh from comment #1)

Hi - I'm having a similar issue after upgrading to Big Sur from Catalina. There were no issues before updating. Scrolling in the folder pane is now slow and choppy. I have quit all other programs, rebooted, etc. with no changes. No other programs have any issues.

I should mention - I'm on TB 90.0b2. The issue is causing a serious work slowdown.

Interesting, I have this slow issue too on TB-78 (all versions)
I have just tried TB 90.0b2 and the issue doesn't exist for me (issue also doesn't exist for me on TB 85.0b3 too)

Very odd. I wonder if there is more then one bug/issue with the slow, choppy scrolling in folder pane

The problem with the choppy scrolling is that XUL <tree> uses fallback drawing, so it re-rasterizes too much. Somebody has to implement nsDisplayTreeBody::CreateWebRenderCommands

Is there a way to know what Mac models this issue is solved on? It doesn't look like I'll be able to use TB day-to-day until this issue is resolved. It seems odd that it was working fine before I upgraded to Big Sur, and that was the only change. Something works, just not under Big Sur. :-)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

The problem with the choppy scrolling is that XUL <tree> uses fallback drawing, so it re-rasterizes too much. Somebody has to implement nsDisplayTreeBody::CreateWebRenderCommands

Alex, is this doable as for 91 release? And, the next qn, is will it backport to 78? Or, is folder pane in the same ugly boat as message list - Bug 370437 Comment 31?

Blocks: 1661980
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(alessandro)
Keywords: dupeme

(In reply to Josh from comment #5)

Is there a way to know what Mac models this issue is solved on? It doesn't look like I'll be able to use TB day-to-day until this issue is resolved. It seems odd that it was working fine before I upgraded to Big Sur, and that was the only change. Something works, just not under Big Sur. :-)

Perhaps emilio can answer this.

And, in the interim, whether removing the folder icons might help (copied from a forum posting)...

add this code to your userChrome.css, all folder pane items will be gone.

.tabmail-tab[type="folder"], treechildren::-moz-tree-image(folderNameCol) {
list-style-image: none !important;
}

Flags: needinfo?(emilio)

I don't know how doable it is as I haven't looked at the necessary implementation.
Also, if it's from a pure C++ side of things I'm little to no help.

The folderPanel code changed dramatically since 78, but if it's a XUL <tree> specific issue, I think we can backport it to 78.
I'm mostly speculating, so don't quote me on that.

The problem with the choppy scrolling is that XUL <tree> uses fallback drawing, so it re-rasterizes too much. Somebody has to implement nsDisplayTreeBody::CreateWebRenderCommands

Emilio, do you have any example of such implementation I could look at?

Flags: needinfo?(alessandro)

(In reply to Wayne Mery (:wsmwk) from comment #7)

(In reply to Josh from comment #5)

Is there a way to know what Mac models this issue is solved on? It doesn't look like I'll be able to use TB day-to-day until this issue is resolved. It seems odd that it was working fine before I upgraded to Big Sur, and that was the only change. Something works, just not under Big Sur. :-)

Perhaps emilio can answer this.

I suspect this is likely to be due to WebRender. Does changing gfx.webrender.force-disabled to true help? If it's not it, then we need profiles to see what might be going on.

(In reply to Alessandro Castellani [:aleca] from comment #8)

Emilio, do you have any example of such implementation I could look at?

There are lots, but for this we'd need to re-implement nsTreeBodyFrame::PaintTreeBody in terms of WebRender, which is quite a bespoke piece of painting code.

Flags: needinfo?(emilio)

Hi All - thanks very much for your suggestions. I tried gfx.webrender.force-disabled set to true and separately Wayne's suggestion to add to userChrome.css and didn't see any change. I also tried restarting in Troubleshooting Mode and clearing the cache just to see if that would help and got no change there. I'm not sure about how to get profiles as per Emilio's point.

(In reply to Joshua from comment #3)

Interesting, I have this slow issue too on TB-78 (all versions)
I have just tried TB 90.0b2 and the issue doesn't exist for me (issue also doesn't exist for me on TB 85.0b3 too)

Very odd. I wonder if there is more then one bug/issue with the slow, choppy scrolling in folder pane

I had the issue on Thunderbird release (78.something). I just upgraded to 90.0b4 and I think the problem is somewhat worse for me. Hard to be sure, because it varies depending on window height. But I just tried setting gfx.webrender.all again, and that greatly improves it for me (!), from something like 2fps to maybe 8-15fps.

(In reply to John Hood)

I had the issue on Thunderbird release (78.something). I just upgraded to 90.0b4 and I think the problem is somewhat worse for me. Hard to be sure, because it varies depending on window height. But I just tried setting gfx.webrender.all again, and that greatly improves it for me (!), from something like 2fps to maybe 8-15fps.

Setting gfx.webrender.all had no effect on my machine but making the window smaller was a great tip. Gets back to usability at least.

A question for the developers - this issue did not occur until I upgraded to Big Sur, so the hardware is adequate to the task. It seems like the problem arises because the drawing method being chosen under Big Sur is different from the one chosen under Catalina. Is there any reason that the code couldn't be changed to use the same drawing method as Catalina?

Flags: needinfo?(press)

I have just downloaded and install TB 91.0
I can confirm the issue "Slow, choppy scrolling in folder pane on Mac" no longer exists for me.
I am on macOS 10.15.7 on a 13" MacBook Pro 2013

I can also confirm, I have this issue on all version of TB 78.x
I can also confirm, I don't have this issue on TB 85.0b3 or 90.0b2

So I assume where Tom has linked this issue to TB 91, there may be another reason in some cases where this issue of "Slow, choppy scrolling in folder pane on Mac" also exists for TB 91 ?

Hello - I'm on macOS 11.5.2 with TB 92.0b1, and a 15" Macbook Pro Retina Late 2013, and unfortunately I'm still getting the issue.

(In reply to Joshua from comment #14)

I have just downloaded and install TB 91.0
....
So I assume where Tom has linked this issue to TB 91, there may be another reason in some cases where this issue of "Slow, choppy scrolling in folder pane on Mac" also exists for TB 91 ?

So I assume where Tom has linked this issue to TB 91, ...

This was a mechanical house-keeping change for a few bugs incl this one. If tracking for TB 91 ESR is requested, then the status for TB 91 ESR should be set.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

(In reply to Wayne Mery (:wsmwk) from comment #7)

(In reply to Josh from comment #5)

Is there a way to know what Mac models this issue is solved on? It doesn't look like I'll be able to use TB day-to-day until this issue is resolved. It seems odd that it was working fine before I upgraded to Big Sur, and that was the only change. Something works, just not under Big Sur. :-)

Perhaps emilio can answer this.

I suspect this is likely to be due to WebRender. Does changing gfx.webrender.force-disabled to true help? If it's not it, then we need profiles to see what might be going on.

(In reply to Alessandro Castellani [:aleca] from comment #8)

Emilio, do you have any example of such implementation I could look at?

There are lots, but for this we'd need to re-implement nsTreeBodyFrame::PaintTreeBody in terms of WebRender, which is quite a bespoke piece of painting code.

Do we have an alternative?

FWIW, I think we are past the point of caring about version 78. But if this affects a significant percentage of Mac users (I feel like we don't yet know that), it would be nice to have this resolved before unleashing version 91 on the full user population (or ASAP) .

Blocks: tb91found
Severity: -- → S3
Flags: needinfo?(alessandro)

In my case, the only difference was upgrading to Big Sur. Not trying to be cheeky here but any chance of switching back to the old painting code, at least for older models? It was working without a hitch. :-)

FWIW, I think we are past the point of caring about version 78. But if this affects a significant percentage of Mac users (I feel like we don't yet know that), it would be nice to have this resolved before unleashing version 91 on the full user population (or ASAP) .

The problem is still the same on 91.

This issue is beyond my understanding of the XUL tree and webrenderer, and I'm not even sure if this is something we can even fix on our side or it all comes from m-c.

FYI, bug 1724841 is moving forward, which will finally obliterate every single usage of the XUL tree.

Flags: needinfo?(alessandro)

(v78 bug, removing from found 91)

No longer blocks: tb91found

FYI this bug is in 92.0b3, at least on my machine.

Depends on: tb-deforestation
Flags: needinfo?(press)
OS: Unspecified → macOS

I can confirm it's still in 92b4.

I had the same issue but I'm on 78.13.0 - release channel. Having just found this I tried changing sizes and smaller windows fixes the issue for me. However I also turned off Folder Pane Columns under View->Layouts and that made it dramatically faster, even with a full height windows on a 27" iMac (on Catalina).

(In reply to Paul Hart from comment #24)

I had the same issue but I'm on 78.13.0 - release channel. Having just found this I tried changing sizes and smaller windows fixes the issue for me. However I also turned off Folder Pane Columns under View->Layouts and that made it dramatically faster...

On TB92 it doesn't make any difference. I also had Folder Pane Columns always disabled (didn't even know it exists). Scrolling remains slow and choppy.
macOS 11.5, iMac 2017 27"

Blocks: 1730423

(In reply to Alessandro Castellani [:aleca] from comment #20)

This issue is beyond my understanding of the XUL tree and webrenderer, and I'm not even sure if this is something we can even fix on our side or it all comes from m-c.

FYI, bug 1724841 is moving forward, which will finally obliterate every single usage of the XUL tree.

Is there a bug created yet to to implement the "something better" implementation? (I assume there is some work involved)
Is this also tied to Bug 1729379 - [meta] Implement 3-pane tab in a separate document ?

Flags: needinfo?(alessandro)

We already have the new treelistbox implemented in various areas of the application, like the new address book and the account manager.
Bug 1724841 is keeping track of everything.

Flags: needinfo?(alessandro)

Leo,
We haven't heard from you lately. Does reducing window height or change the gfx preferences help you?

Flags: needinfo?(press)

Some of you came from the slightly older Bug 1677380 - Thunderbird 78.4.x account list / folder pane slow to scroll on MacOS 10.15 - high CPU in FrameLayerBuilder::PaintItems. Not better with HWA disabled. Better with Webrender.

I have summarized from this bug and 1677380 into the User Story. Quite a mashup, as there seems to be inconsistencies between some reports.

bug query: https://mzl.la/3lCnU5k

User Story: (updated)

(In reply to Wayne Mery (:wsmwk) from comment #28)

Leo,
We haven't heard from you lately. Does reducing window height or change the gfx preferences help you?

Thanks Wayne,

I'm on TB 95.0b5. In recent versions, the behavior improved slightly. That is scrolling is a bit faster. But it's just a mild improvement, the bug remains exactly the same.

Reducing window height doesn't make any difference (plus it wouldn't be an acceptable solution anyway).

Just tried gfx.webrender.all > true: doesn't make any difference.

Flags: needinfo?(press)

(In reply to Wayne Mery (:wsmwk) from comment #29)

Some of you came from the slightly older Bug 1677380 - Thunderbird 78.4.x account list / folder pane slow to scroll on MacOS 10.15 - high CPU in FrameLayerBuilder::PaintItems. Not better with HWA disabled. Better with Webrender.

I have summarized from this bug and 1677380 into the User Story. Quite a mashup, as there seems to be inconsistencies between some reports.

bug query: https://mzl.la/3lCnU5k

Thanks Wayne,
I have upgraded to TB 91 and the issues for me have gone (was previously on TB 68.12.0)

Thanks
Joshua

Blocks: 1753479

I don't experience this issue anymore in TB 100.0b3 on Mac Studio M1 Max.

Status update - by my reconning, Paul and Josh are still seeing the problem as of v91.

(In reply to Leo from comment #33)

I don't experience this issue anymore in TB 100.0b3 on Mac Studio M1 Max.

That's quite the beefy machine, so not too suprising it doesn't occur there.

Paul, is your situation also better in version 102?

Flags: needinfo?(pdh)

WFM per reporter

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(pdh)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.