Discussion :

[_alx_]

Bonsoir,
Existe-t-il un moyen, avec un PC sous Windows et par logiciel avec Delphi, de dater précisément (à la milliseconde ou mieux) l'affichage d'un motif à l'écran (le texte d'un label ou un graphique dans un canevas), c'est-à-dire de déterminer le moment exact où il devient visible après l'envoi des instructions d'écriture (VCL ou FMX) ? Je suppose un écran LED avec un temps de rafraichissement négligeable.
Merci d'avance à qui aura une idée.
Alx.

[ShaiLeTroll]

Pense que le dessin sous Windows, cela passe par WM_PAINT
Modifier le texte ne provoque pas le dessin, cela provoque un Invalidate qui amènera à un Paint ultérieur via la file d'attente.

QueryPerformanceCounter ou TStopwatch, une précision autour de la µs (voir 100 ns) mais l'affichage c'est complexe, fragmenté (seule une zone est dessiné, cela peut être juste le label comme tout un écran)
la VCL gère le DoubleBuffered, donc cela dessine dans un tampon et c'est lui qui est dessiné à l'écran ensuite

FMX, encore plus complexe, cela passe par DirectX, donc accélération graphique, double ou triple buffered.

Si l'on active, la synchronisation verticale, Directx ou OpenGl vont se cadencer à la fréquence de l'écran
Désactivé, on peut avoir plusieurs images qui se dessinent, la première n'est pas terminée que cela commence la seconde, cela peut faire quelques artefacts à la rupture (encore plus complexe avec les cartes graphiques qui divisent l'écran en plusieurs parties pour paralléliser des calculs, héritage de technologie de Naomi de SEGA)


Quel est l'objectif réel ?

[_alx_]

Quel est l'objectif réel ?

Je suis en train de tester le logiciel d'acquisition d'une caméra CMOS qui est capable d'horodater les images successives d'une vidéo.
Faute de matériel (ou d'astuce !), j'imaginais pouvoir avoir une idée des temps de latence en filmant l'écran du PC d'acquisition sur lequel j'écris l'heure qu'il est, en discontinu, avec un timer.
Ca marche, mais j'obtiens des délais qui ne sont pas en accord avec la liaison rapide en USB3 et qui doivent en effet venir plutôt du logiciel de dessin.
D'après vos remarques, cela n'a pas l'air facile d'en avoir une estimation.

[ShaiLeTroll]

Filmer un écran, généralement le résultat est pas terrible
Avec un LED, je crois que maintenant, ça se film sans soucis
Avec un LCD de 2010, tu verrais une taillade dans l'image
Avec un Cathodique, tu verrais une zébrure
Avec des LED de bricolage type Ardunio, tu le verrais clignoter.

La caméra filme en 25 images / seconde ?


Mais le décalage, tu l'observes à combien, pas plus de 1 / 25eme de seconde ?
Et c'est peut-être le logiciel d'acquisition qui prend un peu de temps aussi

Perso, je n'ai travaillé qu'avec des caméras en Coaxial sur des DVR Dahua ou des Caméras IP Axis.
L'horodatage était intégré (c'est conçu pour la vidéo surveillance, fonctionnalité de base)

[_alx_]

Filmer un écran, généralement le résultat est pas terrible.

C'est un écran moderne (portable DELL), de bonne qualité: il n'y a pas de souci de lisibilité.

La caméra filme en 25 images / seconde ?

c'est une caméra de course (pour l'astro) qui tourne, dans ce test, à 200 Hz avec des poses de 1 milliseconde.

Mais le décalage, tu l'observes à combien, pas plus de 1 / 25eme de seconde ?

c'est le problème: il est de 63 +/- 5 millisecondes, ce que je ne comprends pas.

Et c'est peut-être le logiciel d'acquisition qui prend un peu de temps aussi

C'est un logiciel réputé (dans le milieu astro) et j'ai vérifié, par exemple, que son horodatage, après l'USB3, a la régularité qu'on attend du hardware de la caméra. Il y a juste ce décalage.

