FastSwitch

[EWeiss]

Zitat von Furtbichler:

Eine Sekunde ist aber happig. Wenn der Ladevorgang zu lange dauert, dann müssen sie vorher geladen werden (imho). Aber ich hab ja die Anwendung nicht vor mir, kann das also nur aus der Ferne (grob) beurteilen.

Du machst das schon.

Frohes Fest zurück.

Wir haben es nun so gelöst..
Ob das elegant ist mag dahingestellt sein

Code:

        case Action.ActionType.ACTION_PAGE_UP:
          {
            var timeSpamVerif = DateTime.Now - _lastAction;
            if (timeSpamVerif.TotalSeconds >= 2)
            {
              _validAction = true;
            }
            else
            {
              _validAction = false;
            }
            if (FullScreen && CurrentAudioStream != 0)
            {
              Log.Debug("BASS: Switch to Previous Vis");
              if (_validAction)
              {
                _lastAction = DateTime.Now;
                VizManager.GetPrevVis();
              }
            }
            break;
          }

        case Action.ActionType.ACTION_PAGE_DOWN:
          {
            var timeSpamVerif = DateTime.Now - _lastAction;
            if (timeSpamVerif.TotalSeconds >= 2)
            {
              _validAction = true;
            }
            else
            {
              _validAction = false;
            }
            if (FullScreen && CurrentAudioStream != 0)
            {
              Log.Info("BASS: Switch to Next Vis");
              if (_validAction)
              {
                _lastAction = DateTime.Now;
                VizManager.GetNextVis();
              }
            }
            break;
          }

wobei die 2 Sek. nicht variabel sind was wiederrum einen Deadlock auslösen könnte
wenn die Plugins zu schnell geändert werden da ich nur einen Thread zur Verfügung stelle.
Ist also Zeit abhängig und von PC zu PC unterschiedlich.
Hmmmm...

In der IDE funktioniert es mit 1 Sekunde als Eigenständige Ausführung dann nicht mehr deshalb 2 Sek.
Aber auch das könnte zu Problemen führen.
Was gäbe es da noch für eine Möglichkeit.

Timer wollen die nicht warum auch immer...

Und auf Änderung bzw. addieren eines KeyUp Events wurde gemeckert.
Was eigentlich die eleganteste und richtige Lösung wäre da man dann gezwungen wäre diesen erst loszulassen
damit das nächste Plugin geladen wird.

gruss

[Namenloser]

Wie werden die Plugins denn geladen und entladen? Wenn jedes Plugin einfach eine zentrale Finalize-Routine hätte, die man vom Programm aus aufrufen kann, dann würde das Programn ja automatisch so lange blockieren, bis alles sauber aufgeräumt ist.

Bei statischen Wartezeiten bin ich immer sehr skeptisch... in 5 Jahren bremst die Konstante das Programm auf aktuellen Rechnern dann unnötig aus. Gleichzeitig kann es durch Paging usw. immer mal vorkommen, dass der Prozess doch länger braucht.

[EWeiss]

Zitat:

Wenn jedes Plugin einfach eine zentrale Finalize-Routine hätte

Die habe ich ja BassVis_Quit.. bzw. BassVis_Free
Aber das nutzt überhaupt nichts wenn 1000 mal in einer sekunde versucht wird ein neues Plugin zu starten.

Wenn der Thread sich beendet werden gleichzeitig 100 neu aufgerufen..
Ich weis nicht wie ich das verhindern kann innerhalb meiner DLL.

Zitat:

Bei statischen Wartezeiten bin ich immer sehr skeptisch... in 5 Jahren bremst die Konstante das Programm auf aktuellen Rechnern dann unnötig aus. Gleichzeitig kann es durch Paging usw. immer mal vorkommen, dass der Prozess doch länger braucht.

Die weigern sich halt einen Eintrag für die Wartezeit in den Konfigurations Dialog einzutragen
mit dem Argument um so mehr Einstellungen eingefügt würden um so schlechter käme der User damit zurecht.
Für mich hört sich das an als würden die User für Dumm erklärt.

gruss

[Namenloser]

Achso, dann verstehe ich das. Dann müsste es doch aber genügen, vor dem Aufruf der Finalize-Routine ein globales Flag auf False zu setzen und hinterher auf True. Und wenn die "Nächstes Plugin laden"-Methode aufgerufen wird, während das Flag False ist, dann bricht die Methode ab (oder wartet, bis das Flag wieder True ist). Natürlich noch threadsafe, das ganze. Läuft dann eigentlich auf ganz einfaches, normales Locking hinaus. Übersehe ich etwas?

[EWeiss]

Zitat von Namenloser:

Achso, dann verstehe ich das. Dann müsste es doch aber genügen, vor dem Aufruf der Finalize-Routine ein globales Flag auf False zu setzen und hinterher auf True. Und wenn die "Nächstes Plugin laden"-Methode aufgerufen wird, während das Flag False ist, dann bricht die Methode ab (oder wartet, bis das Flag wieder True ist). Natürlich noch threadsafe, das ganze. Läuft dann eigentlich auf ganz einfaches, normales Locking hinaus. Übersehe ich etwas?

