Feature: Screen Context for Post Processing

[MyButtermilk]

Für Scriber sollte zwischen zwei Größen unterschieden werden:

1. Kontext-Aktualisierung: Wie lange dauert es, bis neuer Bildschirminhalt als Text verfügbar ist?

2. Transkriptionslatenz: Wie lange muss die fertige Transkription zusätzlich auf den Bildschirmkontext warten?

Bei einer asynchronen, gecachten Architektur kann die zweite Größe nahezu 0 ms betragen, obwohl die OCR selbst beispielsweise 200 ms benötigt.

Realistische Planungswerte

Die folgenden Werte sind keine garantierten Herstellerangaben, sondern sinnvolle Ziel- und Planungswerte für einen modernen Laptop, aufgewärmte Modelle und ein aktives Windows-Fenster. Die offiziellen PaddleOCR-Vergleichswerte sind separat angegeben.

Lösung | Kontext-Aktualisierung | Zusätzliche Transkriptionslatenz bei Cache | Synchron ausgeführt -- | -- | -- | -- Fenstertitel und UIA-Eigenschaften | ca. 1–10 ms | 0–2 ms | 1–10 ms UI Automation, fokussierter Textbereich | ca. 2–30 ms | 0–2 ms | 2–30 ms UI Automation, großes Dokument | ca. 20–100+ ms | 0–2 ms | 20–100+ ms Windows Graphics Capture, neuer Frame | ca. 5–25 ms | 0 ms | 5–25 ms PP-OCRv6-tiny, kleine geänderte Region | ca. 30–150 ms | 0 ms | 30–150 ms PP-OCRv6-tiny, vollständiges 1080p-Fenster | ca. 150–400 ms | 0 ms | 150–400 ms PP-OCRv6-small, kleine Region | ca. 80–300 ms | 0 ms | 80–300 ms PP-OCRv6-small, vollständiges 1080p-Fenster | ca. 400–900 ms | 0 ms | 400–900 ms Tiny plus Small für einzelne unsichere Zeilen | ca. 50–220 ms typisch | 0 ms | 50–220 ms Windows AI TextRecognizer auf NPU | geräteabhängig; lokal messen | 0 ms | geräteabhängig Windows.Media.Ocr | stark geräte- und bildabhängig | 0 ms | lokal messen

Ist nach 20–30 ms kein neuer Kontext verfügbar, sollte Scriber den letzten brauchbaren Kontext verwenden oder ganz ohne Bildschirmkontext fortfahren. Ein einzelner langsamer OCR-Aufruf darf niemals die fertige Transkription blockieren.

Konkret empfohlene Strategie

1. UI Automation

• Beim Wechsel des Vordergrundfensters sofort auslesen.

• Fenstertitel, fokussiertes Element und sichtbaren Text priorisieren.

• Text als größere Blöcke abrufen, nicht Zeichen für Zeichen.

• Pro Anwendung ein Timeout beziehungsweise einen Circuit Breaker vorsehen.

• Bei Browsern, Office, Explorer und vielen klassischen Windows-Anwendungen ist das häufig der schnellste Pfad.

Erwartete zusätzliche Transkriptionslatenz: praktisch 0–5 ms bei Verwendung eines Caches.

2. PP-OCRv6-tiny

• Nur aufrufen, wenn UIA keinen ausreichenden Text liefert.

• Geänderte Regionen statt des gesamten Fensters verarbeiten.

• Modell beim Programmstart laden und einmal aufwärmen.

• Orientierungserkennung, Entzerrung und Dokumentvorverarbeitung deaktivieren.

• Zwei bis vier CPU-Threads verwenden.

Erwartete zusätzliche Transkriptionslatenz: 0 ms asynchron; ungefähr 30–400 ms bei synchroner Verarbeitung.

3. PP-OCRv6-small

Nicht für jeden Screenshot aufrufen. small nur verwenden für:

• Zeilen mit geringer Tiny-Konfidenz,

• sehr kleine Schrift,

• technische Bezeichner,

• Produktnamen oder Eigennamen,

• Zeilen mit vielen Sonderzeichen.

