Win64 VCL Applikation Delphi 11.3 - not respondig

[taveuni]

Zitat von Uwe Raabe:

Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

Was aber wenn ich das Handle benötige um mit PostMessage aus einem Thread heraus zu notifizieren? Vermulich ist das dann sowieso der falsche Ansatz und ich sollte für dies wieder zu Events zurückkehren. Und dies mit TThread.Synchronize tun. Dann bin ich diesbezüglich aber wieder am Anfang.

[Kas Ob.]

@taveuni , hi

Sorry for "My bad is English" and the translation, so i might missed many stuff.

But i did few projects with security cameras and recording/handling images software, and want to points few things that can be problem for you to face:

1) The most important thing is to have small code to test the limit of decoding, this code should be portable and included within the software, i mean yes you have hardware (GPU) decoding but there is limit of how many streams can be decoded concurrently, GPU tend to throttle instantly.
2) Crucial thing to do is to not allow or implement any sort of inter-threads communication, i mean 0 interaction between threads them selves or with the main threads, this make no sense at first but will i will explain it further down.
3) the drawing form the main thread should not perform more than fixed frame per second, and definitely should not wait on the background decoding threads, and will not have (or wait for) any notification from them.
4) logging should be lock free.

Now to some details :
GPU decoding can be overwhelmed easily and will stop/slow for each and every stream, so should be throttled, hence the test and benchmark, also after feeding the stream and when you want to decode to different one, make sure to flush the stop decoding for the ones that is not needed, if the application is to save the encoded streams then let them continue to just save only.
The decoding threads will have the decoded images in a ring buffer, lock free would be perfect but any will do, and will not perform any notify for that matter, just drop the image in bucket or list or whatever....
Drawing from the main thread should be happen with a timer, simple as that, remove the images from the buffers then draw then recycle, try to recycle (cache) these Bitmaps, again with lock free list.
That timer must not be more frequent than the Hz of the monitor and the FPS from these streams.
Mainthread will draw/render all the images, if there were new images or not, it will just consume what in the filled buffer from each decoding threads.

Your decoding DLL might provide two method of decoding synchronous and/or asynchronous, use the synchronous (blocking) one.

As a rule of thumb stay away from sending/posting messages, the interthread communication should be limited to go and stop, and may be , i say be a counter for decoded images, and that is it.

After building that you can go fancy and add features, like watermarks special editing, motion detection ...

Hope that helps.

[Uwe Raabe]

Zitat von taveuni:

Was aber wenn ich das Handle benötige um mit PostMessage aus einem Thread heraus zu notifizieren?

Was aber, wenn das Handle durch ein RecreateWnd neu erzeugt wird? Das kann auch bei einem Control in der Parentfolge des Panels sein, was dann auch das Handle des Panels unbrauchbar macht.

Das Problem besteht übrigens unabhängig von Threads.

[himitsu]

Passiert auch, wenn man StayOnTop ändert
oder wenn ein Fenster minimiert ist und aus Platzspargründen vorübergehend aus dem Speicher fliegt.

Für sowas sollte man sich in eines der entsprechenden Methoden einhängen

Delphi-Quellcode:

    procedure CreateWindowHandle(const Params: TCreateParams); virtual;
    procedure CreateWnd; virtual;

    procedure DestroyHandle; virtual;
    procedure DestroyWindowHandle; virtual;
    procedure DestroyWnd; virtual;

bzw. WM_CREATE, WM_DESTORY, CM_RECREATEWND usw.


z.B. bloß im Constructor eine Funktion am Handle (HWND) zu aktivieren und sich dann zu wundern, wenn sie zur Laufzeit irgendwann mal weg ist ... schon bissl unpraktisch.

[taveuni]

Ich bin jetzt 4 Tage nicht im Büro. Werde mich am Dienstag wieder damit beschäftigen. Allgemein: was kann den Hauptthread lahmlegen ohne dass dieser beschäftigt ist?

[himitsu]

ein Deadlock ... Sleep, WaitFor oder I/O, wo der Treiber auf was wartet, usw.

Wenn es lang genug hängt, im Debugger auf Pause und schauen wo der Thread grade hängt (Stack).

[taveuni]

Zitat von himitsu:

ein Deadlock ... Sleep, WaitFor oder I/O, wo der Treiber auf was wartet, usw.

Wenn es lang genug hängt, im Debugger auf Pause und schauen wo der Thread grade hängt (Stack).

Da fehlt mir leider das Verständnis. Als ich mich mit dem remote debugger eingehängt hatte war ja irgendwie pausieren nach Verbindung angehakt. Da würde ich dann etwas sehen?
Ich komme gerne darauf zurück.

[hoika]

Hallo,
funktioniert denn die alte Installation/ Exe noch.

Nicht das sich in der Zwischenzeit irgendwas anderes geändert hat ...

[himitsu]

Diese Option sagt nur, dass der Debugger kurz nach dem Start der Anwendung schon anhalten soll, man also das Starten der Anwendung debuggen kann.

Du willst doch erstmal etwas laufen lassen, bis das Fenster geladen ist, also erst ab da wo die GUI hängt.
Wie bei Kassette, CD, DVD usw.
Es gibt den Start-Knopf ⏵ (mit und ohne Käfer), einen Knopf zum Beenden ⏹ und ⏸
ohne Käfer = ohne Debugger starten

Und dann noch Tasten (F7/F8) um langsam weiterzugehn (Schritt für Schritt oder ein gaaaanz großer Schritt, bis es wieder zurück/heim kommt)