Datation précise en Delphi

Version imprimable

09/01/2023, 22h20
_alx_

Datation précise en Delphi

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.
09/01/2023, 23h06
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 ?
09/01/2023, 23h58
_alx_

Citation:

Envoyé par ShaiLeTroll

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.
10/01/2023, 09h32
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)
10/01/2023, 12h08
_alx_

Citation:

Envoyé par ShaiLeTroll

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é.

Citation:

Envoyé par ShaiLeTroll

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.

Citation:

Envoyé par ShaiLeTroll

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.

Citation:

Envoyé par ShaiLeTroll

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.
10/01/2023, 13h52
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ù ?)
10/01/2023, 15h25
_alx_

Citation:

Envoyé par 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.

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).

Citation:

Envoyé par Paul TOTH

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 :oops: 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 ...

Citation:

Envoyé par Paul TOTH

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.:D
10/01/2023, 16h55
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

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:

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 :)

10/01/2023, 20h47
_alx_

Citation:

Envoyé par ShaiLeTroll

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 ?
10/01/2023, 20h53
_alx_

Citation:

Envoyé par Paul TOTH

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 ?
10/01/2023, 21h27
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.

Nouvelle tentative alors :)

Code:

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;

11/01/2023, 12h22
_alx_

2 pièce(s) jointe(s)

Citation:

Envoyé par Paul TOTH

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 :D
Merci à vous deux (Shail-Le-Troll et Paul Toth) pour votre aide et votre intérêt.

Alx.

Pièce jointe 632289 Pièce jointe 632290
11/01/2023, 12h53
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.
11/01/2023, 13h45
ShaiLeTroll

Citation:

Envoyé par _alx_

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 :

Citation:

Envoyé par ShaiLeTroll

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.
11/01/2023, 16h47
Paul TOTH

pour la petite histoire, j'ai commencé à travailler sur ces notions dans les années 80 sur un commodore 64 :D 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 https://www.youtube.com/watch?v=SZsyv5aKw4U"]Hobbit ou encore https://www.youtube.com/watch?v=6KMqP7VAN7U"] :)
11/01/2023, 19h34
_alx_

Citation:

Envoyé par Paul TOTH

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 :wink:
11/01/2023, 19h51
_alx_

Citation:

Envoyé par ShaiLeTroll

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.

1 pièce(s) jointe(s)

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:

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:
Pièce jointe 632420
Comment expliquer que, dans le film, le second événement d'écriture ait une date antérieure au premier ?

première chose à vérifier, c'est que le second Now est > en premier
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 procedure TDrawThread.Execute; begin var DC := GetDC(HWnd); while not Terminated do begin var T1 := Now; var S := FormatDateTime('hh:nn:ss.zzz', T1); Winapi.Windows.TextOut(DC, 10, 10, PChar(S), Length(S)); var T2 := Now; Assert(T2 > T1); S := FormatDateTime('hh:nn:ss.zzz', T2) + ' *'; Winapi.Windows.TextOut(DC, 10, 30, PChar(S), Length(S)); Sleep(45); end; end;
ensuite, cela peut s'expliquer par le balayage écran qui tomberait entre les deux textes (et non sur le texte comme dans ta photo avec 431 et 446)

tient, je t'invite à tester un rendu OpenGL en double buffered avec VSync activé (ou pas)

c'est un peu plus compliqué que GDI car OpenGL est une API graphique, donc pour afficher du texte il faut un peu de boulot (il y a d'autres méthodes mais j'aime bien celle-ci)

Code:

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
 
unit Unit1;
 
interface
 
uses
  Winapi.OpenGL,
  Winapi.OpenGLext,
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.ExtCtrls;
 
type
  TForm1 = class(TForm)
    Timer1: TTimer;
    procedure FormPaint(Sender: TObject);
    procedure FormResize(Sender: TObject);
  private
    { Déclarations privées }
    FDC: HDC;
    FGL: HGLRC;
    FFont: Integer;
    procedure createBitmapFont;
  public
    { Déclarations publiques }
    procedure CreateWnd; override;
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
 
{ TForm1 }
 
const
  FONT_TEXTURE_SIZE = 512;
