Performance-Probleme

[FireBird]

Ich werde es am Abend ausprobieren.

[Elle4u]

[quote=""FireBird""]Wenn es Dir dort besser gefällt... [/quote]
War nur eine Idee.

Denn sonst wird ja nach jedem Tastendruck 100ms gewartet auch wenn Filer nicht sichtbar ist, oder?

Ach ne... war glaube ich ein Denkfehler..
"KeyEventLock" wird ja nur bei eingeblendetem Filer gesetzt... kan also bleiben wo es ist

[ibbi]

[quote=""asrael""]Ich habe mir bisher immer gedacht, dass damit der Keycode an die anderen TAPs weitergegeben wird (die dann die Ereignisart selbst aber auf firmware-magische Art und Weise bekommen) und man so auch die gedrückte Taste prinzipiell verfälschen könnte.[/quote]

Das habe ich auch gedacht, aber interessanterweise habe ich Tasten stets mit TAP_GenerateEvent() manipuliert, nie direkt über param1. Jetzt frage ich mich: Wieso eigentlich?

[FireBird]

[quote=""ibbi""]Das habe ich auch gedacht, aber interessanterweise habe ich Tasten stets mit TAP_GenerateEvent() manipuliert, nie direkt über param1. [/quote]
Hast Du sie damit manipuliert oder einen weiteren Event ausgelöst?

[ibbi]

[quote=""FireBird""]Hast Du sie damit manipuliert oder einen weiteren Event ausgelöst?[/quote]

Ich glaube, ich habe einen Key-Event ausgelöst und dann mit return 0 beendet. Allerdings müsste ich mal alle meine Sourcen (speziell die Test-TAPs) nach param1 = durchsuchen. Ich kann nicht glauben, dass ich den Return-Wert noch nie manipuliert habe.

[ibbi]

[quote=""asrael""]Ich habe mir bisher immer gedacht, dass damit der Keycode an die anderen TAPs weitergegeben wird (die dann die Ereignisart selbst aber auf firmware-magische Art und Weise bekommen) und man so auch die gedrückte Taste prinzipiell verfälschen könnte.[/quote]

[quote=""FireBird""]Ich werde es am Abend ausprobieren.[/quote]

Klappt (erwartungsgemäß).

[FireBird]

Das Testen hat erwartungsgemäß geklappt, aber das Ergebnis sieht nicht so aus, wie von mir vorhergesagt. Mit dem return lässt sich sehr wohl steuern, welchen param1 das nächste TAP zu sehen bekommt. Folgend die Ausgaben von 2 Test-TAPs. Ich drücke die Tasten 1 bis 6 und das Einser-TAP produziert von den Tasten abhängig verschiedene Return-Codes.

Code: Alles auswählen

KeyEvents1: param1 = 00010001  return param1
KeyEvents2: param1 = 00010001 

KeyEvents1: param1 = 00010002  return RKEY_NoUse
KeyEvents2: param1 = 0001000d  


KeyEvents1: param1 = 00010003  return 0
KeyEvents2: param1 = 00000000  


KeyEvents1: param1 = 00010004  GenerateEvent (EVT_KEY, RKEY_1, 0); return 0
KeyEvents2: param1 = 00000000  
KeyEvents1: param1 = 00010001  
KeyEvents2: param1 = 00010001  


KeyEvents1: param1 = 00010005  return 1
KeyEvents2: param1 = 00000001  


KeyEvents1: param1 = 00010006  return 0x100
KeyEvents2: param1 = 00000100 

Jetzt muss ich noch den Beitrag finden, auf den ich mich bezog, sonst war’s das mit der Reputation. ops: :

[ibbi]

[quote=""FireBird""]Jetzt muss ich noch den Beitrag finden, auf den ich mich bezog, sonst war?s das mit der Reputation. ops: [/quote]

Es steht höchstens die Reputation des Beitragsschreibers auf dem Spiel. Du bist über jeden Zweifel erhaben.

[asrael]

[quote=""ibbi""]Es steht höchstens die Reputation des Beitragsschreibers auf dem Spiel. Du bist über jeden Zweifel erhaben. [/quote]

Selbstverständlich ist er das. Aber ich bin doch froh, dass ich noch nicht völlig senil bin und mich meine Erinnerung nicht trog.

Um wieder On Topic zu kommen: Kann es dann nicht doch sein, dass auch ein Idle-Event besser möglichst immer weitergegeben würde? Ich stelle mir immer noch vor, dass, wenn ein TAP sich ein Idle-Event schnappt und dann return 0 sagt, die anderen TAPs darunter leiden könnten.

mfg

asrael

[FireBird]

