performance c++ <> Delphi

[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

[EWeiss]

Für die Messagen weise ich ein MessageHandle zu

FMessageHandle := Classes.AllocateHWnd(ProcMessage);

In der Function ProcMessage werte ich nun die Events aus.

Delphi-Quellcode:

if (iEventCode = EC_COMPLETE) or (iEventCode = EC_USERABORT) then // Event is reached
begin
  MediaControl.Stop;                          // Player Stopped
  SetMediaStreamPos(0);                       // Streamposition set to zero
  FPlayerState := psSTOPPED;                  // PlayerState is stopped
  if Win32MajorVersion >= 6 then             
    AllowMonitorPowerdown;                    // SetThreadExecutionState continuous
  if Assigned(FEventNoticeFunc) then          // if Event registerd > NULL
    FEventNoticeFunc(PlayEnded);              // send the Event

Wenn mir nun DirectShow die Message EC_COMPLETE oder bei Fehler EC_USERABORT dann reagiere ich darauf.
Siehe Code.

Ich wüsste jetzt nicht wie ich das noch besser machen sollte.
Das ist mein einziger Thread!

gruss

[Zacherl]

Zitat von 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.

Ja, also die Callback Funktion muss zwingend die stdcall Konvention besitzen (weil das bei dir in der Dll ja auch der Fall ist). Beim Funktionszeiger Typedef scheint es wohl egal zu sein (wundert mich eigentlich, weil die C++ Compiler in der richtigen Konfiguration eigentlich sehr pingelig sind). Warum dein Kontakt die Calling Convention hier zwanghaft weglassen will, leuchtet mir aber trotzdem nicht ein. Ziemlich gefährlich, wenn er mal selbst eine Variable dieses Typs im C++ Programm zuweisen will und außerdem aus Korrektheitsgründen einfach falsch. Ohne stdcall bleibt es wie man es dreht und wendet der falsche Typ.

[EWeiss]

Na ja seine Meinung ist halt das er schon sehr lange sich mit Callbacks beschäftigt
und MF das genauso machen würde deshalb will er stdcall nicht.

OK sei's drum. Ich lasse es drin weil es einfach richtig aussieht. LOL

gruss

[TiGü]

Was ist denn MF? Media Foundation?

[OlafSt]

Ich tippe mal, das hier "MFC" gemeint ist. Microsoft Foundation Classes.

MFC ist aber nur eine Bibliothek für Windows-Controls, so wie die VCL in Delphi auch nur eine Bibliothek ist. Das hat nix mit C++ zu tun (die MFC wurde damals für Visual C (ohne ++) entwickelt), so wie die VCL auch nicht "Delphi" ist.

[EWeiss]

Zitat von TiGü:

Was ist denn MF? Media Foundation?

Richtig!
Es geht ja um das abspielen von Media Dateien.

gruss