Im Idealfall wird nur der bereits gefundene Zeilenausschnitt an den Recognizer übergeben. Die erneute Texterkennung einer Zeile ist erheblich günstiger als eine zweite vollständige Detection-plus-Recognition-Pipeline.

Erwartete zusätzliche Transkriptionslatenz: 0 ms asynchron; bei einem selektiven zweiten Durchlauf häufig deutlich unter einem vollständigen Small-Aufruf.

CPU oder GPU?

Für diesen Anwendungsfall würde ich zunächst CPU mit OpenVINO oder ONNX Runtime verwenden:

• Die Screenshots treten einzeln und nicht als große Batches auf.

• Kleine Bildbereiche profitieren weniger stark von einer GPU.

• Der Speichertransfer und das Scheduling können einen Teil des GPU-Vorteils aufzehren.

• Verwendet die Audio-Transkription bereits die GPU, verhindert CPU-OCR zusätzliche GPU-Konkurrenz.

Die GPU lohnt sich eher bei:

• regelmäßigem Vollfenster-OCR,

• mehreren Monitoren,

• 4K-Bildern,

• mehreren parallelen OCR-Aufträgen,

• CPU-basierter Audio-Transkription.

Meine endgültige Empfehlung für minimale Latenz

UI Automation
    ↓ bei unzureichendem Ergebnis
PP-OCRv6-tiny auf geänderten Regionen
    ↓ nur bei unsicheren wichtigen Zeilen
PP-OCRv6-small Recognition

Alle Ergebnisse werden zeitgestempelt im Cache abgelegt. Das Transkriptions-Postprocessing wartet höchstens 20–30 ms und verwendet ansonsten den letzten verfügbaren Kontext. Damit bleibt die wahrgenommene zusätzliche Latenz im Normalfall bei ungefähr 0–5 ms.

Quellenverzeichnis

1. Microsoft, About the Text and TextRange Control Patterns – Performance: https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-about-text-and-textrange-patterns (Microsoft Learn)

2. PaddleOCR, PP-OCRv6 Introduction – Accuracy and Inference Benchmarks: https://www.paddleocr.ai/main/en/version3.x/algorithm/PP-OCRv6/PP-OCRv6.html (paddleocr.ai)

3. Microsoft, Direct3D11CaptureFramePool.CreateFreeThreaded: https://learn.microsoft.com/en-us/uwp/api/windows.graphics.capture.direct3d11captureframepool.createfreethreaded (Microsoft Learn)

4. Microsoft, Get Started with AI Text Recognition (OCR): https://learn.microsoft.com/en-us/windows/ai/apis/text-recognition (Microsoft Learn)

Ich lese „Laurenz“ als **Latenz**. Ja, die jeweiligen Verfahren erzeugen zusätzliche Laufzeit – allerdings muss diese **nicht** die Ausgabe der Transkription verzögern.

Zwei unterschiedliche Latenzen

Für Scriber sollte zwischen zwei Größen unterschieden werden:

1. Kontext-Aktualisierung: Wie lange dauert es, bis neuer Bildschirminhalt als Text verfügbar ist?
2. Transkriptionslatenz: Wie lange muss die fertige Transkription zusätzlich auf den Bildschirmkontext warten?

Bei einer asynchronen, gecachten Architektur kann die zweite Größe nahezu 0 ms betragen, obwohl die OCR selbst beispielsweise 200 ms benötigt.

Realistische Planungswerte

Die folgenden Werte sind keine garantierten Herstellerangaben, sondern sinnvolle Ziel- und Planungswerte für einen modernen Laptop, aufgewärmte Modelle und ein aktives Windows-Fenster. Die offiziellen PaddleOCR-Vergleichswerte sind separat angegeben.