var
  FontSizes: array[#0..#255] of TSize;
 
function glTextOut(x, y, FontSize: Single; const Str: AnsiString): Integer;
const
  t = 16/FONT_TEXTURE_SIZE;
begin
  Result := 0;
  glBegin(GL_QUADS);
  for var I := 1 to Length(Str) do
  begin
    var c := Str[I];
 
    var u1 := ((Ord(c) mod 16) * FONT_TEXTURE_SIZE / 16) / FONT_TEXTURE_SIZE;
    var v1 := ((Ord(c) div 16) * FONT_TEXTURE_SIZE / 16) / FONT_TEXTURE_SIZE;
    var u2 := u1 + FontSizes[c].cx / FONT_TEXTURE_SIZE;
    var v2 := v1 + FontSizes[c].cy / FONT_TEXTURE_SIZE;
    var x2 := x + FontSizes[c].cx * FontSize / 32;
    var y2 := y + FontSizes[c].cy * FontSize / 32;
    glTexCoord2f(u2, v1); glVertex3f(x2, y , 0);
    glTexCoord2f(u1, v1); glVertex3f(x , y , 0);
    glTexCoord2f(u1, v2); glVertex3f(x , y2, 0);
    glTexCoord2f(u2, v2); glVertex3f(x2, y2, 0);
    Inc(Result, Round(FontSizes[c].cx * FontSize / 32));
    x := x2;
 
  end;
  glEnd();
end;
 
procedure TForm1.createBitmapFont;
var
  c: AnsiChar;
begin
  var B := TBitmap.Create;
  B.PixelFormat := pf32Bit;
  B.SetSize(512, 512);
 
  B.Canvas.Font.Name := 'Arial';
  B.Canvas.Font.Size := 16;
 
  var DC := B.Canvas.Handle;
  for c := #0 to #255 do
  begin
    var X := 32 * (Ord(c) mod 16);
    var Y := 32 * (Ord(c) div 16);
    TextOutA(DC, X, Y, @C, 1);
    GetTextExtentPoint32A(DC, @C, 1, FontSizes[C]);
  end;
 
 
  glGenTextures(1, @FFont);
  glBindTexture(GL_TEXTURE_2D, FFont);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
 
  var P: TArray<Cardinal>;
  var S: PCardinal;
 
  SetLength(P, 512 * 512);
  for var y := 0 to 511 do
  begin
    S := B.ScanLine[y];
    for var x := 0 to 511 do
    begin
      var color := 255 - S^ and $FF;
      P[512 * y + x] := ($FFFFFF - (S^ and $FFFFFF)) or (color shl 24);
      Inc(S);
    end;
  end;
 
  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, P);
 
  B.Free;
end;
 
procedure TForm1.CreateWnd;
begin
  inherited;
 
  FDC := GetDC(Handle);
  if FDC = 0 then
    RaiseLastOSError;
 
  var pfd: TPIXELFORMATDESCRIPTOR;
  FillChar(pfd, SizeOf(pfd), 0);
  pfd.nSize       := sizeof(pfd);
  pfd.nVersion    := 1;
  pfd.dwFlags     := PFD_DRAW_TO_WINDOW or PFD_SUPPORT_OPENGL or PFD_DOUBLEBUFFER;
  pfd.iLayerType  := PFD_MAIN_PLANE;
  pfd.iPixelType  := PFD_TYPE_RGBA;
  pfd.cColorBits  := 32;
  pfd.iLayerType  := PFD_MAIN_PLANE;
  pfd.cStencilBits:= 0;
 
  var PixelFormat := ChoosePixelFormat(FDC, @pfd);
  if PixelFormat = 0 then
    RaiseLastOSError;
 
  if not SetPixelFormat(FDC, pixelformat, @pfd) then
    RaiseLastOSError;
 
  FGL := wglCreateContext(FDC);
 
  wglMakeCurrent(FDC, FGL);
 
  Winapi.OpenGLext.InitOpenGLext;
 
  wglSwapIntervalEXT(1); // Activer VSync
 
  CreateBitmapFont;
 
  FormResize(Self);
end;
 
procedure TForm1.FormResize(Sender: TObject);
begin
  if FGL <> 0 then
  begin
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity;
    glOrtho(0, ClientWidth, ClientHeight, 0, -100, +100);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity;
    glViewport(0, 0, ClientWidth, ClientHeight);
  end;
  Invalidate;
end;
 
