Skip to content

WIP: Add Tools-GPS-Tracks workload - #600

Open
camillobruni wants to merge 7 commits into
WebKit:mainfrom
camillobruni:2026-07-20_gpx_workload
Open

camillobruni wants to merge 7 commits into
WebKit:mainfrom
camillobruni:2026-07-20_gpx_workload

Conversation

@camillobruni

Copy link
Copy Markdown
Contributor

Introduce an experimental GPS activity track analyzer workload to cover binary and XML telemetry parsing, IndexedDB persistence, geospatial map rendering, and multi-track physiological charting in Speedometer.

Introduce an experimental GPS activity track analyzer workload to cover binary and XML telemetry parsing, IndexedDB persistence, geospatial map rendering, and multi-track physiological charting in Speedometer.
@netlify

netlify Bot commented Nov 13, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for webkit-speedometer-preview ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit e04801f
🔍 Latest deploy log https://app.netlify.com/projects/webkit-speedometer-preview/deploys/6af7436db7f46d44adc656ec
😎 Deploy Preview https://deploy-preview-600--webkit-speedometer-preview.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Expand the geospatial and physiological telemetry computations across all seven benchmark steps so each step consistently exceeds 20 ms on desktop Firefox while keeping iteration variance low.
Scale down the geospatial and physiological telemetry computations across all seven benchmark steps by 40% to keep total step runtimes balanced across browsers.
Achieve target step runtimes by exercising multi-track, multi-section, and multi-mode application workflows instead of repeating identical computations in synthetic loops. This keeps all 7 benchmark steps balanced at ~40-60ms in Firefox while testing realistic user interactions across all views.
Browser history state updates are rate-limited across repeated benchmark iterations and cause SecurityError failures in high-iteration runs. Replace window.history usage with an in-memory query and navigation state implementation so benchmark runs execute without browser history side effects.
…steps

The prepare phase ran a full synthetic warmup and app initialization before signaling readiness, leaving a large unmeasured chunk of JS. Prepare now only fetches test data, so all initialization, parsing, and rendering is measured consistently in the benchmark steps across browsers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant