Making EF-Map Faster: Three.js, WebGL, Performance Mode and FPS Caps

EF-Map renders the EVE Frontier universe with Three.js on top of WebGL, and for a long time the honest answer to "is it fast?" was "fast on my machine." That is a dangerous thing for a developer to believe. My machine has a discrete GPU and a display I run at a modest refresh rate. Plenty of the people using EF-Map do not, and a star map that floats along on a desktop with a dedicated graphics card can crawl on an integrated GPU, an older laptop, a phone, or a high resolution panel running at a high refresh rate. This is the story of how the map went from looking nice on one computer to staying usable across a much wider range of hardware, and the controls we added so players can make that trade for themselves.

From a black background to a real starfield

EF-Map did not start out pretty. The early version was close to white points on a black background. It was readable, it was cheap to draw, and it was visually flat. During a stretch when most of the blockchain facing work was waiting on EVE Frontier's move to the Sui chain, which we wrote about in Planning for SUI, there was room to make the universe feel less like a chart and more like a place.

That visual layer grew over several passes. Stars got a richer presentation, with colours nudged toward real spectral classes so the field reads more like actual stars than uniform dots. Close stars got a soft glow, a lens flare style highlight, and a subtle chromatic fringe on that glow. Behind everything sits a dark, layered nebula backdrop with near, mid, and far parallax. We covered the star side of this in Starfield Depth Effects and the background side in Fixing EF-Map's Parallax Backdrop. Every one of those effects is real geometry and real shader work, and every one of them costs GPU time.

"Works on my machine" stops being good enough

The effects looked great where they were built and tested. Then the reports started arriving from everywhere else. Integrated Intel graphics struggled. Some older Macs ran hot. Phones were uneven. High resolution screens pushed far more pixels per frame than a 1080p panel. High refresh monitors asked for frames far more often than 60 times a second. And a particular group mattered more than their numbers suggested: people running EF-Map on a second screen, next to the actual game, where every frame the map spends is a frame the game does not get.

That last case reframed the whole problem. EF-Map is a companion tool. A companion that quietly eats a chunk of your GPU while you are trying to fly is not helping. Once you accept that the map will often run beside something more important, "looks best on my hardware" is the wrong target. "Stays out of the way on your hardware" is the right one.

Why a still image still costs you frames

The least intuitive part of this is worth stating plainly, because it drives most of what follows. A 3D scene that looks completely static is not free. If the renderer is drawing the same frame 120 or 144 or 240 times a second, the GPU is doing 120 or 144 or 240 full passes of work every second, even though nothing on screen moved. Your eyes see a still picture. Your graphics card sees a full time job.

That single fact has two consequences. First, a high refresh display can make even a parked, motionless map expensive, purely because the screen is asking for frames so often. Second, the cheapest frame is the one you never draw. A lot of EF-Map's performance work is not about making each frame faster. It is about drawing far fewer of them when nobody needs them.

Performance Mode

The blunt instrument is Performance Mode, a single toggle at the top of Display Settings. Turning it on strips back the expensive visual layers: the star glow and flare go to zero, the parallax nebula backdrop is hidden, and the depth based brightness and desaturation effects are switched off. What you are left with is a cleaner, lighter star map that still does its real job of showing systems and routes, but asks far less of the GPU. It is the right setting for lower end hardware and for second screen use.

Performance Mode is careful about your settings. When you enable it, your current effect values are backed up first, and when you disable it they are restored, so it is a reversible switch rather than a one way wipe of your preferences. On top of that, EF-Map tries to detect an integrated GPU through WebGL and offer Performance Mode automatically the first time, so a lot of people on Intel, Apple Silicon, or AMD integrated graphics get the gentler defaults without ever opening a menu. The detection and auto enable logic has its own history, which we told in Performance Mode: Auto-Detecting GPUs, and there is a related deep dive into one nasty GPU specific slowdown in GPU Performance Debugging.

Display settings you actually control

Performance Mode is deliberately all or nothing, but not everyone wants all or nothing. Display Settings exposes the individual controls too, closer in spirit to a game's graphics menu than a single quality slider. You can dial star glow, flare, glow size, the backdrop, parallax intensity, star colours, and more, each on its own. All of it persists locally in your browser between sessions, so your tuning survives a reload.

Because a settings panel with this many knobs is easy to get lost in, there is a way back. Display Settings includes a Reset Display Defaults button that returns the visuals to a known good baseline, and a separate Reset Layout for the window arrangement. The intent is that you can experiment freely, knowing one click undoes the mess.

An FPS cap

The high refresh problem needed its own answer, because no amount of trimming effects changes the fact that a 144Hz or 240Hz display asks for frames that often. So Display Settings has an FPS Cap. It offers Match monitor, which is the uncapped default, plus fixed caps of 30, 60, and 120 FPS.