Je me demande si le problème ne vient pas plutôt d'un délai dans l'affichage (Windows + Delphi): ce que je peux dater facilement (QueryPerformanceCounter, etc...) c'est l'instruction qui lance l'affichage graphique. Ce que je ne vois pas, et c'était ma question, c'est comment dater le moment où quelque chose va être visible à l'écran !
Ou, du moins, comment l'estimer.

[Paul TOTH]

alors, déjà Windows n'est pas un OS temps réel...et il est dépendant du hardware...sur x86 tu ne descends pas sous 15ms.

ensuite, je ne suis pas spécialiste, mais qu'appelles-tu visible à l'écran ?

1) le soft envoie des ordres graphiques
2) le hard alimente la mémoire vidéo avec les données calculées
3) le moniteur récupère l'info pour actualiser l'écran
4) les led réagissent électroniquement à la fréquence de rafraichissement de l'écran

si tu as un écran à 60Hz, ça veux dire si je ne m'abuse 60 images seconde, soit 16.6ms/image...et tu arrives aux limites du timer

donc je ne sais pas bien ce que tu veux horodaté (et où ?)

[_alx_]

alors, déjà Windows n'est pas un OS temps réel...et il est dépendant du hardware...sur x86 tu ne descends pas sous 15ms.

Ce n'est plus si mauvais que ça depuis Windows 7 & ff. Avec un cycle de changement de contexte de 0.5 ms, Windows et les machines modernes te permettent maintenant de garder une acquisition exigeante (PCI, USB) dans un intervalle de 1 ms dans au moins 95% des cas, avec quelques errances à au plus 2 ou 3 ms. On peut d'ailleurs encore améliorer en ''nettoyant" le système.
C'est cela qu'on essaye d'exploiter (voir plus bas).

ensuite, je ne suis pas spécialiste, mais qu'appelles-tu visible à l'écran ?

1) le soft envoie des ordres graphiques
2) le hard alimente la mémoire vidéo avec les données calculées
3) le moniteur récupère l'info pour actualiser l'écran
4) les led réagissent électroniquement à la fréquence de rafraichissement de l'écran

si tu as un écran à 60Hz, ça veux dire si je ne m'abuse 60 images seconde, soit 16.6ms/image...et tu arrives aux limites du timer

Merci de m'avoir fait remarquer mon oubli d'avoir vérifié la vitesse de rafraîchissement sur ce PC, que je pensais plus rapide puisqu'il y a un GPU additionnel (NVIDIA/T1000) en plus du GPU intel de série. Quoi qu'il en soit, une fréquence de rafraîchissement de 60 Hz explique(rait) un retard de 10 à 20 ms, pas de 65 ms ...

donc je ne sais pas bien ce que tu veux horodaté (et où ?)

Mon test consiste à inscrire périodiquement sur l'écran l'heure du PC en gros caractères (par un simple: TThread.Synchronize(TThread.Current, procedure begin Label.Caption := ...; end)), disons toutes les quelques dizaines de millisecondes sans doute assez variables, tout en filmant l'écran avec la caméra en acquisition à plus haute vitesse sur le même PC. Naïvement je croyais pouvoir comparer la date d'acquisition des images individuelles avec les changements de celle présente sur chaque image, afin d'en vérifier la concordance pour ce qui concerne l'acquisition.
La mauvaise concordance (typiquement 65 - 15 ~ 50 ms.) pourrait-elle raisonnablement être expliquée par les évènements 1) 2) 3) 4) que tu décris ? En particulier par le 3) ?

Pour info, il s'agit de préparer des observations d'amateurs d'un phénomène astronomique fugitif qui nécessite une datation absolue avec une précision d'au moins 10 ms. Evidemment, dans le monde professionnel, la caméra serait directement asservie par une horloge de référence (rubidium ou GPS) et les performances de l'acquisition n'interviendraient pas. Dans le monde des astronomes amateurs, les moyens sont plus réduits et se limitent en général à une caméra (derrière télescope) et un PC standard pour l'acquisition.

Merci, en tous cas, de t'être intéressé à mon problème.

[ShaiLeTroll]

TThread.Synchronize ... pense que c'est durant le Idle de TApplication que cela est effectué, donc quand l'application n'a rien de mieux à faire, si tu as plein de WM_PAINT a traiter pour afficher la vidéo dans ton programme, ça va être en faible priorité