Lösung	Kontext-Aktualisierung	Zusätzliche Transkriptionslatenz bei Cache	Synchron ausgeführt
Fenstertitel und UIA-Eigenschaften	ca. 1–10 ms	0–2 ms	1–10 ms
UI Automation, fokussierter Textbereich	ca. 2–30 ms	0–2 ms	2–30 ms
UI Automation, großes Dokument	ca. 20–100+ ms	0–2 ms	20–100+ ms
Windows Graphics Capture, neuer Frame	ca. 5–25 ms	0 ms	5–25 ms
PP-OCRv6-tiny, kleine geänderte Region	ca. 30–150 ms	0 ms	30–150 ms
PP-OCRv6-tiny, vollständiges 1080p-Fenster	ca. 150–400 ms	0 ms	150–400 ms
PP-OCRv6-small, kleine Region	ca. 80–300 ms	0 ms	80–300 ms
PP-OCRv6-small, vollständiges 1080p-Fenster	ca. 400–900 ms	0 ms	400–900 ms
Tiny plus Small für einzelne unsichere Zeilen	ca. 50–220 ms typisch	0 ms	50–220 ms
Windows AI TextRecognizer auf NPU	geräteabhängig; lokal messen	0 ms	geräteabhängig
Windows.Media.Ocr	stark geräte- und bildabhängig	0 ms	lokal messen

Microsoft weist darauf hin, dass UI Automation für Textabfragen prozessübergreifende Aufrufe verwendet. Einzelzeichenabfragen sind deshalb ungünstig; moderate Textblöcke sollten in einem Aufruf gelesen werden. Sehr große Bereiche können wiederum eine erhöhte Latenz verursachen. 1

Offizielle PaddleOCR-Referenzwerte

PaddleOCR nennt für die vollständige PP-OCRv6-Pipeline auf einem Intel Xeon 8350C mit OpenVINO:

• PP-OCRv6-tiny: 0,20 Sekunden
• PP-OCRv6-small: 0,59 Sekunden
• PP-OCRv6-medium: 1,40 Sekunden

Diese Messungen wurden mit einem anspruchsvollen, mehrsprachigen Testsatz durchgeführt, der unter anderem Dokumente, Webbilder, Handschrift, Unschärfe, Rotation und Verzerrung enthält. Ein sauberer Windows-Ausschnitt kann schneller sein; ein schwächerer Laptop oder ein 4K-Vollbild kann wiederum langsamer sein. 2

Für Scriber entscheidend: keine OCR im kritischen Pfad

Ich würde den Ablauf so bauen:

Bildschirm ändert sich
       │
       ├── UI Automation sofort auslesen
       │        typisch 2–30 ms
       │
       └── falls UIA unzureichend:
                Capture + OCR asynchron
                typisch 30–400 ms
                         │
                         ▼
                   Kontext-Cache

Audiosegment endet
       │
       ▼
Transkription fertig
       │
       ▼
Nächstliegenden Kontext aus Cache lesen
       │
       ▼
Postprocessing

Damit ergibt sich beispielsweise:

-300 ms   OCR des aktuellen Fensters startet
-120 ms   OCR-Ergebnis liegt im Cache
   0 ms   Benutzer beendet den Satz
+100 ms   ASR liefert das Rohtranskript
+102 ms   Kontext wird aus dem Cache gelesen
+103 ms   Postprocessing startet

Die OCR hat in diesem Beispiel 180 ms benötigt, aber nur ungefähr 1–3 ms zur Transkriptionslatenz hinzugefügt.

Empfohlenes Latenzbudget

Für Scriber würde ich folgende Grenzwerte verwenden:

Metrik	Zielwert
UIA-Abfrage P95	unter 30 ms
OCR einer geänderten Region P95	unter 150 ms
Vollfenster-OCR mit Tiny P95	unter 400 ms
Maximale Wartezeit des Postprocessors auf Kontext	20–30 ms
Zulässiges Alter des gecachten Kontexts	etwa 2–5 Sekunden
Debounce nach Bildschirmänderung	etwa 100–200 ms
OCR-Threads	2–4
OCR-Warteschlange	maximal ein aktueller Auftrag

Ist nach 20–30 ms kein neuer Kontext verfügbar, sollte Scriber den letzten brauchbaren Kontext verwenden oder ganz ohne Bildschirmkontext fortfahren. Ein einzelner langsamer OCR-Aufruf darf niemals die fertige Transkription blockieren.

Konkret empfohlene Strategie

1. UI Automation