[quote=""asrael""]Kann es dann nicht doch sein, dass auch ein Idle-Event besser möglichst immer weitergegeben würde? Ich stelle mir immer noch vor, dass, wenn ein TAP sich ein Idle-Event schnappt und dann return 0 sagt, die anderen TAPs darunter leiden könnten.[/quote]
Was ist die Alternative? return param1? param1 ist beim Idle-Event auch 0.

[ibbi]

[quote=""asrael""]Ich stelle mir immer noch vor, dass, wenn ein TAP sich ein Idle-Event schnappt und dann return 0 sagt, die anderen TAPs darunter leiden könnten.[/quote]

FireBird schrieb doch, dass dies nicht der Fall ist. Es würde auch mein (TAP-)Weltbild zerstören, wenn man IDLE-Events blocken könnte. (Na gut, sicher kann man die blocken, aber das gehört dann in die Kategorie "Wie programmiere ich eine Endlosschleife".)

return param1 erscheint mir optisch richtiger (was immer ich damit meine ), aber es ändert nichts am Verhalten des TAPs.

[FireBird]

[quote=""ibbi""]erscheint mir optisch richtiger (was immer ich damit meine )[/quote]
Keine Sorge, ich verstehe Dich schon.

[asrael]

[quote=""FireBird""]Was ist die Alternative? return param1? param1 ist beim Idle-Event auch 0.[/quote]

OK, jetzt habe ich verstanden

Da stand ich etwas auf der Leitung.

mfg

asrael

[chrisly]

[quote=""asrael""]
Weitere Tests ergaben folgendes: wird filer relativ spät gestartet (also z. B. nach improbox), ergab sich genau oben beschriebenes Verhalten. Wird filer relativ früh gestartet (bei mir aber nach nicedisplay und fastskip), läuft alles recht normal.

Da relativ viele von Euch ja Probleme mit der Performance haben, die elle nicht nachvollziehen kann, lohnt sich vielleicht mal ein Umstellen der Startreihenfolge. [/quote]

Ich habe ja leider auch diese Probleme, allerdings ist es schon deutlich besser geworden beim Filer (3PG ist inzwischen das Hauptproblem ... ).
Deshalb habe ich gehofft, dass o.g. Hinweis was bringen könnte. Aber ich kann das nicht bestätigen. Egal, ob Filer als erstes oder letztes TAP gestartet wird - es hakt beim Live-TV und insbesondere, wenn auch noch eine Aufnahme läuft.
Aber wie gesagt: es war schon schlimmer und es ist auch nicht ständig der Fall!

Ich habe allerdings noch nicht die Beta 6 drauf, bei der die temprec-Datei nicht mehr mitgescannt wird. Ich hoffe also noch auf eine Verbesserung ... (zumindest beim Filer - bei 3PG ist wohl nicht mit einer Besserung zu rechnen).

So ganz kapiere ich sowieso nicht, wieso bei lfd. Wiedergaben alles in Ordnung ist, es bei Live-TV aber hakt (gilt auch für 3PG, wenn Filer nicht geladen ist!).
Hat irgendjemand noch eine Erklärung für dieses Verhalten? Es kann ja dann nicht nur am temprec-Scan liegen ...

[urmel]

Die Performance-Probleme haben mich gezwungen, nach einem kurzen Blick auf Filer 2.xx wieder zu Filer 1.xx zurückzukehren. Nach Aufspielen und Neustart hat es ewig gedauert bis Improbox geladen wurde. Ein Scrollen in Filer war gar nicht möglich. Nach dem ersten Tastendruck blieb alles hängen.

Was wurde denn geändert und haben alle diese Erfahrung? Einige scheinen Filer 2.xx ja nutzen zu können. Da ich ungern darauf verzichten möchte, bitte ich Elle4U um eine Antwort. Könnte der neue Style die Probleme aufwerfen?

[StevieC]

[quote=""urmel""]Könnte der neue Style die Probleme aufwerfen?[/quote]

Nö, aber der erste Start dauert immer länger, da die DB erstellt werden muss.

Gruß

StevieC

[Elle4u]

Wärend des erstens Scans ist alles ganz langsam und träge da die DB aufgebaut wird.

In dieser Zeit ist aber auch links oben ein Scan-Symbol zu sehen (siehe Anleitung für 2.00 Beta 6).

[chrisly]

Nur zur Info:

Es gibt letzte (! ) Neuigkeiten zu den Performanceproblemen:

viewtopic.php?t=7388

Vielleicht habt Ihr ja ´ne Idee dazu ...

[Elle4u]

Darauf gehe ich nicht mehr ein

[chrisly]

Da kannst Du (und wahrscheinlich auch sonst niemand) wohl eh nix dran ändern ...

Außerdem wollte ich das böse Wort ("Scro...") in diesem Thread niiiiiie mehr erwähnen ...
(nicht, dass Du irgendwann bei mir vor der Tür stehst (ist ja nicht so weit weg)