joeytwiddle
commented
4 years ago Which dweets to animate
We may want to decide between two goals:
A. All visible dweets should be animating (provided they are fully onscreen)
B. Only one visible dweet should be animating (this would maximize framerate, pretty important for slower machines)
I have been leaning towards B. This active dweet could be the one nearest the middle of the screen. But then with many dweets on screen, we may need to tweak the rules to animate the first and last few dweets in a feed.
Note: On desktop, the user can always control the number of dweets visible at one time by zooming. But most mobile browsers don't offer a convenient zoom setting (even Accessibility settings are limited).
Blue-sky
C. We could circumvent much of the complexity above, by presenting dweets as a sort of slide-show. There would only ever be one dweet visible.
For possible UIs, consider YouTube, or how Twitter/Facebook/Instagram navigate through a set of images (and their comments). Consider also the pros/cons of the Dweetabase.
I love the snappiness of the current beta, but I wonder if we can keep that, but also keep some offscreen dweets. My real wishes (numbered to assist discussion, emphasis for clarity not because I'm angry which I am not):
The four dweets above the current dweet could remain in memory, but be paused, when they go offscreen.
Motivation: If we scroll back up, they we can see the earlier dweets resume playback where they left off. This will make the site feel more seamless, and would let us resume slow renders while we go to make coffee.
When a dweet is far enough offscreen (five or more offscreen) then we can unload them as the beta does now, to save memory. I think this would be a nice compromise between the old and current systems.
Similarly, the next dweet ahead of this one could be preloaded (1 frame), before it scrolls into view.
Motivation: The startup of a dweet can be a little slow. It would be good to have this done before the dweet comes into view. (Yes, even if it causes a few dropped frames on the currently visible dweet! I think it's worth it.) Old dwitter did this, but for 10 iframes, which was a bit heavy. I think we should do it, but just for one.
Motivation: It's not ideal to see a black canvas while scrolling down, which then flicks into white when the dweet actually starts.✻ It would be elegant to have the first frame already rendered, for a smooth transition.
✻ (We could change the CSS to white, but then we'll just get the same problem with black-background dweets.)
Caveat: The dweet should not actually start playing until the full canvas is in view. So the user won't miss any parts of the first few frames because they happened out of the viewport.
When scrolling back up, I think we could use the same policy as 1. Pause offscreen dweets below the viewport, but don't unload them too early. Keep at least 4.
Obviously this proposal could mean up to 9 iframes will be loaded in memory at any moment. (But usually 6, when scrolling down.)
I feel that might be a nice compromise between the current beta (max 1 active iframe) and the original dwitter (10 × n iframes, where n keeps increasing). But we can experiment with the ideal balance for the numbers. (Perhaps even tweak them for different devices.)