Log Viewer: sampled data storage for mobile support

[DonLakeFlyer]

Overview

The Log Viewer is currently desktop-only. Supporting it on mobile (iOS/Android) requires reducing the memory footprint of loaded log data, since mobile devices have strict memory limits and large .ulg/.bin files can easily consume hundreds of MB of samples.

Problem

LogFileParser currently stores every parsed sample in memory (QHash<QString, QVector<QPointF>> _fieldSamples). A typical 10-minute PX4 flight at 250 Hz across dozens of topics can produce millions of points — unacceptable on mobile.

The rendering layer already handles downsampling at display time via fieldSamplesFiltered(), but the full dataset is still held in RAM.

Proposed Solution

At parse time, apply configurable stride-based or LTTB (Largest-Triangle-Three-Buckets) downsampling when the device is identified as mobile, capping stored samples per field to a platform-tuned maximum (e.g. 10 000 points on mobile vs. unlimited on desktop).

Key considerations:

• The cap should be applied per-field during _applyResult(), before storing into _fieldSamples.
• AppSettings (or a new LogViewerSettings key) could expose a maxSamplesPerField preference, defaulting to 0 (unlimited) on desktop.
• fieldSamplesFiltered() remains unchanged — it already handles zoom/pixel decimation on top of whatever is stored.
• GPS path data (_gpsPathULogVehicleGlobalPosition etc.) should be sampled separately to preserve spatial resolution.
• Unit tests should verify that parse results with a sample cap produce the correct number of stored points and that fieldMinMax() still returns accurate extremes.

Acceptance Criteria

• Log Viewer can open a 10-minute flight log on an iPad/Android tablet without OOM crash.
• A maxSamplesPerField setting (or equivalent) controls the cap, defaulting to unlimited on desktop.
• Existing desktop unit tests continue to pass unmodified.
• New unit test covers capped-parse behavior.

[DonLakeFlyer]

Related to #14471

[AhmWael]

I think the proposed approach (stride/LTTB downsampling at parse time with a configurable cap) is a solid solution for the immediate mobile memory issue. It’s simple, predictable, and should reliably prevent OOM on constrained devices, which is the main goal here.

One potential limitation is that once we downsample during parsing, the original high-frequency data is permanently lost, so very fine-grained inspection (especially for things like IMU spikes or PID tuning) won’t be possible on mobile logs anymore. That may or may not matter depending on how we expect the mobile Log Viewer to be used.

As a possible longer-term enhancement, an alternative could be a hybrid approach where we keep a lightweight downsampled dataset for initial rendering, but still allow lazy loading of full-resolution data when a user zooms deeply into a specific field. That would preserve the same UX improvements while keeping full fidelity available when needed.

If needed, I can try implementing this later.