🧠 Perceptual Engine: Un motor de renderizado que predice el movimiento del usuario
La mayoría de las librerías de virtualización optimizan el número de nodos en el DOM.
Yo me empecé a preguntar:
¿Y si el problema real no es el tamaño del DOM… sino la percepción humana?
Esa pregunta se convirtió en Perceptual Engine, un runtime de renderizado experimental para React centrado en la fluidez percibida, el desplazamiento predictivo, la calidad adaptativa y el renderizado consciente de la GPU.
No se trata de "renderizar menos nodos".
Se trata de renderizar lo que el usuario está a punto de necesitar.
El problema que no se abordó realmente
Las librerías tradicionales de desplazamiento virtual son geométricas.
Calculan la visibilidad así:
scrollTop → índices visibles → renderizar
Eso funciona… hasta que fuerzas la UI al límite:
Formularios complejos
WebViews de Android
Inputs con teclados IME
Cálculos en tiempo real
Layouts dinámicos grandes
Desplazamiento rápido con flick
Ahí las cosas empiezan a fallar:
Parpadeos
Pérdida de foco
Tirones en el scroll
Caída de frames
Rotación excesiva de portales
Destrucción de estado
Me topé con todo esto construyendo un sistema TPV que corre dentro de un WebView de Android.
Y las soluciones existentes no estaban diseñadas para ese entorno.
Lo que construí
Perceptual Engine trata el desplazamiento como un problema de predicción de movimiento.
En lugar de reaccionar solo a la posición del scroll, el motor analiza continuamente:
velocidad
aceleración
sobreaceleración (cambio en la aceleración)
distancia de frenado prevista
presión de renderizado
presupuesto de frames
uso de capas de GPU
Pipeline:
ENTRADA ↓ ANÁLISIS DE MOVIMIENTO ↓ PREDICCIÓN ↓ VISIBILIDAD ↓ MEDICIÓN ↓ MUTACIÓN DEL DOM ↓ COMPOSICIÓN EN GPU
Cada etapa puede:
dividir el trabajo entre frames
cancelarse a sí misma
degradar la calidad
repriorizar tareas
Se comporta más como un pequeño motor de videojuegos que como una lista tradicional de React.
Ideas centrales
- Overscan basado en movimiento
En lugar de un overscan fijo:
overscan={5}
El motor predice hacia dónde se mueve el usuario usando la sobreaceleración y la velocidad.
Los desplazamientos rápidos aumentan automáticamente el renderizado predictivo.
Los movimientos lentos reducen el trabajo automáticamente.
- Sistema de calidad adaptativa
Si los FPS bajan:
el overscan se reduce
las capas de GPU disminuyen
las predicciones se simplifican
las mediciones costosas se posponen
Muy similar a los sistemas de calidad adaptativa usados en motores de videojuegos.
- Pool de DOM persistente
En lugar de montar/desmontar constantemente:
los nodos del DOM se mantienen vivos
los elementos se reciclan a través de pools
los portales inyectan contenido incrementalmente
el estado sobrevive al desplazamiento
Esto fue crítico para formularios complejos y teclados de Android.
- Planificador con presupuesto de frames
El planificador usa:
prioridades
división de tiempo (time slicing)
lógica anti-inanición
presupuestos de frames
No todo el trabajo de renderizado merece la misma urgencia.
API sencilla
import { PerceptualList } from 'perceptual-engine';
function ProductForms({ products }) {
return (
<PerceptualList
items={products}
estimatedItemSize={600}
overscan="auto"
enableGPUCompositing
persistenceKey="product-forms"
renderItem={(product) => (
<ProductForm product={product} />
)}
/>
);
}
El motor se encarga de:
overscan predictivo
reciclaje de DOM
restauración del scroll
degradación adaptativa
composición en GPU
planificación
agrupación de mediciones
Caso de uso real en producción
Actualmente uso Perceptual Engine en producción dentro de un sistema TPV en WebView de Android.
Escenario:
15 formularios complejos simultáneos
Cálculos en tiempo real
Inputs numéricos
Validación
Totales dinámicos
Alta interacción
Hardware Android de gama baja
Con virtualización tradicional:
pérdida de foco
parpadeo con IME
estado que desaparece
desplazamiento inestable
Con Perceptual Engine:
desplazamiento estable a 60fps
interacción persistente
cero parpadeos
sin destrucción de foco
Ese entorno moldeó toda la arquitectura.
Arquitectura
React
↓
PerceptualList
↓
usePerceptualEngine
↓
PerceptualEngine
├── MotionAnalyzer
├── LayoutPredictor
├── ViewportManager
├── RecyclingPool
├── CompositorLayer
├── Scheduler
└── ScrollRestoration
Qué lo hace diferente
La mayoría de librerías de virtualización optimizan:
memoria
número de nodos en el DOM
matemáticas de visibilidad
Perceptual Engine optimiza:
fluidez percibida
continuidad de la interacción
predicción de movimiento
estabilidad de frames
presión sobre la GPU
Es una filosofía muy diferente.
Estado actual
El motor está actualmente en alfa avanzada.
Funcionando hoy:
✅ Overscan adaptativo
✅ Pools de reciclaje de DOM
✅ Caché incremental de portales
✅ Restauración de scroll multiestrategia
✅ Degradación consciente de los FPS
✅ Agrupación compartida de ResizeObserver
✅ Overlay de rendimiento
✅ Controles de composición en GPU
Hoja de ruta:
🔜 Publicación en npm
🔜 Benchmarks
🔜 Renderizado sin portales
🔜 Capa de preservación de foco
🔜 Planificación basada en workers
🔜 Suite de tests completa
Limitaciones conocidas
Los portales de React aún introducen sobrecarga a escalas extremas
Los WebViews de Android antiguos pueden comportarse de forma inconsistente
La API aún está evolucionando antes del lanzamiento en npm
La documentación sigue en progreso
Filosofía
No estoy intentando construir "otra librería de virtualización".
Estoy explorando cómo podría ser el renderizado si tratáramos el desplazamiento como una señal perceptiva en lugar de un problema geométrico.
Los usuarios no experimentan:
"índices visibles"
Los usuarios experimentan:
fluidez, continuidad y capacidad de respuesta.
Eso cambia la arquitectura por completo.
Buscando feedback
Me encantaría recibir feedback de gente que trabaje con:
WebViews de Android
formularios complejos
conjuntos de datos enormes
casos límite de virtualización
hardware de gama baja
infraestructura de renderizado
Especialmente si se han topado con limitaciones en soluciones existentes.
GitHub
github.com/fouzstack/perceptual-engine
Lanzamiento en npm próximamente.
¿Qué opinas?
¿Es el renderizado predictivo el siguiente paso después de la virtualización?
