https://github.com/alexfigliolia/frame-pooler

A task manager for distributing callbacks between animation frames
https://github.com/alexfigliolia/frame-pooler

animation scheduling task-manager typescript

Last synced: 10 days ago
JSON representation

A task manager for distributing callbacks between animation frames

• Host: GitHub
• URL: https://github.com/alexfigliolia/frame-pooler
• Owner: alexfigliolia
• Created: 2024-07-08T01:10:12.000Z (5 months ago)
• Default Branch: main
• Last Pushed: 2024-08-08T21:20:28.000Z (3 months ago)
• Last Synced: 2024-08-09T22:35:00.258Z (3 months ago)
• Topics: animation, scheduling, task-manager, typescript
• Language: JavaScript
• Homepage: https://www.npmjs.com/package/@figliolia/frame-pooler
• Size: 96.7 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Frame Pooler

A task queue for distributing callbacks into animation frames. The Frame Pooler will allow you to run sequential tasks and automatically handle task distribution based on a maximum frame-duration and callstack size.

This library is primarily designed for heavy DOM manipulation and/or animation.

## Installation

```bash

npm i @figliolia/frame-pooler

# or

yarn add @figliolia/frame-pooler

```

## Basic Usage

```typescript

import { FramePooler } from "@figliolia/frame-pooler";

const Pooler = new FramePooler(

  100 

  /* max call stack size per frame (defaults to Infinity) */

);

Pooler.run((time: number) => {

  // heavy DOM reads or updates

});

```

### Background

When building an animation-intensive JavaScript library I found myself benchmarking the performance of concurrent calls to `requestAnimationFrame` vs. pooling callbacks into already open animation frames. 

Due to the fact that logic executed inside of `requestAnimationFrame` can itself take any duration, I landed upon a game loop-like solution for my library - where an animation loop would remain running as long as tasks were pending. And if a given set of tasks exceeded a safe duration for a single frame, the frame will close with remaining tasks executing in the next available frame.

Thus allowing for the best possible frame rate the end-user's device could handle while still receiving user-input.