• Beim Wechsel des Vordergrundfensters sofort auslesen.
• Fenstertitel, fokussiertes Element und sichtbaren Text priorisieren.
• Text als größere Blöcke abrufen, nicht Zeichen für Zeichen.
• Pro Anwendung ein Timeout beziehungsweise einen Circuit Breaker vorsehen.
• Bei Browsern, Office, Explorer und vielen klassischen Windows-Anwendungen ist das häufig der schnellste Pfad.

Erwartete zusätzliche Transkriptionslatenz: praktisch 0–5 ms bei Verwendung eines Caches.

2. PP-OCRv6-tiny

• Nur aufrufen, wenn UIA keinen ausreichenden Text liefert.
• Geänderte Regionen statt des gesamten Fensters verarbeiten.
• Modell beim Programmstart laden und einmal aufwärmen.
• Orientierungserkennung, Entzerrung und Dokumentvorverarbeitung deaktivieren.
• Zwei bis vier CPU-Threads verwenden.

Erwartete zusätzliche Transkriptionslatenz: 0 ms asynchron; ungefähr 30–400 ms bei synchroner Verarbeitung.

3. PP-OCRv6-small

Nicht für jeden Screenshot aufrufen. small nur verwenden für:

• Zeilen mit geringer Tiny-Konfidenz,
• sehr kleine Schrift,
• technische Bezeichner,
• Produktnamen oder Eigennamen,
• Zeilen mit vielen Sonderzeichen.

Im Idealfall wird nur der bereits gefundene Zeilenausschnitt an den Recognizer übergeben. Die erneute Texterkennung einer Zeile ist erheblich günstiger als eine zweite vollständige Detection-plus-Recognition-Pipeline.

Erwartete zusätzliche Transkriptionslatenz: 0 ms asynchron; bei einem selektiven zweiten Durchlauf häufig deutlich unter einem vollständigen Small-Aufruf.

CPU oder GPU?

Für diesen Anwendungsfall würde ich zunächst CPU mit OpenVINO oder ONNX Runtime verwenden:

• Die Screenshots treten einzeln und nicht als große Batches auf.
• Kleine Bildbereiche profitieren weniger stark von einer GPU.
• Der Speichertransfer und das Scheduling können einen Teil des GPU-Vorteils aufzehren.
• Verwendet die Audio-Transkription bereits die GPU, verhindert CPU-OCR zusätzliche GPU-Konkurrenz.

Die GPU lohnt sich eher bei:

• regelmäßigem Vollfenster-OCR,
• mehreren Monitoren,
• 4K-Bildern,
• mehreren parallelen OCR-Aufträgen,
• CPU-basierter Audio-Transkription.

Meine endgültige Empfehlung für minimale Latenz

UI Automation
    ↓ bei unzureichendem Ergebnis
PP-OCRv6-tiny auf geänderten Regionen
    ↓ nur bei unsicheren wichtigen Zeilen
PP-OCRv6-small Recognition

Alle Ergebnisse werden zeitgestempelt im Cache abgelegt. Das Transkriptions-Postprocessing wartet höchstens 20–30 ms und verwendet ansonsten den letzten verfügbaren Kontext. Damit bleibt die wahrgenommene zusätzliche Latenz im Normalfall bei ungefähr 0–5 ms.

Quellenverzeichnis

1. Microsoft, About the Text and TextRange Control Patterns – Performance: https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-about-text-and-textrange-patterns ([Microsoft Learn]1)
2. PaddleOCR, PP-OCRv6 Introduction – Accuracy and Inference Benchmarks: https://www.paddleocr.ai/main/en/version3.x/algorithm/PP-OCRv6/PP-OCRv6.html (paddleocr.ai)
3. Microsoft, Direct3D11CaptureFramePool.CreateFreeThreaded: https://learn.microsoft.com/en-us/uwp/api/windows.graphics.capture.direct3d11captureframepool.createfreethreaded ([Microsoft Learn]3)
4. Microsoft, Get Started with AI Text Recognition (OCR): https://learn.microsoft.com/en-us/windows/ai/apis/text-recognition ([Microsoft Learn]4)