Werde das mal testen
Normalerweise hab ich so was nicht gebraucht wenn die Anwendung die Lib Ordnungsgemäß behandelt.
Wie ein normal Mensch darauf kommen kann einfach den Button (taste) gedrückt zu halten ist mir unbegreiflich.

Danke.

EDIT:
Funktioniert leider nicht!
Wenn die so schnell umgeschaltet werden kommt mein Thread nicht mehr mit
Bei normalen gebrauch hingegen gibt es keine Probleme.


gruss

[Furtbichler]

Wieso verwendest Du nicht einfach einen separaten Thread zum Laden des nächsten Plugins. Dieser Thread meldet, wenn er fertig ist und ein weiteres Plugin laden kann. Während der Thread beschäftigt ist, kann man eben nicht scrollen. Das ersetzt deine statische Konstante.

Wenn ich eine Liste von Dingern habe, bei denen ich nur alle 2 Sekunden weiterklicken kann, ist das -mit Verlaub- unzumutbar. Das sind doch bloß irgendwelche DLL, was soll daran 2 Sekunden dauern?

[EWeiss]

Zitat von Furtbichler:

Wieso verwendest Du nicht einfach einen separaten Thread zum Laden des nächsten Plugins. Dieser Thread meldet, wenn er fertig ist und ein weiteres Plugin laden kann. Während der Thread beschäftigt ist, kann man eben nicht scrollen. Das ersetzt deine statische Konstante.

Wenn ich eine Liste von Dingern habe, bei denen ich nur alle 2 Sekunden weiterklicken kann, ist das -mit Verlaub- unzumutbar. Das sind doch bloß irgendwelche DLL, was soll daran 2 Sekunden dauern?

Genau das möchte ich verhindern.. Die Anwendung soll nicht Multithread fähig sein.
Also es soll und darf nicht mehr als ein Plugin zur gleichen zeit geladen werden.

Die meckern ja schon wenn die eine last von 20% CPU haben was soll das erst geben wenn man 2 gleichzeitig starten kann.

Mein Problem ist eigentlich ganz einfach zu erklären.
Der Thread ist nicht beendet wenn das neue Plugin startet.
bzw.. der nächste BeginThread aufgerufen wird.

Wie kann ich garantieren das dieser vorher 100% beendet wurde.

Zitat:

Das sind doch bloß irgendwelche DLL, was soll daran 2 Sekunden dauern?

Wenn man das so Pauschal sagen könnte ja, ist aber nicht der Fall

Ist es möglich das WaitForSingleObject Probleme macht?

Delphi-Quellcode:

    hEvent := CreateEvent(nil, True, False, nil);
    PostThreadMessage(RenderThreadId, WM_QUIT, 0, hEvent);
    WaitRe := WaitForSingleObject(hEvent, 1000);
    CloseHandle(hEvent);

im Thread signalisiere ich wenn er beendet wurde
  SetEvent(Msg.LParam);

Das trifft aber nicht rechtzeitig ein egal ob ich jetzt 1 oder 10 Sekunden übergebe


gruss

[BUG]

Zitat von EWeiss:

Wie ein normal Mensch darauf kommen kann einfach den Button (taste) gedrückt zu halten ist mir unbegreiflich.

Das deutet darauf hin, das dass Navigieren durch die PlugIns umständlich ist. Ich würde das auch versuchen.

Um nochmal Furtbichlers ersten Vorschlag anzusprechen: Du solltest auf keinen die Benutzerschnittstelle verlangsamen; damit wirkt einfach dein Programm fehlerhaft.
Eher solltest du den Nutzer so schnell umschalten lassen, wie er möchte, und dann etwas verzögert das PlugIn nachladen (also wenn er sich "entschieden" hat).

[EWeiss]

Zitat von BUG:

Zitat von EWeiss:

Wie ein normal Mensch darauf kommen kann einfach den Button (taste) gedrückt zu halten ist mir unbegreiflich.

Das deutet darauf hin, das dass Navigieren durch die PlugIns umständlich ist. Ich würde das auch versuchen.

Um nochmal Furtbichlers ersten Vorschlag anzusprechen: Du solltest auf keinen die Benutzerschnittstelle verlangsamen; damit wirkt einfach dein Programm fehlerhaft.
Eher solltest du den Nutzer so schnell umschalten lassen, wie er möchte, und dann etwas verzögert das PlugIn nachladen (also wenn er sich "entschieden" hat).

Mittlerweile hatte er mir ja einen anderen Vorschlag unterbreitet aber da komme ich nicht mit klar bzw. müsste dann extrem viel ändern da meine Threads auf API ausgelegt sind.

So schnell wie man dann die Plugins läd können diese sich gar nicht initialisieren.
Also der User würde in dem Fall gar nicht sehen was er da laden bzw. in dem Moment für ein Plugin erwischt.

Das ist auch der grund warum man unter Winamp diese aus einer Liste unter Konfiguration wählen muss.
Ein umschalten zur Laufzeit ist gar nicht möglich.

Werde da wohl dann nichts ändern wenn die Anwendung meinen Wrapper so missbrauchen will
dann ist es letztendlich nicht mein Problem da in diesem Fall die Handhabung nicht durchdacht ist.

gruss