The cap is exactly what it sounds like. When it is set, the render loop skips frames that arrive sooner than the target interval, so a 240Hz monitor stops driving the map at 240 frames a second when 60 is plenty to read it. The in app description is honest about who it is for: it caps rendering to reduce GPU usage, and it is useful while gaming or on a laptop. If you are running EF-Map beside the game, capping it at 30 or 60 hands a meaningful slice of your GPU back to the thing you actually care about.

Throttling the map when you walk away

The cap helps while you are using the map. The bigger savings come from when you are not. EF-Map does not render at a fixed rate. It runs a dirty flag render loop: it draws at the full rate while something is actually changing, such as a pan, a zoom, a hover, or an animation, and when nothing is changing it throttles itself down to roughly five frames a second. The moment you move the mouse or interact, it wakes straight back up.

This is the single most important trick for a tool that lives open in a background tab or on a second monitor. If you tab away to fly and leave the map parked, it is not quietly rendering hundreds of frames a second of an unchanging scene. It is ticking over slowly until you come back. The earlier work that established this idle behaviour, including how it interacts with live event history, is in CPU Optimization: Reducing Idle Rendering.

The route pulse that refused to sleep

Idle throttling only works if the app honestly has nothing to draw. For a while one feature quietly broke that promise: the animated pulse that flows along a planned route. It is a nice touch, it shows direction, and because it animates continuously it counted as "something is changing" forever. A route on screen meant the map never went idle, which meant the GPU never got the break the throttling was supposed to give it.

The fix was to let the route animation fade out when you stop interacting. It now stays at full speed for a short grace period of about five seconds, then decelerates smoothly over the next fifteen, so it comes to rest roughly twenty seconds after your last interaction. Any interaction ramps it back to full speed within about a second. Once the pulse has settled, there is genuinely nothing animating, and the idle throttle can finally take over and drop the frame rate. The route is still there and still readable. It just stops paying for an animation nobody is watching.

The Performance Check benchmark

All of this raised a support problem. When someone says "EF-Map is slow," that could mean a software WebGL fallback, a tight frame budget from a high refresh display, heavy effects on a weak GPU, a driver issue, or simply a giant browser window pushing too many pixels. Guessing over Discord is painful. So EF-Map has a built in Performance Check, reachable from the Help panel, that turns "it feels slow" into a report you can actually read.

It runs a short benchmark, around half a minute, while the camera briefly orbits on its own and the visual effects toggle through different states. Under the hood it measures several phases: a stripped back state and the default effects state, each tested with the camera held still and then with the camera sweeping and zooming. That separation is the useful part. It can tell the difference between a scene that is heavy because of effects and one that struggles the moment the camera moves. While the benchmark runs it deliberately ignores your FPS cap, because the point is to measure peak capability, and it restores all your settings when it finishes.

The report it produces is detailed without being noise. For each phase it records average FPS, the worst case low percentile FPS, how many hitches occurred, and a score and grade. It detects your refresh rate and the matching frame budget, reads your unmasked GPU through a WebGL extension, notes whether WebGL is hardware accelerated or stuck in software, captures canvas size and pixel count, and even flags if your browser is zoomed. It then makes a rough call on whether you are limited by the CPU and JavaScript side or by the GPU and compositor, and it turns all of that into plain recommendations, such as suggesting an FPS cap when a high refresh rate is creating a tight frame budget, or Performance Mode when the effects are clearly the bottleneck.

What is still open

This is alpha software and the work is not finished. The galaxy map is where the adaptive idle throttling and the FPS cap apply most thoroughly. The newer Solar System View has more cinematic visuals, and confirming that it benefits from the same full idle and render throttling is on my list to verify rather than something I am claiming is already perfect. I am treating that as future investigation, not as a known bug. As EVE Frontier evolves and the hardware mix of its players changes, the right defaults will keep moving too.

The point is control, not minimalism

It would be easy to read all of this as "turn everything off and the map gets faster." That is true, but it is not the goal. The goal is to give players the choice. If you have the hardware and you want the full glow, flare, and parallax version of the EVE Frontier map, it is right there and it is the default. If you are on an integrated GPU, or a phone, or a 240Hz panel, or you just want EF-Map to sit politely beside the game and sip your GPU instead of gulping it, the same tool can do that too. Performance Mode, the FPS cap, idle throttling, and the Performance Check exist so that "fast enough" is something you decide, not something my particular graphics card decided for everyone.

Try it

Open EF-Map, go to Display Settings, and try Performance Mode and the FPS Cap. If the map ever feels slow, open the Help panel and run the Performance Check, then share the report if you want a hand reading it. The numbers it gives you are about your machine, not mine, which was the entire point.