🧠 Perceptual Engine — A Rendering Engine That Predicts User Movement
Most virtualization libraries optimize DOM count.
I started wondering:
«What if the real problem is not DOM size… but human perception?»
That question became Perceptual Engine — an experimental rendering runtime for React focused on perceived smoothness, predictive scrolling, adaptive quality, and GPU-aware rendering.
Not “render fewer nodes”.
Render what the user is about to need.
The Problem Nobody Really Solved
Traditional virtual scrolling libraries are geometric.
They calculate visibility like this:
scrollTop → visible indexes → render
That works… until you push the UI hard:
- Complex forms
- Android WebViews
- Inputs with IME keyboards
- Real-time calculations
- Large dynamic layouts
- Fast flick scrolling
Then things start breaking:
- Flicker
- Lost focus
- Scroll jitter
- Frame drops
- Portal churn
- State destruction
I hit all of this while building a POS system running inside Android WebView.
And existing solutions weren’t designed for that environment.
What I Built
Perceptual Engine treats scrolling as a motion prediction problem.
Instead of reacting to scroll position only, the engine continuously analyzes:
- velocity
- acceleration
- jerk (change in acceleration)
- predicted stopping distance
- rendering pressure
- frame budget
- GPU layer usage
Pipeline:
INPUT
↓
MOTION ANALYSIS
↓
PREDICTION
↓
VISIBILITY
↓
MEASUREMENT
↓
DOM MUTATION
↓
GPU COMPOSITING
Each stage can:
- split work across frames
- cancel itself
- degrade quality
- reprioritize tasks
It behaves more like a small game engine than a traditional React list.
Core Ideas
- Motion-Based Overscan
Instead of fixed overscan:
overscan={5}
The engine predicts where the user is moving next using jerk + velocity.
Fast flicks increase predictive rendering automatically.
Slow movement reduces work automatically.
- Adaptive Quality System
If FPS drops:
- overscan shrinks
- GPU layers reduce
- predictions simplify
- expensive measurements defer
Very similar to adaptive quality systems used in game engines.
- Persistent DOM Pool
Instead of constantly mounting/unmounting:
- DOM nodes stay alive
- elements recycle through pools
- portals inject content incrementally
- state survives scrolling
This was critical for complex forms and Android keyboards.
- Scheduler With Frame Budgeting
The scheduler uses:
- priorities
- time slicing
- anti-starvation logic
- frame budgets
Not all rendering work deserves the same urgency.
Simple API
import { PerceptualList } from 'perceptual-engine';
function ProductForms({ products }) {
return (
items={products}
estimatedItemSize={600}
overscan="auto"
enableGPUCompositing
persistenceKey="product-forms"
renderItem={(product) => (
)}
/>
);
}
The engine handles:
- predictive overscan
- DOM recycling
- scroll restoration
- adaptive degradation
- GPU compositing
- scheduling
- measurement batching
Real Production Use Case
I’m currently using Perceptual Engine in production inside an Android WebView POS system.
Scenario:
- 15 simultaneous complex forms
- Real-time calculations
- Numeric inputs
- Validation
- Dynamic totals
- Heavy interaction
- Low-end Android hardware
With traditional virtualization:
- focus loss
- IME flicker
- disappearing state
- unstable scrolling
With Perceptual Engine:
- stable 60fps scrolling
- persistent interaction
- zero flicker
- no focus destruction
That environment shaped the entire architecture.
Architecture
React
↓
PerceptualList
↓
usePerceptualEngine
↓
PerceptualEngine
├── MotionAnalyzer
├── LayoutPredictor
├── ViewportManager
├── RecyclingPool
├── CompositorLayer
├── Scheduler
└── ScrollRestoration
What Makes It Different
Most virtualization libraries optimize:
- memory
- DOM count
- visibility math
Perceptual Engine optimizes:
- perceived smoothness
- interaction continuity
- motion prediction
- frame stability
- GPU pressure
That’s a very different philosophy.
Current Status
The engine is currently in advanced alpha.
Working today:
- ✅ Adaptive overscan
- ✅ DOM recycling pools
- ✅ Incremental portal caching
- ✅ Multi-strategy scroll restoration
- ✅ FPS-aware degradation
- ✅ Shared ResizeObserver batching
- ✅ Performance overlay
- ✅ GPU compositing controls
Roadmap:
- 🔜 npm release
- 🔜 benchmarks
- 🔜 portal-less rendering
- 🔜 focus preservation layer
- 🔜 worker-based scheduling
- 🔜 full test suite
Known Limitations
- React portals still introduce overhead at extreme scales
- Legacy Android WebViews can behave inconsistently
- API still evolving before npm release
- Documentation still in progress
Philosophy
I’m not trying to build “another virtualization library”.
I’m exploring what rendering could look like if we treated scrolling as a perceptual signal instead of a geometry problem.
Users don’t experience:
«“visible indexes”»
Users experience:
«smoothness, continuity, and responsiveness.»
That changes the architecture completely.
Looking for Feedback
I’d love feedback from people working with:
- Android WebViews
- complex forms
- huge datasets
- virtualization edge cases
- low-end hardware
- rendering infrastructure
Especially if you’ve hit limitations with existing solutions.
GitHub
github.com/fouzstack/perceptual-engine
npm release coming soon.
What do you think?
Is predictive rendering the next step after virtualization?
Top comments (0)