performance c++ <> Delphi

[freimatz]

Kurze Antwort: Nein.

Bischen wirr geschrieben der Beitrag (so wie meine meist.)

Wie kann man ein Event an C++ schicken? C++ ist eine Programmiersprache

Wenn es um Probleme gibt und Postmessage ist im Spiel ist Delphi sicher so viel langsamer, als dass das irgendweine Rolle spielen könnte.

[hoika]

Hallo,

Zitat:

Mir möchte jemand erzählen das wenn er seine Scrollbar sehr schnell zum Ende bewegt wenn ein Movie spielt seine Anwendung dabei abstürzt.

Dann baue ihm eine Dummy-DLL, deren Aufrufe nichts machen zum Test.
Oder er soll sich eine c++-DLL bauen.

Und außerdem:
Wenn seine Anwendung abstürzt, was kannst du denn dafür

[Zacherl]

Von der Performance ist C++ sicherlich besser als Delphi, aber das ist definitiv nicht die Ursache des Problems.

Verwendest du in deiner Dll oder er in seinem Programm mehrere Threads?

[Uwe Raabe]

Zitat von Zacherl:

Von der Performance ist C++ sicherlich besser als Delphi, aber das ist definitiv nicht die Ursache des Problems.

Genau! Ein fehlerhaftes Programm kann man bekanntlich in jeder Programmiersprache schreiben - in manchen ist das etwas schwieriger als in anderen. Allerdings glänzt C++ gerade in diesem Punkt nicht so besonders.

[nahpets]

Zitat von Zacherl:

Von der Performance ist C++ sicherlich besser als Delphi, aber das ist definitiv nicht die Ursache des Problems.

Aber dann stimmt dashier nicht: Integer Performance Comparison for C++, C#, Delphi
Da kommt genau das gegenteilige Ergebnis raus.

[Blup]

Wenn man überhaupt nicht weis was diese DLL und die Anwendung macht, kann man mit der Beschreibung nicht viel anfangen.

Eine Möglichkeit wäre z.B., die DLL ruft innerhalb eine Threads das Event auf.
Die Anwendung möchte im Event auf die VCL zugreifen.
Dann könnte der Eventhandler per PostMessage die Nachricht an den Hauptthread weiter leiten, der das darf.

[EWeiss]

Zitat:

Bischen wirr geschrieben der Beitrag (so wie meine meist.)

Kein Ahnung was du wirr meinst noch deutlicher kann man das nicht formulieren.

Zitat von Blup:

Wenn man überhaupt nicht weis was diese DLL und die Anwendung macht, kann man mit der Beschreibung nicht viel anfangen.

Eine Möglichkeit wäre z.B., die DLL ruft innerhalb eine Threads das Event auf.
Die Anwendung möchte im Event auf die VCL zugreifen.
Dann könnte der Eventhandler per PostMessage die Nachricht an den Hauptthread weiter leiten, der das darf.

Ich weis was er macht.
Also nochmal!

Meine DLL schickt ein Event an die Anwendung welche C++ verwendet.
Die Funktion die das Event signalisiert.

Code:

BOOL KVIDEOPLAYERDEF(KVideo_Initialize)(HWND MediaWindow, BOOL UseOverlay, CBEventNotice event);

Meine Reverenz.

Code:

typedef void(__stdcall *CBEventNotice)(TPlayerEvent);

sein Reverenz.

Code:

typedef void( *CBEventNotice)(TPlayerEvent);

er meint er braucht __stdcall nicht weil die Referenz selbst bei ihm nie aufgerufen wird.

Die CallBack bei mir.. funktioniert ohne Probleme.

Code:

void __stdcall OnPlayerEvent(TPlayerEvent event)
{
    if (event == PlayEnded)
    {
        KillTimer(MovieHandle, MOVIE_TIMER);
        // IMediaSeeking mach probleme wenn Position weniger dann auf Max setzen
        INT64 MaxPos = (aMediaProperty.PlaybackLength / 10000) / 1000;
        if (Position < MaxPos)
            SetScrollPos(MovieHandle, SBS_HORZ, (int)MaxPos, TRUE);
        else
            SetScrollPos(MovieHandle, SBS_HORZ, 0, TRUE);
    }
}

Die Callback bei ihm.

Code:

void __stdcall OnPlayerEvent(TPlayerEvent event)
{
    if (event == PlayEnded)
    {
         if (CheckLoopMode()) {
            KVideo_Play();
         } else {
            SetStatusText(L"Closed");
            DisableRestoreState();
            Media_Stopped();
         }
    }
}

Hier soll es jetzt krachen wenn er seinen Slider schnell zum Ende bewegt.
Er hat das jetzt so umgangen.