procedure TForm1.FormPaint(Sender: TObject);
begin
  glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
 
  glEnable(GL_TEXTURE_2D);
  glBindTexture(GL_TEXTURE_2D, FFont);
  glEnable(GL_ALPHA_TEST);
  glAlphaFunc(GL_GREATER, 0.1);
 
  glTextOut(10, 10, 40, FormatDateTime('hh:nn:ss.zzz', Now));
 
  SwapBuffers(FDC);
 
  InvalidateRect(Handle, nil, False); // boucle éternelle
end;
 
end.

13/01/2023, 10h30
_alx_

Citation:

Envoyé par Paul TOTH

ensuite, cela peut s'expliquer par le balayage écran qui tomberait entre les deux textes (et non sur le texte comme dans ta photo avec 431 et 446)

Oui, c'est ce que je viens de comprendre et que tu confirmes: l'affichage montre, dans chaque 60ème de seconde et dans le sens du balayage du bas vers le haut, l'état de la mémoire graphique telle qu'elle est remplie à cet instant. Donc, une ligne située plus bas peut être montrée mais avoir été créée antérieurement à une ligne située plus haut, puisqu'elle n'a pas encore été modifiée.

Du coup, ça explique 16 ms de décalage, et ça pourrait même peut-être expliquer les valeurs plus élevées constatées en cas de multi-buffering x5 ou x6 (comme l'a suggéré ShailLeTroll).
13/01/2023, 10h32
_alx_

Citation:

Envoyé par Paul TOTH

tient, je t'invite à tester un rendu OpenGL en double buffered avec VSync activé (ou pas)

merci :D, je vais essayer dès que possible.

note que ce que j'ai mis dans FormPaint doit pouvoir se faire aussi dans une boucle indépendante...voir dans un Thread ? je n'ai pas testé...là j'utilise InvalidateRect (à ne pas mettre dans une boucle) qui va relancer un WM_PAINT sans WM_ERASEBKGND (dernier paramètre à False) contrairement au Invalide de la VCL...on a donc un WM_PAINT en boucle.

pour des questions de "ms" en moins on doit pouvoir aussi utiliser une procedure WMPaint(var Msg: TMessage); message WM_PAINT vu qu'on utilise rien de la VCL

oui d'ailleurs ça donne ça
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 procedure TForm1.Render; begin glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT); glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, FFont); glEnable(GL_ALPHA_TEST); glAlphaFunc(GL_GREATER, 0.1); glTextOut(10, 10, 40, FormatDateTime('hh:nn:ss.zzz', Now)); SwapBuffers(FDC); end; procedure TForm1.WMPaint(var Msg: TMessage); begin Render; end;
même plus besoin d'invalidate car normalement WM_PAINT appelle Validate(), ce que je ne fais pas ici :)

13/01/2023, 13h04
ShaiLeTroll

Citation:

Envoyé par Paul TOTH

indépendante...voir dans un Thread ?

Citation:

With multithread applications, flush the drawing commands in any other threads drawing to the same window before calling SwapBuffers.

Si tu n'as qu'un thread, ça doit pouvoir se faire, tu fais tourner ton thread avec juste un Sleep(0)
En mutli-thread, il semble falloir prendre des précautions, est-ce que la VCL peut pertuber quelque chose (un WMPaint avec un corps vide devrait laisser le thread secondaire d'aller à fond)
13/01/2023, 19h29
_alx_

1 pièce(s) jointe(s)

Citation:

Envoyé par Paul TOTH

tient, je t'invite à tester un rendu OpenGL en double buffered avec VSync activé (ou pas)

Ca ne change strictement rien de GDI à OpenGL, ni en activant ou non le VSync.
Il y a toujours ~90 ms de décalage dans tous les cas, pour un timer à 45 ms et une video à 9 ips.
Le décalage est seulement de ~65 ms avec un timer à 15 ms. Rien de nouveau.

Pièce jointe 632469
13/01/2023, 21h41
Paul TOTH
ok, par contre tu ne devrais plus avoir de chevauchement avec VSync activé :) tu peux ajouter un second temps
Code:

1 2 3 glTextOut(10, 10, 40, FormatDateTime('hh:nn:ss.zzz', Now)); glTextOut(10, 50, 40, FormatDateTime('hh:nn:ss.zzz', Now));
13/01/2023, 22h05
_alx_

Citation:

Envoyé par Paul TOTH

ok, par contre tu ne devrais plus avoir de chevauchement avec VSync activé :) tu peux ajouter un second temps

Désolé :calim2:, mais je viens de vérifier que les deux lignes restent identiques en OpenGL, que Vsync soit ou non activé 8O