You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each frame is mostly independent of every other frame, so we could potentially render N frames concurrently by loading the same webpage in N tabs / pages.
This should be viewed as a perf experiment and optional toggle since it's performance will likely depend on the number of underlying CPUs, memory, and other platform considerations.
The only real change we'll have to be careful with in the implementation is our use of image2pipe for piping individual frames into ffmpeg when rendering mp4 outputs. Since the frames won't necessarily be rendered in order anymore, we'll need to either:
A) write these temp frames out to disk like we do for the gif renderer
or
B) buffer the frame images in memory and pipe them out only once all preceding frames have been piped
I'm leaning towards option B since it'll likely be more efficient but am open to other thoughts / feedback as well.
The text was updated successfully, but these errors were encountered:
@transitive-bullshit I don't know very well puppeteer or it's capabilities, but you could also load the same animation multiple times in the same page and render different frames on each instance.
They would be using the same thread, but only using a single instance of puppeteer.
Also, someone has been experimenting with Offscreen Canvas and lottie, which could run each animation in a separate thread. airbnb/lottie-web#1602
Only problem is that it would only support the canvas renderer.
Hope this helps.
Each frame is mostly independent of every other frame, so we could potentially render
N
frames concurrently by loading the same webpage inN
tabs / pages.This should be viewed as a perf experiment and optional toggle since it's performance will likely depend on the number of underlying CPUs, memory, and other platform considerations.
The only real change we'll have to be careful with in the implementation is our use of
image2pipe
for piping individual frames intoffmpeg
when renderingmp4
outputs. Since the frames won't necessarily be rendered in order anymore, we'll need to either:A) write these temp frames out to disk like we do for the gif renderer
or
B) buffer the frame images in memory and pipe them out only once all preceding frames have been piped
I'm leaning towards option B since it'll likely be more efficient but am open to other thoughts / feedback as well.
The text was updated successfully, but these errors were encountered: