Ruckelige Ladeanimation #7

New issue

Open

opened 2026-04-17 01:29:29 +02:00 by moritz · 1 comment

moritz commented

2026-04-17 01:29:29 +02:00

Owner

Die Animation des Kreises, welcher den Fortschritt anzeigt, stockt leicht beim Suchen des GPS fix und sieht daher nicht flüssig aus.

Imported from GitHub #13

Die Animation des Kreises, welcher den Fortschritt anzeigt, stockt leicht beim Suchen des GPS fix und sieht daher nicht flüssig aus. --- *Imported from [GitHub #13](https://github.com/EiSiMo/Einsatzprotokoll/issues/13)*

moritz referenced this issue from a commit

2026-05-04 08:50:39 +02:00

Fix #7: Smooth GPS loading animation (60fps)

moritz closed this issue

2026-05-04 08:50:39 +02:00

moritz referenced this issue from a commit

2026-05-04 09:34:33 +02:00

Fix #7 properly: cache loading text instead of reloading per frame

moritz referenced this issue from a commit

2026-05-04 09:38:09 +02:00

Revert #7 attempts: restore original LoadingView animation

moritz

2026-05-04 09:38:45 +02:00

reopened this issue
added the
deferred
label

moritz commented

2026-05-04 09:39:12 +02:00

Author

Owner

Aufgeschoben.

Zwei Versuche gemacht, beide brachten auf der echten FR265 keinen sichtbaren Unterschied:

Tick-Rate von 50ms (20fps) auf 16ms (~60fps) erhöht — Commit 33d107a. Theorie: 20fps zu wenig, höhere Rate masking. Auf der Uhr keine Verbesserung.
Resource-Caching im onUpdate — Commit b07d994. Theorie: WatchUi.loadResource() + splitLines() lief jeden Frame, das könnte den Hauptthread genug stören dass der Bogen stockt. Auch keine Verbesserung.

Beide Änderungen wurden in 495d854 zurückgenommen, damit der Code wieder im Originalzustand ist.

Vermutung: Das Stocken liegt an der Hardware/Firmware der FR265. Wahrscheinlich ist dc.drawArc() mit dickem Stift über den vollen Umfang für den Connect-IQ-Renderer auf dem Gerät zu teuer und Frames werden gedroppt. Das wäre ohne Bitmap-basiertes Pre-Rendering oder kompletten Wechsel der Loading-Visualisierung (z.B. einfache pulsierende Punkte statt Arc) kaum zu fixen.

Akzeptiert. Wieder anpacken nur wenn jemand eine konkrete Idee hat oder wir die Loading-Visualisierung sowieso umbauen (z.B. im Zuge von #6 — Genauigkeit live anzeigen).

Aufgeschoben. Zwei Versuche gemacht, beide brachten auf der echten FR265 keinen sichtbaren Unterschied: 1. **Tick-Rate von 50ms (20fps) auf 16ms (~60fps) erhöht** — Commit `33d107a`. Theorie: 20fps zu wenig, höhere Rate masking. Auf der Uhr keine Verbesserung. 2. **Resource-Caching im `onUpdate`** — Commit `b07d994`. Theorie: `WatchUi.loadResource()` + `splitLines()` lief jeden Frame, das könnte den Hauptthread genug stören dass der Bogen stockt. Auch keine Verbesserung. Beide Änderungen wurden in `495d854` zurückgenommen, damit der Code wieder im Originalzustand ist. **Vermutung:** Das Stocken liegt an der Hardware/Firmware der FR265. Wahrscheinlich ist `dc.drawArc()` mit dickem Stift über den vollen Umfang für den Connect-IQ-Renderer auf dem Gerät zu teuer und Frames werden gedroppt. Das wäre ohne Bitmap-basiertes Pre-Rendering oder kompletten Wechsel der Loading-Visualisierung (z.B. einfache pulsierende Punkte statt Arc) kaum zu fixen. **Akzeptiert.** Wieder anpacken nur wenn jemand eine konkrete Idee hat oder wir die Loading-Visualisierung sowieso umbauen (z.B. im Zuge von #6 — Genauigkeit live anzeigen).

moritz added the

error

label

2026-05-04 14:31:35 +02:00