Donc tu as SetCaption durant le OnIdle, celui provoque un Invalidate, et c'est plus tard que l'application recevra un WM_PAINT pour dessiner ... tellement d'asynchrone !
sachant que TLabel c'est un dessin sur le Control Parent, donc c'est particulièrement tordu, un TStaticText aura un comportement différent.
Entre le moment où tu as calculé le Temps et le moment où tu le dessines, déjà tu as un délai, ajoute le délai matériel, aucune surprise d'avoir une latence

Je serais toi, je dessinerais directement hors du WM_PAINT, un Timer qui dessine à l'arrache (Appel de Repaint forcé, ça fera du clipping) ... sur le forum, j'ai un programme qui dessine sur le bureau directement, si je trouve ça
Tu peux donc imaginer dessiné directement dans le DC de la fenêtre qui affiche la vidéo (voir un HOOK du WM_PAINT de cette appli si cela utilise le GDI et non une API plus bas niveau comme DX, OpenGL ...)

Tu veux un affichage immédiat, n'utilise pas la VCL mais peut-être une Scene DirectDraw, envoyé directement au GPU ce qu'il faut afficher hors du GDI Windows

[Paul TOTH]

alors j'ai fait un test rapide avec 2 timer et 2 label

le premier timer est fixé à 10ms
le second à 1000ms (1 seconde)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
uses
  System.DateUtils;
 
var
  Count: Integer = 0;
  Start: TDateTime;
 
procedure TForm1.Timer1Timer(Sender: TObject);
begin
  if Count = 0 then
    Start := Now;
  Inc(Count);
  Label1.Caption := FormatDateTime('hh:nn:ss.zzz', Now);
end;
 
procedure TForm1.Timer2Timer(Sender: TObject);
begin
  var seconds := SecondsBetween(Start, Now);
  if seconds > 0 then
    Label2.Caption := FloatToStrF(Count / seconds, ffFixed, 14, 2);
end;

j'arrive à 66 mise à jour par secondes...reste à savoir ce que capte la caméra

[_alx_]

Tu veux un affichage immédiat, n'utilise pas la VCL mais peut-être une Scene DirectDraw, envoyé directement au GPU ce qu'il faut afficher hors du GDI Windows

Merci pour toutes ces pistes que je vais étudier en détail.
Question naïve: si j'ai 2 GPUs sur ma machine, comment je fais avec Delphi pour utiliser l'un plutôt que l'autre, en dehors de l'attribuer globalement à BDS.EXE via le paramétrage Windows ?
Y a t-il un choix dynamique possible ?

[_alx_]

j'arrive à 66 mise à jour par secondes...reste à savoir ce que capte la caméra

Exactement comme moi, je suis bloqué à 15.6 ms par affichage quelque soit la valeur du timer, soit 64 Hz, drôlement proche des 60 Hz de l'écran ?

[ShaiLeTroll]

Le Timer fonctionne par message, il fait donc rarement moins que 15 ms entre deux appels, comme le bon vieux GetTickCount.

Tu veux une fréquence plus élevé, un Thread qui dessine sans utiliser la VCL directement sur le DeviceContext (sans Synchronize, juste protéger contre les erreurs 1400), tu perdras ton dessin à chaque fois que le Control se redessine, suffit de dessiner suffisamment souvent.

[Paul TOTH]

Nouvelle tentative alors

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
type
  TDrawThread = class(TThread)
  private
    HWnd: THandle;
  public
    constructor Create(HWnd: THandle);
    procedure Execute; override;
  end;
 
constructor TDrawThread.Create(HWnd: NativeUInt);
begin
  inherited Create(False);
  Self.HWnd := HWnd;
end;
 
procedure TDrawThread.Execute;
begin
  var DC := GetDC(HWnd);
  while not Terminated do
  begin
    var S := FormatDateTime('hh:nn:ss.zzz', Now);
    Winapi.Windows.TextOut(DC, 10, 10, PChar(S), Length(S));
    Sleep(10);
  end;
end;
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  TDrawThread.Create(Handle);
end;

