aber sehr bildlich!

_________________
Selber Denken macht klug!

Bezüglich CPU-Auslastung:

Leider weis ich nicht wie WaitForSingleObject genau funktioniert, aber setz doch hinter deinem WaitForSingleObject ein Sleep(Intervall - 5). Vieleicht geht dann die CPU - Auslastung runter und Du hast trotzdem die hohe Genauigkeit.

KidPaddle

_________________
http://www.seban.de

Trotzdem noch 10-24% CPU auslastung... :´(
Liegt am Interval Wenn ich meine SkinEngine alle 33 msecs neu zeichnen lassen... dann frisst dat schon 20% und die anderen 4% kommen von Bass.

Ich habs halt auf 333 sekunden gemacht.
Bloss beim Analyzer wirds scheisse... der braucht nen Interval von 40 msecs... und muss einige komplexe sachen berechnen.

matane,
Final

Ähm Moment mal! Lässt du dein Fenster alle 33 MSec neu zeichnen? :blink:

Also wenn ja, dann solltest du das DRINGENST ändern! Das macht man doch net! Man zeichnet die Fenster nur neu, wenn sich auch etwas geändert hat. Und die resultierunde CPU Last kommt natürlich nicht von dem Thread sondern von dem Fenster neu zeichnen. Du solltest dann deine Skinengine in sofern umstellen, dass sie das OnPaintEvent (WM_PIANT) verwendet.

Jop, aber nun ist es so... ich Lass nur die Grundform über OnPaint zeichnen...
Die Procedure wo ausgeführt wird im Threat macht folgendes:



Nur so zur Info, die Engine funktioniert so... es werden Dynamische TControl wie z.b. TImage erstellt und diese dann mit Daten gefüllt.

und beim Rendern einer Progressbar zum Beispiel, ist die Compo eine TImage.
und wird nur dann gezeichnet wenn die Renderprocedure aufgerufen wird:


Sag jetzt nicht das ist unnötig mit das ich die Controls Dynamisch erstelle...
Das bringt erhebliche Vorteile wenn du z.b. nen Mediaplayer wie Xenorate programmierst.

Weil ich hatte es die ganze zeit satt, immer meine SkinEngine zu ändern, falls ein neues Control her musste.
So muss ich nur noch die Standardtypen wie Progressbars, Buttons, Checkboxen, Listboxen usw. Dynamische erstellen... und diese werden dann auch noch Dynamisch angepasst.

Aber mal was anderes... wann wird denn genau das Erreignis OnPaint durchgeführt ???
und wann das erreignis WM_PAINT, und was ist der unterschied zwischen diesen beiden ???

Danke,

matane,
Final

Nö. Warum sollte ich das tun?


Ich weiß nicht wie groß Bass_Pos ist aber du könntest schon wesentlich mehr sparen, wenn du die Position in Prozente (oder Pixelbreite deiner Progressbar z.B.: 200) umwandelst. Und dann nur updatest, wenn sich die Position auch verändert hat.

Vorteil 1. Du würdetst das jetzt nur zeichnen, wenn sich auch wirklich etwas getan hat.
Vorteil 2. Wenn der Maximalwert von Bass_pos eine Million beträgt und deine Progressbar ca 100 bis 200 Pixel breit ist. Dann macht ein neues zeichnen ja keinen Sinn, wenn sich die Position um 20 Punkte verschoben hat. Das wäre zwar eine veränderung aber sie wäre nicht sichtbar.
Verstehst du, was ich damit sagen will? Nach möglichkeit nur dann zeichnen, wenn sich auch wirklich nur etwas sichbares getan hat. Das ist programmiertechnischer Mehraufwand. Zahlt sich aber am Ende aber aus. Und das nicht zu knapp.


Also OnPaint und WM_PAINT sind das selbe. OnPaint ist lediglich nur die Delphikappselung davon.
OnPaint wird immer dann aufgerufen, wenn der Teil eines Fensters (Fenster, Button, alles was ein Handel hat) gezeichnet werden muss. Sprich, wenn sich die Sichtbarkeit eines Fensters ändert. Du verschiebst ein Fenster außerhalb des Bildschirmes. Es wird nicht neu gezeichnet. Du ziehst es wieder herrein und es wird neu gezeichnet. Und zwar weil jetzt einige Pixel sichtbar sind die vorher nicht sichtbar sind. Genau das selbe bei 2 Fenstern.

Bass_Pos ist leider nen Int64 wert, was ziemlich viel speicher frisst... deswegen musste ich auch meine Progressbar anpassen also Max, Min, Position auch auf int64.

Ich werd mal den Analyzer integrieren... und nen zweiten Thread nehmen den ich auf 40 msecs setze...
die Statusbar mach in den Thread mit rein... hoffe das läuft dann gut. Also max. 10% CPU auslastung wäre schon cool wenn nen Lied abgespielt wird.

Was meinst OpenGL für das kleine Analyzer fensterchen ??
Vorteile, man könnte viele tolle sachen machen... mit effekten rumspielen und so und halt 3D

matane,
Final

Okay int64 ist dann doch ziemlich groß. Ich würde aber auf jeden Fall erst einmal die 20% CPU last wegmachen bevor ist mich dort an 3D mache. Weil schau dir nur mal WinAmp als "Vorbild" an. Wenn das Teil abspielt hat der bei mir 2% CPU-Last. Versuche einfach so viel wie möglich unnötige last zu vermeiden, dann passt das mit der Auslastung schon fast von ganz alleine.

Jop, das werde ich in dieser neuen Engine versuchen...
Ich werde auf jedes Byte Speicher achte... und versuchen berechnungen nur dann auszuführen, wenn das teil läuft.
Ich sags ist echt hart nen Player zu schreiben...
hast du dir eigentlich mal die aktuelle Xenorate version angeschaut und mal Auslastung verglichen ??
Winamp ist halt wohl oda übel komplett durchdacht... wurden bestimmt design scripts geschrieben und alles vorher geplant. Wenn ich daran denke das ich das bei der jetzigen Xenorate version nicht gemacht habe und einfach drauf los gecodet habe, ist mein Player ja gar nicht so schlecht.

Ich finde ausser vom Equalizer,Auslastung und Plugins hat mein Player Winamp schon übertroffen.
Meiner hat nämlich nen besseren Video modus, bzw auch DVD modus... Winamp hat nur nen fakigen Video modus der stinkt. <- Hmm, ich bin überhaupt keeeeinn winamp gegner... nööö wie kommt ihr darauf... *g*

matane
Final

Ähm naja. Ich will ja nicht schon wieder wieder moppern, aber du musst ja nicht peinlich darauf achten wie viel Speicher du verwendest. Das macht bei heutigen System nicht viel aus. So ich denke da mal an mind 128MB Ram in einem Computer. Es komt halt immer darauf an wie du das verhältniss zwischen Speicher und CPU-Auslastung triffst. Das mit dem Int64 meinte ich weil er an dieser Stelle einfach eine zu große Auflösung hat und deswegen zu oft Dinge macht die so oder so niemand sieht. :-/ Das da ein paar Bytes mehr Speicher verbraten werden spielt überhaupt keine Rolle.

Da schlägt die Softwareentwicklung mal wieder zurück. Ich merke das Beruflich auch immer wieder. Wenn man kein Konzept ausarbeitet und nicht bis ins kleinste detail plant, dann kommen immer wieder echt scheiß Probleme auf einen Zu. Das was ich jetzt privat entwickle. Da habe ich mir auch schon unzählige gedanken gemacht. Ich habe zwar nichts schriftliches. Aber ich habe das teilweise schon bis in sehr kleine Details (Speicherstruktur von meinen Daten) geplant. Und abgesehen davon, dass mir die Zeit fehlt läuft es eigentlich ganz gut.

Ich muss gestehen, dass ich mir deinen Player noch nicht angeschaut hatte, weil ich ein absoluter WinampFan bin. Bis auf den 3er.
Und für Videos und DVD verwende ich den Zoomplayer. Die sind beide vollkommen frei und auf ihrem Gebiet (Winamp = Sound, ZoomPlayer = Video) einfach oberaffengeil.
Werde ich aber gleich nach holen.

in dem tutorial fehlt gänzlich das thema

Semaphoren!

warum ich das nenne? weil multithreading auch mit semaphoren zu tun hat! man muss sie zwar nicht erklären, aber ein verweis am rande wäre nicht schlecht..

noch 2 dinge:


auf single-cpu systemen ja, auf multi-cpu systemen wird es wirklich gleichzeitig ausgeführt (bei N prozessoren können auch N threads gleichzeitig ausgeführt werden -> vorallem wird hier dann syncronisation wichtig! man sollte eine multithreading anwendung auch auf mutli-cpu systemen testen!!!)



nicht nur der.. jede anwendung ist ein prozess, der einen eigenständigen thread startet, nämlich das was wir dann zu sehen bekommen. bei delphi anwendungen wird automatisch dann der thread fürs message-handling erzeugt..

_________________
http://www.rochus.net

Richtig da war ja noch etwas. Allerdings war es von mir auch nicht angedacht, dass ich alles über das Thema Multithreading erzähle. Weil ich erstens auch nicht alles weiß (semaphoren) und zweitens es einem "unbedachten" Programmierer vollkommen verwirren.



Mea Culpa. Hatte vergessen zu erwähnen, dass dies nur für einen Proz gilt. Die Probleme und Schwierigkeiten die dabei auftreten können sind aber die Selben.


Hatte ich das nicht erwähnt???

zum letzten punkt: eigentlich schon

_________________
http://www.rochus.net

vielleicht hättest du auch das mutex-objekt nennen sollen, mit dem du die deadlock situationen umschippern kannst, da alle threads das selbe objekt benutzen und auch windows selbst ein mutex objekt freigeben kann, wenn der thread vorzeitig terminiert..

_________________
http://www.rochus.net

Wie ich bereits oben schon einmal erwähnt hatte, war das Tutorial dazu gedacht Programmierern den Einstieg in die Welt der Threads etwas zu erleichtern. Meines erachtens ist es für einen Prgrommierer, der sich damit überhaupt nicht auskennt, schon schwer genug ohne, dass er die kompletten Möglichkeiten in sein Gehirn gestopft bekommt. Und als du damit angefangen hast, da wurde dir auch nicht gleich erzählt, was eine Mutex oder Semaphore ist, oder täusche ich mich da jetzt? Und aus dem Grund habe ich die auch rausgelassen. Dieses Tutorial war nicht dazu gedacht, Leuten die davon schon Ahnung haben noch mehr Ahnung zu geben! Die Leute die davon Ahnung haben, hätten sich das so wieso nicht durchgelesen. Allerdings, wenn du der Meinung bis, dass du so viel Ahnung hast, warum schreibst du dann nicht ein Folgetutorial bzw. ein Tutoruial über Multiprocessing???
Denn ich werde es nicht tun, da das Wissen in dem Tutorial für 95% aller Anwendungsfälle ausreichen sollte!

Und wenn man das Thema ausführlich behandeln wollte, dann würde das locker ein ganzes Buch füllen! Und das war mir dann doch zu viel arbeit!