Following up on my own question here, in case it helps anyone who lands on this thread later.
I never found a truly effective way to cap the DPI used by mapView.hitTest(), short of overriding window.devicePixelRatio itself. But I did find a better approach for my use case: for features drawn on the client, running a geometry query against the layer view turned out to be more performant than hit-testing, and far more consistent across DPI.
The approach
Instead of mapView.hitTest(), I run a geometry query against the layer view. It's generally faster and, more importantly, stays consistent as DPI changes. The only residual GPU cost is generating the hover highlight graphic itself, which does still lag as DPI / canvas size increase, but that's a much smaller cost than the hit-test was.
The reason comes down to what each one actually does:
- mapView.hitTest() forces a full WebGL render pass per pointer move and reads back from the GPU to work out what's under the cursor. That readback cost scales with the canvas pixel area, which is exactly why it doubled on a Retina display (DPI=2 is 4x the pixels of DPI=1). It's a rendering operation, so resolution is baked into the cost.
- layerView.queryFeatures() with a point geometry runs against the features held client-side in the layer view, using the in-memory spatial index on the CPU. It's a pure geometry operation. It has no idea what resolution your screen is, so devicePixelRatio simply doesn't enter into it.
So instead of asking the GPU "what did you draw at this pixel", I convert the pointer location to a map point with view.toMap() and ask the layer view "which features intersect this point". Same answer, no render pass.
What it looks like
async function pickAtScreenPoint(view, layerView, screenPoint) {
const mapPoint = view.toMap(screenPoint);
if (!mapPoint) return [];
// createQuery() folds in the layer view's effective display filter,
// outFields and returnGeometry, so filtered-out features are excluded for free.
const query = layerView.createQuery();
query.geometry = mapPoint;
query.spatialRelationship = 'intersects';
const { features } = await layerView.queryFeatures(query);
return features;
}
A few things worth noting:
- Use the layer view's queryFeatures (view.whenLayerView(layer)), not the layer's. FeatureLayer.queryFeatures() goes to the feature service; FeatureLayerView.queryFeatures() runs against the features available for drawing on the client, so there's no server round trip and no waiting on a fetch.
- createQuery() is doing useful work here. It applies the effective display filter for the current scale, so whatever the user has filtered out of view is automatically excluded from the pick, with no extra bookkeeping.
- If you want a bit of click tolerance, buffer the map point slightly before the query rather than relying on pixel tolerance.
One limitation worth flagging
As I understand it mapView.hitTest() picks against the rendered symbology, so it accounts for things like line widths, marker sizes, and symbol offsets. A thin line drawn with a wide stroke is still pickable across the full width you see on screen, and an offset symbol is pickable where it's actually drawn, not where its geometry sits.
The geometry query has none of that context. It tests the true feature geometry only, so symbol width and offset are ignored. For my polygon footprints that makes no practical difference, but for thin lines or large/offset point symbols the query will feel less forgiving, since you have to be over the actual geometry. Buffering the query point (scaled to the current resolution) recovers most of the width tolerance, though it won't reproduce symbol offsets exactly. Worth weighing up if your layer leans heavily on symbology for its clickable area.
Hope this saves someone the rabbit hole I went down. Happy to share more detail on the setup if useful.
The video below shows a comparison: first the view.hitTest() method (map with blue footprints), then the new layer query approach (map with red footprints).