[_alx_]

Nouvelle tentative alors

Bonjour,

J'ai fait de nouveaux tests en utilisant ton code.

Je trouve que le cadencement de l'écran est figé au multiple de 15.6 ms immédiatement supérieur à la valeur qu'on donne à l'instruction ''sleep'' de cadencement du thread. Cela semble montrer que l'écriture sur l'écran est asservie à sa cadence de rafraichissement (60 Hz), quelle que soit l'instant exact de l'instruction d'écriture dans le ''textout''.

Chaque string d'heure est donc en principe présent pendant environ 15.6 ms sur l'écran, lequel est filmé par la caméra à la cadence de 111 Hz, avec des poses de 1 ms.

On s'attendrait donc à voir une succession de deux ou trois images montrant le même string et environ une image sur 15 avec un flou de transition.

L'image de gauche ci-dessous illustre le résultat attendu: le string du milieu est l'heure envoyée à l'écran, l'incrustation en haut de la fenêtre est exécutée par le logiciel d'acquisition de la caméra à la réception de chaque image. Il y a donc bien un décalage, en moyenne de l'ordre de 80 ms, entre l'heure ''demandée'' et l'heure ''reçue''.

L'image de droite montre la situation de transition (mélange des valeurs 431 et 446), mais qui est beaucoup plus fréquente qu'attendue (50% des cas). Je suppose que le GPU ajoute un ''flou de transition'' pour rendre plus agréable le scintillement résiduel à 60 Hz. Le décalage pourrait à mon avis provenir de la gestion du graphisme (matériel + Windows + FIFO) et ne correspondrait en fait à rien de réel.

Qu'en pensez-vous ?
En tous les cas, Delphi ne peut m'aider et j'abandonne ce type de test qui est inadapté à son objectif, mais m'a appris beaucoup de choses
Merci à vous deux (Shail-Le-Troll et Paul Toth) pour votre aide et votre intérêt.

Alx.

[Paul TOTH]

oui donc on en revient aux 60Hz de l'écran...quelques soient les données graphiques dans la carte graphique, l'écran ne s'actualise que 60 fois par secondes.

pour ce qui est du mélange, il correspond à une mise à jour des données graphiques en cours de balayage écran...donc tu as le haut du 31 et la bas du 46 (normalement)...dans les jeux vidéos on utilise généralement un double buffer, ça permet de basculer instantanément d'une image à la suivante en changeant l'adresse mémoire à laquelle sont lues les données vidéo...et tu as généralement le paramètre VSync pour indiquer si on fait cette bascule pendant le retour en haut d'écran (ce sont des notions hérités des écrans cathodiques mais je crois que le fonctionnement est similaire, l'écran est balayé de haut en bas et de gauche à droite et il y a un petit délai entre le dernier pixel et le premier le temps de remonter = VSync) si tu changes le buffers avec VSync activé, tu restreins le FPS mais tu garantis que l'image est toujours entièrement affichée car elle ne change pas entre le premier et le dernier pixel...si tu désactives VSync tu augmentes le FPS mais tu peux avoir plusieurs portions d'images de différentes sources à l'écran...ça donne des lignes de décalages à l'écran quand tu bouges le point de vue...sauf à avoir un écran 144Hz qui va pouvoir s'actualiser suffisamment vite...mais ça le fait aussi avec VSync activé du coup

EDIT: ce n'est pas la même chose que le DoubleBuffer de Delphi, le double buffer Delphi est la création d'un bitmap pour stocker les infos qui sont ensuite envoyées à l'écran, ça évite les clignotement (j'efface le fond, puis je dessine le texte par exemple), mais le chargement du bitmap vers l'écran peut aussi se faire pendant la synchronisation écran et tu retrouves donc le flou.

[ShaiLeTroll]

On s'attendrait donc à voir une succession de deux ou trois images montrant le même string et environ une image sur 15 avec un flou de transition.

Oui, on en revient à ce que j'évoquais au début :

par DirectX, donc accélération graphique, double ou triple buffered.

