DEV Community: Prashant Piprotar

AetherScan: Building a Real-Time 3D Reconstruction App with Fast3R, WebSockets, and React Three Fiber

Prashant Piprotar — Thu, 30 Jul 2026 10:50:55 +0000

The Problem

You've got a bunch of photos of an object taken from different angles. You want a 3D model. Most tools make you upload images, wait, download a file, then open it in a separate viewer.

I wanted something better — drop your images in a browser and watch the 3D point cloud build in front of you, in real time.

That's AetherScan.

What It Does

Drag & drop images into the web UI
Images are streamed to the backend via WebSocket
Fast3R (Facebook Research's neural 3D reconstruction model) runs GPU inference
Reconstructed 3D points stream back to the browser in real-time
The point cloud renders live at 60fps using React Three Fiber
Export the result as a .PLY file

No page reloads. No file downloads mid-process. Just upload → watch → export.

Architecture

┌──────────────────────────────┐          ┌───────────────────────────────┐
│       Next.js Frontend       │          │       FastAPI Backend         │
│                              │          │                              │
│  DropZone ──► FileReader     │          │  WebSocket Endpoint          │
│              │               │          │      │                       │
│         base64 chunks        │◄──WS───►│  Decode & Save to /tmp       │
│              │               │          │      │                       │
│  usePointStream Hook ◄───────│          │  Fast3R (PyTorch/CUDA)       │
│      │                       │          │      │                       │
│  React Three Fiber Canvas    │          │  Stream points back          │
│      │                       │          │                              │
│  Live 3D Point Cloud         │          │                              │
└──────────────────────────────┘          └───────────────────────────────┘

The entire pipeline is bidirectional over a single WebSocket — no REST calls for the heavy lifting.

Tech Stack

Layer	Tech
Frontend	Next.js 15, React 19, React Three Fiber, Tailwind CSS
Backend	FastAPI, PyTorch, Fast3R (ViT-Large), CUDA
Transport	WebSocket (binary-friendly JSON streaming)
Infra	Docker Compose with NVIDIA GPU passthrough

The Interesting Engineering Bits

1. Streaming Points Over WebSocket

The backend doesn't wait for the full reconstruction to finish. As soon as points are computed, they're streamed in chunks of 100:

# backend/main.py
chunk_size = 100
for i in range(0, len(points), chunk_size):
    chunk = points[i:i+chunk_size]
    await websocket.send_json({
        "type": "points",
        "data": chunk
    })
    await asyncio.sleep(0.01)  # backpressure

This gives the user instant visual feedback — points start appearing within seconds, even for large reconstructions.

2. Zero-Re-render Point Cloud Updates

Normally, React re-renders the entire component tree when state changes. With 100K+ points arriving in rapid chunks, that would be a disaster.

The usePointStream hook bypasses React's state entirely:

// frontend/hooks/usePointStream.ts
const positionsRef = useRef<Float32Array>(new Float32Array(maxPoints * 3));
const colorsRef    = useRef<Float32Array>(new Float32Array(maxPoints * 3));

const addPoints = useCallback((points: PointData[]) => {
    const positions = positionsRef.current;
    for (const point of points) {
        const idx = currentCount * 3;
        positions[idx]     = point.x;
        positions[idx + 1] = point.y;
        positions[idx + 2] = point.z;
        currentCount++;
    }

    // Update GPU buffer directly — no setState
    positionAttributeRef.current.needsUpdate = true;
    geometryRef.current.setDrawRange(0, currentCount);
}, []);

Key decisions:

Float32Array in refs, not state — no re-renders
DynamicDrawUsage tells Three.js the buffer will change often
setDrawRange incrementally reveals points without re-uploading the entire buffer
Direct needsUpdate flag pushes data to the GPU

The result: 1M+ points at 60fps with zero React re-render overhead.

3. Fast3R Inference with Dynamic Resolution

Consumer GPUs have limited VRAM. The backend dynamically adjusts the input resolution based on image count to prevent CUDA OOM:

# backend/services/reconstruction.py
if num_images <= 3:
    img_size = 512
elif num_images <= 6:
    img_size = 384
else:
    img_size = 256

It also uses mixed precision (float16) on CUDA for 2x memory savings:

precision = "16-mixed" if self.device == "cuda" else "32"

4. Eager Model Loading at Startup

The Fast3R ViT-Large model is ~1.8 GB. Instead of lazy-loading on the first request (and making the user wait), the model loads eagerly at server startup:

@app.on_event("startup")
async def startup_event():
    service = get_reconstruction_service()
    await loop.run_in_executor(None, service.initialize)

A /status endpoint returns 503 until the model is ready, so health checks and load balancers know when the service can accept traffic.

5. Client-Side PLY Export

The export happens entirely in the browser — no round-trip to the server:

const header = `ply
format ascii 1.0
element vertex ${points.length}
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
end_header
`;

const blob = new Blob([header + vertices], { type: 'text/plain' });

The user gets a standard .PLY file compatible with MeshLab, Blender, CloudCompare, and other 3D tools.

Running It Yourself

Docker (Recommended)

git clone https://github.com/prashplus/AetherScan.git
cd AetherScan
docker-compose up

Requires NVIDIA GPU + NVIDIA Container Toolkit.

Frontend: http://localhost:3000
Backend API: http://localhost:8000
Swagger Docs: http://localhost:8000/docs

Local Development

# Backend (Python 3.11 + conda)
conda create -n aether python=3.11
conda activate aether
cd backend && pip install -r requirements.txt
git clone --recursive https://github.com/facebookresearch/fast3r.git ../fast3r
pip install -e ../fast3r
uvicorn main:app --reload --host 0.0.0.0 --port 8000

# Frontend
cd frontend && npm install && npm run dev

Apple Silicon Support

The backend auto-detects the best available device. On a Mac with Apple Silicon, it falls back to MPS:

def get_best_device() -> str:
    if torch.cuda.is_available():
        return "cuda"
    if torch.backends.mps.is_available():
        return "mps"
    return "cpu"

Lessons Learned

WebSocket > REST for streaming workloads. Chunked HTTP responses work, but WebSockets give you true bidirectional communication — the client can send images and receive points on the same connection.
Bypass React for hot data paths. React's reconciliation is great for UI state. For high-throughput data like point clouds, write directly to GPU buffers via refs.
Eager model loading pays off. A 30-second startup delay is much better than a 30-second hang on the first user request. Health checks and readiness probes make this safe in production.
Dynamic resolution prevents OOM. Instead of failing with a CUDA out-of-memory error, scale down input resolution based on the workload. Users get results at slightly lower fidelity rather than a crash.
Ship a working fallback. If the ML model fails to load (no GPU, no internet for weights), the system falls back to demo points. The UI never breaks.

What's Next

Binary WebSocket frames — switch from JSON to raw Float32Array over binary frames for 5-10x bandwidth reduction
Level-of-Detail (LOD) — progressive point cloud rendering for very large scenes
Multi-object support — segment and reconstruct individual objects from a scene
Mesh generation — go from point clouds to textured meshes using Poisson surface reconstruction

From Drone Video to 3D Maps: Automate WebODM Setup with GPU Acceleration

Prashant Piprotar — Thu, 30 Jul 2026 10:43:40 +0000

The Problem: Drone Mapping Shouldn't Be This Hard

You've got a drone. You've captured stunning aerial footage. Now you want to turn those videos into orthophoto maps, 3D models, or point clouds — and you hit a wall.

Setting up WebODM (the open-source drone mapping platform built on OpenDroneMap) involves juggling Docker Compose files, configuring processing nodes, extracting frames from video, and — if you want any reasonable speed — wiring up GPU acceleration. Each step has its own pitfalls across Windows, Linux, and macOS (including Apple Silicon).

I built WebODM-Setup to solve this. One repo. One command. Full pipeline from raw drone video to finished map.

What This Repo Does

At its core, the toolkit automates the entire drone-mapping workflow:

Capture Video → Extract Frames → Upload to WebODM → Process → Export

Here's what's inside:

One-command install scripts for Windows (PowerShell), Linux (Bash), and macOS (including native Apple Silicon support)
Docker Compose configs that wire up the full WebODM stack — webapp, worker, NodeODM processing node, PostGIS database, and Redis broker
GPU acceleration out of the box (NVIDIA GPUs via the nodeodm:gpu Docker image)
Video processing scripts — extract frames at configurable FPS with GPS metadata preservation
Batch processing for multi-video workflows

Quick Start (Under 5 Minutes)

Prerequisites

Docker Desktop (Windows/macOS) or Docker Engine (Linux)
Python 3.8+
Git

Linux / macOS

git clone https://github.com/prashplus/WebODM-Setup.git
cd WebODM-Setup
chmod +x scripts/*.sh
./scripts/install-linux.sh
./scripts/start-webodm.sh

Windows (PowerShell)

git clone https://github.com/prashplus/WebODM-Setup.git
cd WebODM-Setup
.\scripts\install-windows.ps1
.\scripts\start-webodm.ps1

Open http://localhost:8000 — done.

Apple Silicon users: The scripts auto-detect M1/M2/M3/M4 and use the correct arm64-native, CPU-only Docker images. No extra config needed.

The Architecture

The docker-compose.yml spins up five services:

Service	Image	Role
webapp	`opendronemap/webodm_webapp`	Web UI + API (port 8000)
worker	`opendronemap/webodm_webapp`	Celery task worker
node-odm-1	`opendronemap/nodeodm:gpu`	Photogrammetry engine (port 3000)
db	`postgis/postgis:14-3.3`	PostGIS database
broker	`redis:7`	Task queue

A node-register init container auto-registers the processing node with the webapp on first boot — no manual setup.

GPU Acceleration: The Speed Multiplier

This is where things get exciting. By default, the compose file uses the nodeodm:gpu image with NVIDIA GPU reservation:

node-odm-1:
  image: opendronemap/nodeodm:gpu
  environment:
    - GPU_ENABLED=true
  deploy:
    resources:
      reservations:
        devices:
          - driver: nvidia
            count: 1
            capabilities: [gpu]

Real-World Performance (200 images, 20MP)

Configuration	Processing Time
CPU only (8 cores)	~2–4 hours
GPU (RTX 4060, 8GB VRAM)	~30–60 minutes

That's a 2–5x speedup across the photogrammetry pipeline — Structure from Motion, Multi-View Stereo, meshing, and texturing all benefit.

Requirements

NVIDIA GPU with CUDA 11.0+ and 4GB+ VRAM
NVIDIA Container Toolkit installed
On Windows: WSL2 backend with GPU passthrough enabled

If you don't have an NVIDIA GPU, just swap the image to opendronemap/nodeodm:latest and remove the deploy section — everything works on CPU.

From Video to Map: The Processing Pipeline

Most consumer drones record video, not individual photos. The repo includes Python scripts to bridge that gap.

Extract Frames

# 1 frame per second, JPEG quality 95
python scripts/extract-frames.py \
  --input DJI_0001.MP4 \
  --output ./frames/project1 \
  --fps 1 \
  --quality 95

# With GPS metadata extraction
python scripts/extract-frames.py \
  --input DJI_0001.MP4 \
  --output ./frames/project1 \
  --fps 2 \
  --extract-gps

Batch Process Multiple Videos

python scripts/batch-process.py \
  --input-dir ./videos \
  --output-dir ./frames \
  --fps 1

Choosing the Right FPS

Flight Speed	Recommended FPS	~Frames per 5-min Video
Slow (2–3 m/s)	0.5–1	150–300
Normal (4–5 m/s)	1–2	300–600
Fast (6+ m/s)	2–3	600–900

The key is overlap — consecutive frames need 70–80% overlap for the photogrammetry algorithms to work.

Processing Presets

Once frames are uploaded to WebODM, choose a preset based on your needs:

Preset	Time (200 imgs, 8C/16GB)	Use Case
Fast	~15 min	Quick previews, data validation
Default	~1.5 hours	Most projects
High Quality	~4 hours	Professional deliverables, detailed 3D
Ultra	8+ hours	Maximum detail, heritage documentation

Output Formats

Orthophoto (GeoTIFF) — georeferenced 2D map
3D Model (OBJ/PLY) — textured mesh
Point Cloud (PLY/LAS) — colored XYZ data
DEM (GeoTIFF) — elevation/terrain model
Contours (GeoJSON) — elevation contour lines

Real-World Use Cases

The workflow documentation covers four common scenarios:

Agriculture Mapping — Grid pattern at 100m, orthophoto export for NDVI analysis
Construction Site Surveys — DEM + orthophoto for volume calculations
Building/Monument 3D Models — Circular flight pattern, high-quality 3D mesh export
Infrastructure Inspection — Multi-angle capture, detailed textured model

Project Structure

WebODM-Setup/
├── scripts/
│   ├── install-windows.ps1 / install-linux.sh
│   ├── start-webodm.ps1 / start-webodm.sh
│   ├── stop-webodm.ps1 / stop-webodm.sh
│   ├── update-webodm.ps1 / update-webodm.sh
│   ├── extract-frames.py
│   ├── batch-process.py
│   └── common.sh
├── config/
│   ├── webodm-config.env
│   └── processing-presets.json
├── docker-compose.yml                # GPU-enabled (Linux/Windows)
├── docker-compose.apple-silicon.yml  # Apple Silicon (arm64, CPU-only)
├── requirements.txt
├── GPU_SETUP.md
├── MACOS_APPLE_SILICON.md
├── WORKFLOW.md
└── README.md

Tips & Gotchas

Docker memory: Bump to 8GB+ in Docker Desktop settings. Processing large datasets with the default 2GB will crash.
Port conflicts: If port 8000 is taken, edit config/webodm-config.env and set WO_PORT=8080.
GPU monitoring: Run watch -n 2 nvidia-smi (Linux) or a looping nvidia-smi (Windows PowerShell) to monitor utilization during processing.
FFmpeg: Required for the frame extraction scripts. Install via brew install ffmpeg, apt install ffmpeg, or choco install ffmpeg.
Image quality matters: Blurry, overexposed, or sky-only frames will degrade results. Curate your frame set before uploading.

Contributing

The project is MIT-licensed and welcomes contributions. Fork, branch, PR — the standard flow:

git checkout -b feature/your-feature
git commit -m "Add your feature"
git push origin feature/your-feature

I Built a Cross-Platform Browser Benchmark That Stress Tests Any Device — Here's How

Prashant Piprotar — Thu, 30 Jul 2026 10:26:02 +0000

No installs. No native apps. Just open a URL and push your MacBook, PC, Android, or iPhone to its limits.

We've all been there. You get a shiny new device — a MacBook Pro with an M4 chip, a Galaxy S25, or a gaming PC with the latest GPU — and the first thing you want to do is see what it can really do.

The problem? Most benchmark tools are platform-locked native apps. Geekbench costs money. 3DMark is Windows-only. AnTuTu is mobile-only. And none of them let you compare your MacBook against your phone with the same test suite.

So I built WebStress — an open-source, browser-based benchmark suite that runs on literally anything with a modern browser. No installs, no accounts, no app store. Just open a URL.

Here's what I learned building it, and how you can use (or fork) it yourself.

Why a Browser-Based Benchmark?

Browsers have become absurdly powerful. WebGL gives us GPU access. Web Workers enable multi-threaded CPU tests. TypedArrays let us do real number-crunching. The browser is no longer just a document viewer — it's a compute platform.

A browser benchmark has one killer advantage: true cross-platform parity. The exact same JavaScript code runs on your M4 MacBook, your Windows gaming rig, your Android phone, and your iPhone. Same tests, same scoring, genuinely comparable results.

What It Tests

WebStress runs 32 individual sub-tests across 6 categories. Let me break down what each one actually measures and why it matters.

🧠 CPU — The Brain

The CPU benchmark isn't just "loop a billion times and see how fast it goes." It targets specific computational patterns:

Integer Arithmetic — Bitwise operations, XOR chains, and integer multiplication. This is your chip's bread and butter for general-purpose computing.
Floating Point — Trigonometric functions (sin, cos, atan2), square roots, logarithms. Critical for scientific computing, audio processing, and physics simulations.
Hash / Crypto — FNV-1a hashing over 1KB buffers. Simulates real-world hashing workloads like integrity checks and password processing.
Array Sort — Sorting 10,000-element Float64 arrays. Tests branch prediction, cache efficiency, and the JS engine's sort implementation.
Prime Sieve — Classic trial division up to 500K. Pure integer ALU throughput with branching.
Matrix Multiply — 64×64 double-precision matrix multiplication. The fundamental operation behind machine learning, graphics, and scientific computing.
Multi-Core Scaling — Spawns Web Workers equal to your core count, all running the integer test simultaneously. Measures how well your chip scales under parallel load and how efficiently the browser manages threads.

The multi-core test is particularly interesting. Apple's M-series chips show very different scaling behavior from Intel/AMD due to their efficiency/performance core architecture. You can literally watch it in the results.

🎮 GPU — The Graphics Muscle

These tests use WebGL shaders — actual GPU programs running on your graphics hardware:

Fill Rate — How many full-screen quads the GPU can paint per second. Raw pixel throughput.
Fragment Shader — A complex procedural shader with trigonometric wave functions. Tests the GPU's shader unit compute performance — the same units that process every pixel in games.
Geometry Throughput — Renders 5,000 animated triangles. Measures vertex processing and how fast the GPU can handle geometry transformations.
Texture Sampling — Multi-level texture reads with coordinate distortion. Tests texture unit throughput and memory bandwidth — critical for game rendering.
Particle System — 10,000 point sprites with alpha blending. Combines vertex processing, fragment shading, and blending — a realistic GPU workload.

Integrated GPUs (Intel, Apple, Qualcomm Adreno) versus discrete GPUs (NVIDIA, AMD) show dramatic differences here. Even between phones, the GPU gap can be 5-10x.

💾 Memory — The Hidden Bottleneck

CPU and GPU get all the headlines, but memory performance often determines real-world speed:

Sequential Read/Write — 32MB linear scan. Tests main memory bandwidth when access patterns are predictable — the best case scenario.
Random Access — 8MB random reads. This is the worst case. It exposes memory latency and how well the cache hierarchy handles unpredictable access patterns. The gap between sequential and random performance reveals your cache effectiveness.
Bandwidth — Tests copy speed across buffer sizes from 8KB to 32MB. This maps directly to cache levels — L1, L2, L3, and main memory. You can literally see the performance cliff as data exceeds each cache level.
Allocation Speed — How fast the runtime can allocate and initialize memory buffers. Important for applications that create lots of temporary objects.
TypedArray Operations — Vectorized multiply-add across 8M floats. Tests how well the JS engine optimizes tight numeric loops — some engines auto-vectorize these to SIMD instructions.

🤖 AI / NPU — The New Frontier

Every chip maker is adding AI accelerators. These tests simulate common ML workloads in pure JavaScript:

Matrix Multiply (GEMM) — 256×256 float32 matrix multiplication. This is THE operation behind neural networks. Measures raw FLOPS.
Conv2D — 3×3 convolution with 16 output channels over a 128×128 image with ReLU activation. The core operation in image recognition models like ResNet and YOLO.
Softmax — 10,000-element softmax across 1,000 iterations. Used in every attention layer and classifier output. Tests exp/log throughput.
Attention Score — Full scaled dot-product attention with Q, K, V matrices (64×64). This is the mechanism inside every transformer model — GPT, BERT, Llama, etc.
Mini-Network Inference — A 3-layer feedforward network (784→256→128→10) processing batches of 32. Simulates real model inference — like running a digit classifier.

Currently these run in pure JS on the CPU. As WebNN browser support matures, these same workloads could be dispatched to dedicated NPU hardware (Apple Neural Engine, Qualcomm Hexagon, Intel NPU). The scores will become a direct measure of on-device AI capability.

🖼️ Rendering — Browser Performance

Your device might have a fast CPU, but can the browser use it efficiently?

DOM Manipulation — Creates 1,000 styled elements, reads layout properties, applies transforms, then removes them. This is what happens in every complex web app — React, Vue, Angular all do this constantly.
Canvas 2D — Renders 200 circles, 100 lines, and 50 text labels per frame for 3 seconds. Tests the browser's 2D rendering pipeline — used in charts, games, and data visualization.
CSS Animations — Animates 500 elements simultaneously with rotation and translation. Tests the browser's compositor and animation scheduler — critical for smooth UI.
Layout / Reflow — Rebuilds a 50-item flexbox grid 500 times, forcing layout recalculation each time. This is the most expensive thing browsers do, and the main source of UI jank.
SVG Rendering — Creates and renders 200 SVG documents with circles and Bézier curves. Tests the vector rendering pipeline.

📦 Storage — I/O Speed

How fast can the browser persist and retrieve data?

IndexedDB Write/Read — Individual transaction read/write operations. The primary storage API for web apps.
IndexedDB Bulk — 5,000 records in a single transaction with cursor-based reading. Tests transactional throughput.
LocalStorage — Synchronous key-value storage. Fast but blocking — these tests reveal just how blocking.
Cache API — Write and read from the browser's Cache Storage. Used by service workers and PWAs for offline support.

Live Monitoring

One thing I wanted that other benchmarks don't do well: watching the test happen in real time.

While benchmarks run, you see four live-updating charts:

FPS — Browser frame rate, showing when the main thread is saturated
Score — Rolling score updates as each sub-test completes
Thermal — A stability metric that detects CPU throttling. It runs a quick workload repeatedly and measures timing consistency. When your chip heats up and throttles, the variance increases. It's indirect, but it actually works — you can watch a MacBook go from "Cool" to "Warm" during the GPU tests
Memory — JS heap usage in real-time (Chrome/Edge only, via performance.memory)

The Scoring System

Every sub-test produces a raw metric (operations/second, FPS, GB/s, etc.). These get normalized to a 0–5000 scale against baseline values.

The baselines are calibrated so that a mid-range 2024 device scores roughly 1000. A high-end device scores 2000–3000+. The maximum is 5000, leaving room for future hardware.

The overall score is the mean across all category scores, giving equal weight to CPU, GPU, Memory, AI, Rendering, and Storage.

Results & Analytics

After tests complete, you get:

Animated score ring with your overall score
Category cards with bar charts and per-sub-test breakdowns
Radar chart showing your device's strengths and weaknesses
Timeline chart showing score progression across tests
Full details table with every raw measurement
Export — JSON download or one-click clipboard copy for sharing

Technical Decisions

A few choices I made and why:

Pure vanilla JS, zero dependencies. No React, no build step, no npm. The entire project is static HTML/CSS/JS files. This means it works from a file:// URL, from any static host, and loads instantly. For a benchmark tool, framework overhead would pollute the measurements.

Inline Web Workers. Workers normally need a separate JS file loaded via URL, which fails on file:// due to security restrictions. I inline the worker code as a string and create a Blob URL. This means the multi-core CPU test works everywhere — even opening index.html directly from disk.

WebGL, not WebGPU. WebGPU is the future, but WebGL2 has 95%+ browser support including mobile Safari. For a tool that needs to work everywhere, WebGL is the right choice today. WebGPU variants can be added as an optional enhanced test later.

Canvas-based charts, not Chart.js/D3. Again, zero dependencies. The mini-line charts, radar chart, and timeline are drawn directly to <canvas>. They're simple, fast, and add zero to the bundle size.

Some Interesting Findings

Testing this across devices revealed patterns you don't see in spec sheets:

Apple Silicon is absurdly efficient. An M2 MacBook Air outperforms many desktop CPUs on single-thread while barely getting warm. The multi-core scaling efficiency is also excellent.
Mobile GPUs are surprisingly good. A recent iPhone's GPU fragment shader performance isn't that far behind integrated laptop GPUs. The Adreno and Mali GPUs in flagship Android phones are legitimate compute devices.
Storage performance varies wildly. IndexedDB on Safari is significantly slower than Chrome. LocalStorage blocking time can be 10x worse on some browsers. If your web app feels slow, storage might be why.
Thermal throttling is real and visible. Run the full suite on a fanless device and watch the thermal stability metric drop. Phones throttle aggressively after 30-60 seconds of sustained load. The benchmark captures this behavior that synthetic spec sheets ignore.

Try It Yourself

The project is fully open source. You can:

Run it now — Head to prashplus.com/web-stress-test and hit "Run Benchmark"
Clone it — Fork the GitHub repo and run locally
Extend it — Add your own tests, adjust baselines, build a leaderboard

git clone https://github.com/prashplus/web-stress-test.git
cd web-stress-test
python3 -m http.server 8000
# Open http://localhost:8000

No build step. No npm install. Just code and a browser.

What's Next

Some ideas for future versions:

WebGPU compute shaders for true GPU compute benchmarks
WebNN integration to actually test NPU hardware when browser support lands
WASM benchmarks comparing JS vs WebAssembly performance
Network speed tests measuring latency and throughput
Battery impact estimation for mobile devices
Leaderboard with anonymous result submission for comparison
Historical tracking to see how browser updates affect performance

The Bottom Line

Your browser is a more powerful computing platform than most people realize. WebStress proves it by pushing every subsystem — CPU, GPU, memory, AI, rendering, and storage — through real workloads, on any device, with zero friction.

The web platform is the only truly universal runtime. Building a benchmark on it means anyone, anywhere, on any device can test and compare their hardware with a single click.

Give it a try, share your scores, and let me know what tests you'd want to see added.

WebStress is open source under the MIT license. Try it live or star it on GitHub if you find it useful.

Tags: JavaScript, WebGL, Benchmarking, Performance, Web Development, Open Source, Browser, Cross-Platform

DEV Community: Prashant Piprotar

AetherScan: Building a Real-Time 3D Reconstruction App with Fast3R, WebSockets, and React Three Fiber

The Problem

What It Does

Architecture

Tech Stack

The Interesting Engineering Bits

1. Streaming Points Over WebSocket

2. Zero-Re-render Point Cloud Updates

3. Fast3R Inference with Dynamic Resolution

4. Eager Model Loading at Startup

5. Client-Side PLY Export

Running It Yourself

Docker (Recommended)

Local Development

Apple Silicon Support

Lessons Learned

What's Next

Links

From Drone Video to 3D Maps: Automate WebODM Setup with GPU Acceleration

The Problem: Drone Mapping Shouldn't Be This Hard

What This Repo Does

Quick Start (Under 5 Minutes)

Prerequisites

Linux / macOS

Windows (PowerShell)

The Architecture

GPU Acceleration: The Speed Multiplier

Real-World Performance (200 images, 20MP)

Requirements

From Video to Map: The Processing Pipeline

Extract Frames

Batch Process Multiple Videos

Choosing the Right FPS

Processing Presets

Output Formats

Real-World Use Cases

Project Structure

Tips & Gotchas

Contributing

Links

I Built a Cross-Platform Browser Benchmark That Stress Tests Any Device — Here's How

No installs. No native apps. Just open a URL and push your MacBook, PC, Android, or iPhone to its limits.

Why a Browser-Based Benchmark?

What It Tests

🧠 CPU — The Brain

🎮 GPU — The Graphics Muscle

💾 Memory — The Hidden Bottleneck

🤖 AI / NPU — The New Frontier

🖼️ Rendering — Browser Performance

📦 Storage — I/O Speed

Live Monitoring

The Scoring System

Results & Analytics

Technical Decisions

Some Interesting Findings

Try It Yourself

What's Next

The Bottom Line