With a large number of tracks, the initial load is very slow

[mstange]

I accidentally captured a profile with 1800 threads. It took a long time before the UI was visible. Here's a profile of the profiler while it was hanging: https://share.firefox.dev/34O2gSO
(I am not sharing the 1800 threads profile.)
I can see the following problems:

• Layout thrashing: For each canvas we add to the timeline, we seem to do a separate layout flush.
• Too many resize listeners: Every canvas has its own window resizing listener.
• Drawing invisible canvases: It would be good to only draw the canvases that are visible.

┆Issue is synchronized with this Jira Task

[julienw]

Once we start virtualizing the track list (3rd point in your list), I believe the 2 first points will be less important.
(but we can still look into them)

[canova]

Reopening this since it's not completely fixed.

[julienw]

Here is a profile with 428 threads, which is already big enough to cause problems: https://share.firefox.dev/3DCfNMr

[julienw]

Unminified profile of "showing all threads" from this profile: https://share.firefox.dev/3dyxfXy

[julienw]

The WithSize component seems to be the biggest culprit.

[julienw]

Also reportTrackHeight is called a lot, which results to a lot of rerenders. When commenting reportTrackHeight, then the profile is all about rendering canvas, which will be improved by @canova's patch using IntersectionObserver.