Si l'on active, la synchronisation verticale, Directx ou OpenGl vont se cadencer à la fréquence de l'écran
Désactivé, on peut avoir plusieurs images qui se dessinent, la première n'est pas terminée que cela commence la seconde, cela peut faire quelques artefacts à la rupture (encore plus complexe avec les cartes graphiques qui divisent l'écran en plusieurs parties pour paralléliser des calculs, héritage de technologie de Naomi de SEGA)

Si tu veux dessiner plus vite, ton écran doit afficher plus vite (donc augmenter la fréquence) et plutôt passer des API GPU qui te donneront plus de maitrise, en gros coder comme dans un Jeux Vidéos.

Il faudrait trouver si tu ne peux pas au niveau matériel, au niveau du Contrôleur de la caméra CMOS, si tu ne peux pas déjà avoir un horodatage plus tôt dans la chaine, par forcément une heure mais un compteur basé sur la fréquence du Contrôleur.
Peut-être compter le nombre d'image, il est connu, si l'on connaît le temps exact à la première image, ne peux-tu pas déterminer le temps à la frame n ?
En théorie oui avec une nombre d'image fixe par seconde.


Et maintenant, tu sais que le horodatage de ton logiciel s'applique sur une image après 80ms, peut-être que tu peux faire un outil de calibrage pour calculer ce délai à chaque session de mesure, pour ensuite le retrancher à l'horodatage par le logiciel.


A savoir que Sleep(10), il y a environ 100µs de marge d'erreur.
Et si tu veux un cycle régulier de 10ms, tu dois retrancher le temps de l'opération, si celui-ci est inférieur à 1ms, faut cumuler le temps d'opération et le retrancher quand c'est possible pour rattraper ton retard.

Evidemment, dans ta problématique c'est sans jamais dépasser la vitesse physique de l'écran.

[Paul TOTH]

pour la petite histoire, j'ai commencé à travailler sur ces notions dans les années 80 sur un commodore 64 les jeux d'aventure utilisaient une technique assez sioux pour changer le mode video en cours de balayage...ça permettait d'avoir des graphismes sur la partie supérieure de l'écran et un mode texte sur la partie basse où on tapait les commandes

comme par exemple dans le

ou encore

[_alx_]

pour la petite histoire, j'ai commencé à travailler sur ces notions dans les années 80 sur un commodore 64

Merci pour cette video et la nostalgie qui l'accompagne: j'avais oublié la petite musique du C64 si caractéristique

[_alx_]

Il faudrait trouver si tu ne peux pas au niveau matériel, au niveau du Contrôleur de la caméra CMOS, si tu ne peux pas déjà avoir un horodatage plus tôt dans la chaine, par forcément une heure mais un compteur basé sur la fréquence du Contrôleur.

Ce serait l'idéal. Même de déclencher la caméra sur une horloge externe de référence. Certains astrams s'exercent à manier le fer à souder, l'Arduino et autre Raspberry pour y arriver. Mais ce n'est pas le cas de tous et j'aimerais trouver une solution moins ''spécialisée''.
La plupart des caméras astro pour amateur n'ont pas d'autre point d'entrée que le port USB du PC d'acquisition. Le plus souvent le contrôleur est un simple HID USB qui pourrait peut-être permettre d'envoyer un signal de synchro ? Mais les codes embarqués dans ces caméras ne sont pas publics.

[_alx_]

Je croyais avoir compris la gestion d'écran par Windows, et mon fil résolu.
Mais j'ai fait un nouvel essai à vitesse plus lente (45 ms. < 3*15.6 ~48 ms.) pour m'assurer si le Textout était synchrone ou pas.
Le code est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
procedure TDrawThread.Execute;
begin
  var DC := GetDC(HWnd);
  while not Terminated do
  begin
    var S := FormatDateTime('hh:nn:ss.zzz', Now);
    Winapi.Windows.TextOut(DC, 10, 10, PChar(S), Length(S));
    S := FormatDateTime('hh:nn:ss.zzz', Now) + ' *';
    Winapi.Windows.TextOut(DC, 10, 30, PChar(S), Length(S));
    Sleep(45);
  end;
end;

et le résultat:

Comment expliquer que, dans le film, le second événement d'écriture ait une date antérieure au premier ?