Small tweaks to making scrolling smoother

[samsonjs]

This has 2 changes to improve scrolling a tiny bit:

• Reserve a fixed number of lines for text in web cards, and reduce the title to 2 lines so it doesn't look terrible when there's only one line. This is a step backwards for aesthetics and maybe it's not a good trade-off for you. I think it's worth it but it's subjective.

• Use drawingGroup to rasterize and cache expensive text views. I added it on all of them in the whole row but maybe it should be a bit more targeted and only on the status body.

Measuring

Measuring these in the hitches instrument consistently shows a reduction in the max hitch time by a few milliseconds on a 14 Pro so I think they're sound optimizations, not for reducing hitches but making them a bit less severe. I should measure on an older device here too and see if the drawing group is still faster. (update: measured on a 2018 iPad Pro and don't see any difference there so maybe this doesn't even improve anything)

Because the gains are so small though it's hard to know for sure whether drawingGroup helps all that much. When measuring, it's always on a different set of posts and you can't scroll the exact same way each run so it's not very scientific but I tried to choose a similar 5s sample for comparisons and got consistently better results.

Other observations

I tried removing everything except the status text and a few other things and there are still hitches and lots of primitive button configuration updates in the SwiftUI list. It seems impossible to eliminate them entirely with such a large view so making them shorter might be the only way to improve things without a big refactor. At least not with my optimization skills!

[Dimillian]

Not a fan of drawingGroup, it create issues with animated emojis etc... and I'm not sure the tradeoff is worth it. I'm putting this on hold, I'll resume the work on optimisations and probably look more into why some of the stuff, like context menu take time to draw.

[Dimillian]

You can look at: https://github.com/Dimillian/IceCubesApp/commit/a52f0f9fbe56d886a8bf41e2793547ff8818365a Basically AvatarView processors from Nuke were useless as we're already doing the clipping in SwiftUI, that saved a lot of rendering time on AvatarView. The second thing is an optimisation I've started yesterday, but forgot one menu. In the StatusRow we have the same context menu 3 times, for the accessibility one, the ... button and the actual long press context menu. Now they all share the same view.

Same as you, hard to debunk but Instruments show that less time is spent drawing those views.

[Dimillian]

Your PR:

Main:

[Dimillian]

Definitely can see it faster on this PR? But also could be just one "bad" status in my sample :/ But again, .drawingGroup create many side effect that I'm not sure I want to ship.

[Dimillian]

More data:

This PR

Main:

[Dimillian]

This last one is very very similar in the end.

[samsonjs]

Yeah I think it's inconclusive at best so far. I can revert the drawing group changes and see if the other change makes a difference on its own. I should be able to make some mock data to test it more reliably.