Code:

void CALLBACK OnPlayerEvent(TPlayerEvent event) {
    PostMessage(hMain, WM_COMMAND, MAKLNG(IDC_PLAYENDED, 0), NULL);
}

WinProc

Code:

        case IDC_PLAYENDED:
            if (CheckLoopMode()) {
                KVideo_Play();
            } else {
                SetStatusText(L"Closed");
                DisableRestoreState();
                Media_Stopped();
            }
            break;

er ist der Meinung das es an Delphi liegt.
wäre zu langsam.

Zudem gäbe es das Problem das meine DLL synchron und MF asynchron laufen das wäre das Problem warum meine DLL zu viel CPU verwenden würde beim abspielen der Videos.

Zitat:

Verwendest du in deiner Dll oder er in seinem Programm mehrere Threads?

Ich nicht er schon.


gruss

[Zacherl]

Zitat von EWeiss:

er ist der Meinung das es an Delphi liegt.
wäre zu langsam.

Zudem gäbe es das Problem das meine DLL synchron und MF asynchron laufen das wäre das Problem warum meine DLL zu viel CPU verwenden würde beim abspielen der Videos.

Selten so blöde Aussagen gehört, die jedlicher Logik entsagen

Zitat von EWeiss:

Zitat:

Verwendest du in deiner Dll oder er in seinem Programm mehrere Threads?

Ich nicht er schon.

Dann wette ich schon fast drauf, dass hier irgendwo die Ursache zu finden ist.

Zitat von EWeiss:

er meint er braucht __stdcall nicht weil die Referenz selbst bei ihm nie aufgerufen wird

Da hat er vermutlich sogar recht, wobei das stdcall im Typedef sich auch keinesfalls negativ auswirken würde. Erfüllt halt vor allem die Funktion des selbstdokumentierenden Codes.

[EWeiss]

Zitat:

Da hat er vermutlich sogar recht, wobei das stdcall im Typedef sich auch keinesfalls negativ auswirken würde. Erfüllt halt vor allem die Funktion des selbstdokumentierenden Codes.

Nun ich bin davon ausgegangen das ein stdcall von Nöten ist um die Funktionsweise des Event zu gewähren.
Zumindest habe ich das bei unserer letzten Diskussion so verstanden.

Nun wie schon erwähnt bin kein besonders guter Kenner von C++ aber versuche mein bestes mit eurer Unterstützung..

gruss

[mensch72]

Ich erspare mir mal Kommentare zu sync/async und wer hier "zu langsam" ist.

Ganz BlackBox und allgemein:
- die DLL ist hier der Master und erzeugt freundlicherweise NotifyEvents... dies tut sie aktuell via Aufruf einer CallBackFunktion
- wenn mein Programm das wäre, wessen CallBack da aufgerufen wird, dann MUSS ICH garantieren, das meine CallbackFunktion so schnell nur irgend geht funktioniert. Das kann ich per eigener Queue selbst machen oder ich nutze die WindowsMessageQueue... ist aber mein Bier und ich kann nicht erwarten, das die DLL selbst auch noch so freundlich ist, mir alle Events zu synchronisieren und zu puffern. Wenn ich die DLL "quäle" in dem meine Callbacks "zu lange" brauchen, kann es rein als Blackbox zwei Arten von Grundsatzproblemen geben:
- a: die DLL und alles was sie macht hängt so lange ich meine ersten EventCallbackFunktion nicht beende und so die Ausführung zur DLL zurückkehrt
- b: die DLL ruft wie auch immer die EventCallbackFunktion nochmal/mehrmals auf, also voll rekursiv... darauf sollte dann aber sowohl die DLL wie auch mein Programm vorbereitet sein

Wenn es nicht zuviel Aufwand ist, biete doch offiziell statt eines EventCallbacks auch eine Möglichkeit für eine EventMessage an, also lass deiner DLL vom Hauptprogramm ein FansterHandle und eine MessageID geben, was du per PostMessage per WPARAM und LPARAM mit 2 Werten für EventType und EventValue fütterst.
Das spart viel Stress. Wenn mehr Daten zu übertragen sind dann die einfach per UDP über "localhost" aus der DLL heraus schicken... dann so eine C++ oder was auch immer Programm doch da die Daten "auffangen"... "Synchrone EventCallBacks" nutzen wir nur mit/zwischen "eigenen" Programmen und DLLs, externes IPC wenn möglich per PostMessage oder per Pipe oder UDP.

Auf so Diskussionen über Schuld/Unschuld bei externen CallBacks verzichte ich, und realisiere es "asynchron" über einen vertrauenswürdigen OS-Puffer, also MessageQueue,Pipes oder Socket