|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > DTST_Memory | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
03.12.2008, 21:40 Uhr MaikG Posts: 5172 Nutzer |
DTST_Memory will bei mir nicht so recht  Gebe ich keinen Namen "" oder NULL& an Funktioniert gar nichts. Gebe ich irgendeine Datei im selben Format an wird die Datei benutzt aber nicht die Daten im Speicher die ich möchte. Mach ich was falsch oder ist der gif.datatype 44.4 (08.08.99) der neuen Funktion nicht mächtig? code: [ - Antworten - Zitieren - Direktlink - ] |
|
03.12.2008, 23:22 Uhr Thore Posts: 2266 Nutzer |
Vergeb mal einen Namen der keine Datei darstellt, z.B. "MyPic" oder so. Eigentlich sollte der Parameter bei DTST_Memory ignoriert werden? Die 3 essentiellen Parameter hast du ja angegeben. Mach mal als DestMode PMODE_V43 rein (ich weiß grad nicht auswendig was die 1 bedeutet) Ich denk der DTST ist Bestandteil der v44 picture.datatype und dürfte damit auch mit jeder Sub-Datatype (z.B. gif) funktionieren. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 00:09 Uhr MaikG Posts: 5172 Nutzer |
>Vergeb mal einen Namen der keine Datei darstellt, z.B. "MyPic" oder >so. funktioniert auch nicht. >Eigentlich sollte der Parameter bei DTST_Memory ignoriert werden? Genau aber umgekehrt wird auch die Speicheradresse benutzt wenn ein existierendes Bild angegeben wird. Liegt an der Speicheradresse kein Bild gehts auch nicht. >Mach mal als DestMode PMODE_V43 rein (ich weiß grad nicht auswendig was die 1 bedeutet) 1 sollte PMODE_V43 sein, funktioniert mit Datei ja. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 09:14 Uhr Thore Posts: 2266 Nutzer |
Ich hoff das Bild liegt schon im richtigen Format im Speicher, und die Adresse und die Größe stimmen? Hast Du es mal mit einer anderen Programmiersprache probiert? Der Code sieht aber eigentlich richtig aus. Hab auch bisher keine Beispielsourcen gefunden. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 11:04 Uhr MaikG Posts: 5172 Nutzer |
Zitat: Ja, liegt genau im Speicher wie es auch in der Datei geschrieben wurde und von da wieder geladen. In einer anderen Sprache bringt mir das leider nichts. Die Includes musste ich ergänzen, evtl. ist da was falsch: DTST_Memory = 5 DTA_SourceAddress = 0x80001027 DTA_SourceSize = 0x80001028 Letzte beiden von DTA_Repeat abgeleitet welches den wert 0x80001026 hat. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 11:13 Uhr Thore Posts: 2266 Nutzer |
DTST_Memory = 5 DTA_SourceAddress = DTA_Dummy+39 DTA_SourceSize = DTA_Dummy+40 DTA_Dummy = TAG_USER + 0x1000 TAG_USER ist ((ULONG)(1L<<31)), also 0x80000000 Damit stimmen Deine Werte Ich hoffe damit konnte ich helfen (und hab mich nirgends verguggt oder verrechnet) [ Dieser Beitrag wurde von Thore am 04.12.2008 um 11:14 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 12:39 Uhr thomas Posts: 7718 Nutzer |
@MaikG: DTST_MEMORY scheint nicht zu funktionieren oder ist zumindest auch bei den Datatype-Klassen, die bei OS 3.9 dabei sind, nicht implementiert. Ich habe gerade mal das Beispiel aus dem NDK ausprobiert. Da hat sich der Autor selbst angeschmiert. Das macht nämlich genau das, was du auch geschrieben hast: wenn ein Dateiname angegeben ist, wird die Datei geladen, wenn nicht, geht's schief. Der Autor hat natürlich immer den Namen der Datei angegeben, die er vorher geladen hat. Dementsprechend wird das Bild immer angezeigt, aber nicht aus dem Speicher, sondern aus der Datei. Wenn man das Programm so ändert, daß ein anderer Name (oder gar keiner) angegeben wird, dann gibt's auch kein Bild. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 13:15 Uhr MaikG Posts: 5172 Nutzer |
@Thomas Danke. Schade, könnte man höchstens noch über das Clipboard gehen. Ich hatte ebend noch das akgif.datatype Installiert, damit gehts auch nicht. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 16:02 Uhr Thore Posts: 2266 Nutzer |
Scheint auch eher ein Problem der Oberklasse picture.datatype zu sein, und nicht von dem darunterliegenden gif.datatype. Vielleicht gibt es eine funktionierende Version? Ab v44 soll es laut Dokumentation klappen... [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 16:15 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was genau willst Du denn machen? Im Normalfall ist die Ram-Disk genau der richtige Ort für den Datenaustausch, wenn eine Komponente nur mit Dateien funktioniert. Clipboard und GIF-Dateien geht nicht wirklich zusammen... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.12.2008, 16:31 Uhr Thore Posts: 2266 Nutzer |
Wenn Du keine extra GIF Datei mitliefern möchtest, dann baue sie direkt ins Programm ein, und erstell daraus eine Datei nach T: oder RAM:T, und öffne dann diese Datei per NewDTObject. Ansonsten weiß ich nicht was schlimm dran ist, eine Datei mit dieser Methode zu öffnen =) [ - Antworten - Zitieren - Direktlink - ] |
|
05.12.2008, 11:14 Uhr MaikG Posts: 5172 Nutzer |
>Was genau willst Du denn machen? Momentan die Geschwindigkeit erhöhen. >Im Normalfall ist die Ram-Disk genau der richtige Ort für den >Datenaustausch, wenn eine Komponente nur mit Dateien funktioniert. >Clipboard und GIF-Dateien geht nicht wirklich zusammen... Die Ram-Disk ist nicht grade schnell und Dateioperationen kosten Zeit. >Wenn Du keine extra GIF Datei mitliefern möchtest, dann baue sie >direkt ins Programm ein, und erstell daraus eine Datei nach T: oder >RAM:T, und öffne dann diese Datei per NewDTObject. >Ansonsten weiß ich nicht was schlimm dran ist, eine Datei mit dieser >Methode zu öffnen =) Hab ich momentan mit Ram:t, aber eigentlich ist das unnötiger overhead. Es geht um tausende gifs, wenns eins wäre kein thema. [ - Antworten - Zitieren - Direktlink - ] |
|
05.12.2008, 11:31 Uhr Thore Posts: 2266 Nutzer |
Was genau hast Du denn vor? Vielleicht gibt es einen besseren/anderen Weg? Tausende GIFs so im Speicher halten ist ja auch nicht die wahre Lösung, oder die ausführbare Datei dermaßen aufzublähen. Kommt auch immer auf die Größe der Bilder an. [ - Antworten - Zitieren - Direktlink - ] |
|
05.12.2008, 12:23 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ergibt keinen Sinn. Irgendwo müssen diese GIFs ja herkommen. Also liegt der Overhead ganz woanders. Es sei denn, Du schaffst es mal, ordentlich zu erklären, was Du eigentlich machen willst. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.12.2008, 12:46 Uhr Thore Posts: 2266 Nutzer |
Wenn es dein Geheimnis bleiben soll... versuch mal aus, die GIFs in eine große Grafik zu halten und sie intern als Clips auszuschneiden (z.B. mappen auf eine vorher reservierte, nicht sichtbare BitMap, dann mit BltBitMap oder ClipBlit die Einzelgrafiken davon wegkopieren) Es kommt ja auch noch drauf an wie Du die Grafiken anzeigen willst. [ - Antworten - Zitieren - Direktlink - ] |
|
06.12.2008, 10:17 Uhr Wishmaster Posts: 140 Nutzer |
MaikG wieder mal in Hochform. Will Hilfe haben, sagt aber nicht genau worum es geht und alle müssen raten was er vor hat. -- Pegasos MorphOS [ Dieser Beitrag wurde von Wishmaster am 06.12.2008 um 10:17 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
06.12.2008, 16:41 Uhr geit Posts: 332 [Ex-Mitglied] |
Ich hab mich damit auch mal rumgeschlagen und es gibt im OS3.9 SDK sogar ein Beispiel das zu funktionieren scheint. Tut es aber nicht. Das Teil hat einen fallback, das die Datei nachläd, wenn DST_Memory fehlschlägt, was immer passiert. Alles was ich dazu sagen kann ist, dass ich es unter 3.9 nicht hinbekommen habe und meine Bilder als Workaround in t: gespeichert, geladen und wieder gelöscht habe. In meinem Fall waren das maximal 16 16x16 Pixel Bilder von Sony Playstation MemoryKarten und somit nicht wirklich problematisch. Geit [ - Antworten - Zitieren - Direktlink - ] |
|
07.12.2008, 11:31 Uhr MaikG Posts: 5172 Nutzer |
>Was genau hast Du denn vor? Vielleicht gibt es einen besseren/anderen >Weg? Tausende GIFs so im Speicher halten ist ja auch nicht die wahre >Lösung, oder die ausführbare Datei dermaßen aufzublähen. Kommt auch >immer auf die Größe der Bilder an. Ist immer nur ein GIF im Speicher das wird dann wieder rausgeschmissen, weil nur ein gif zu einer Zeit benötigt wird. Optimieren könnte man ebend nur noch den Dateizugriff alles andere ist schon Optimiert. Das ist jetzt zwar nicht soo wichtig aber wäre halt schön gewesen auf den Disk zugriff zu verzichten. [ - Antworten - Zitieren - Direktlink - ] |
|
07.12.2008, 18:33 Uhr akl Posts: 265 Nutzer |
@MaikG: http://aminet.net/search?query=dtimage [ - Antworten - Zitieren - Direktlink - ] |
|
07.12.2008, 18:46 Uhr Thore Posts: 2266 Nutzer |
Entweder du lädst alles in den Speicher, oder du lädst es von Festplatte/Diskette... Die RAM Disk ist viel schneller als die Festplatte, aber da ist eben der verfügbare Speicher das "Übel" (Ich erninner mich an "tausende" GIFs). Wenn dein Programm also auch auf nem 4MB Amiga laufen soll, musst du das planen. Niemand kann sich so recht vorstellen was genau Du vorhast, daher können wir nur Vorschläge machen, über das was wir und so denken. Wie groß sind denn die Grafiken (BxHxT)? Werden die nur kurz dargestellt bis die nächste Grafik kommt oder länger (wg. Ladezeit...), Werden alle Grafiken immer benutzt oder nur auserwählte pro Programmstart? Diese und andere Kriterien können die Hilfestellungen beeinflussen. @geit: Anscheinend funktioniert DTST_Memory generell nicht, was entweder ein missing feature oder ein Bug in picture.datatype darstellt. [ - Antworten - Zitieren - Direktlink - ] |
|
08.12.2008, 19:12 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was zur Hölle willst Du denn da optimieren? Wenn die Bilder also doch nicht im RAM liegen, musst Du sie laden. So einfach ist das. Oder bildest Du Dir ein, Du könntest Dateien schneller in den Speicher laden als die Datatypes das tun? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2008, 11:02 Uhr MaikG Posts: 5172 Nutzer |
>@MaikG: >http://aminet.net/search?query=dtimage Kann das aus dem Speicher laden? >Niemand kann sich so recht vorstellen was genau Du vorhast, daher >können wir nur Vorschläge machen, über das was wir und so denken. >Wie groß sind denn die Grafiken (BxHxT)? Werden die nur kurz >dargestellt bis die nächste Grafik kommt oder länger (wg. >Ladezeit...), Werden alle Grafiken immer benutzt oder nur >auserwählte pro Programmstart? Diese und andere Kriterien können die >Hilfestellungen beeinflussen. >Was zur Hölle willst Du denn da optimieren? >Wenn die Bilder also doch nicht im RAM liegen, musst Du sie laden. So >einfach ist das. Oder bildest Du Dir ein, Du könntest Dateien >schneller in den Speicher laden als die Datatypes das tun? Die Bilder dsin nicht auf einen Festspeicher, die kommen aus dem Netzwerk. Gleich verarbeiten ist deswegen schneller als erst speichern und dann wieder laden. Größe ca. 200x100x8. Da ich parallel noch andere Sachen mache (100% CPU) lässt sich da auf anderen wege nichts optimieren. [ Dieser Beitrag wurde von MaikG am 09.12.2008 um 11:02 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2008, 14:17 Uhr Thore Posts: 2266 Nutzer |
Hmm mir dämmert langsam was Du vorhast, und ich hab mal was ähnliches angefangen. Jetzt versteh ich Dich auch ein wenig (wenns das ist was ich vermute). Das allerbeste wär in diesem Fall, mehrere Bilder zu laden, zu puffern, und dann anzuzeigen. Wenn es das ist was ich vermute, ist die beste Möglichkeit, ein Assembler-Inline zu machen, das die GIFs in Rohdaten wandelt, und auf eine Bitmap im "Tile"-Verfahren kopiert, und komplett auf Datatype-Handling zu verzichten. (Oder alternativ eine BASIC Routine dafür entwerfen, ist nicht so schwierig, gibt halt 2 Arten von GIFs) Dann mappst Du den Bereich mit ClipBlit oder BltBitMap auf den RastPort des Ausgabeelements/-fenster. Das ist die schnellste Art und Weise (außer die Daten werden direkt gerendert ohne Zwischenstation auf eine weitere Bitmap, nur dann flackerts eben) Was Du dann auch machen solltest ist einen DoubleBuffer zu implementieren, wenn es flackert. Auch das ist nicht weiter schwierig. Viel Glück bei deinem Vorhaben [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2008, 17:10 Uhr Holger Posts: 8116 Nutzer |
Zitat:Unsinn. Ich weiß ja nicht, was Du für ein mordmäßiges Netzwerk zu haben glaubst, aber bislang ist auf jedem Amiga eine lokale Festplatte schneller als eine Netzwerkverbindung. Und wenn man die Daten parallel zum Empfang speichert, geht dabei auch keine Zeit verloren. "gleich verarbeiten" könnte schneller sein, trifft hier aber gar nicht zu, da die Datatypes kein Streaming unterstützen. Das, womit Du noch am dichtesten rankommst, wäre, den http-handler zu benutzen. Damit kannst Du den Datatypes Netzwerk-Ressourcen als Dateien unterschieben, und, sofern das Datatype die Datei tatsächlich stückweise seriell verarbeitet, könntest streaming-ähnliche Performance erreichen. Allerdings befürchte ich, dass die meisten Datatypes erst mal alles in einem Stück einlesen, bevor sie mit dem Verarbeiten beginnen. Zitat:Wenn Du 100% CPU-Last hast, machst Du entweder etwas grundsätzlich verkehrt, oder hast bereits die Leistungsgrenze erreicht. Wenn Du da etwas optimieren willst, solltest Du Dich auf die 100% CPU-Last konzentrieren, und nicht auf die Festplattenoperation. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2008, 11:49 Uhr MaikG Posts: 5172 Nutzer |
>Das allerbeste wär in diesem Fall, mehrere Bilder zu laden, zu >puffern, und dann anzuzeigen. Dadurch entsteht die CPU last nicht. >Wenn es das ist was ich vermute, ist die beste Möglichkeit, ein >Assembler-Inline zu machen, das die GIFs in Rohdaten wandelt, und >auf eine Bitmap im "Tile"-Verfahren kopiert, und komplett auf >Datatype-Handling zu verzichten. Naja, weil ich sowas nicht kann benutze ich ja die Datatypes. >Wenn Du 100% CPU-Last hast, machst Du entweder etwas grundsätzlich >verkehrt, oder hast bereits die Leistungsgrenze erreicht. Wenn Du da >etwas optimieren willst, solltest Du Dich auf die 100% CPU-Last >konzentrieren, und nicht auf die Festplattenoperation. Die CPU last kommt nicht durch das Laden/Anzeigen der Datatypes. Und ich glaub du gibst mir recht wenn ich sage das speichern/laden ist eine arbeit der CPU, denn das übernimmt leider keiner der Customchips. [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2008, 15:17 Uhr Thore Posts: 2266 Nutzer |
Hier ist ein gif Datatype nebst Source, vielleicht kannst Du die Decode-Routinen umsetzen: http://aminet.net/package/util/dtype/gifanimdtc203 Wodurch entsteht denn die CPU Last? [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2008, 10:47 Uhr Holger Posts: 8116 Nutzer |
Zitat:Um Himmels Willen, nein, da gebe ich Dir überhaupt nicht recht. Laden und Speichern sind I/O-Operationen, das heißt prinzipiell wenig CPU-belastend. Das gilt für die alten Disketten, die sehr wohl von den Customchips gesteuert werden, genauso, wie für SCSI-Kontroller und die Deneb-Karte, die alle DMA-unterstützen (die haben ihre eigenen "Customchips"). Die einzigen Ausnahmen sind die RAM-Disk und der interne IDE-Kontroller des A1200/4000. Die erzeugen wirklich CPU-Last. Mmmh, ich kenn mich natürlich nicht mit jedem noch so exotischen 3rd-party Kontroller aus, da gibt's vielleicht auch den einen oder anderen, der pollt. Aber wie gesagt, Du kannst versuchen den http-handler zu benutzen, um die Datatypes direkt aus dem Netzwerk laden zu lassen. Mehr wirst Du nicht am Datatypes-Handling optimieren können. Die CPU-Belastung musst Du woanders suchen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2008, 12:54 Uhr MaikG Posts: 5172 Nutzer |
>Hier ist ein gif Datatype nebst Source, vielleicht kannst Du die >Decode-Routinen umsetzen: >http://aminet.net/package/util/dtype/gifanimdtc203 Eine C->Basic umsetzung lohnt sich nicht dafür. >Wodurch entsteht denn die CPU Last? Berechnungen+2.Task >Um Himmels Willen, nein, da gebe ich Dir überhaupt nicht recht. Laden >und Speichern sind I/O-Operationen, das heißt prinzipiell wenig >CPU-belastend. Doch tust du, ich habe gesagt das es eine CPU arbeit ist im 2.Satz stimmst du dem mit "prinzipiell wenig CPU-belastend" zu. Wenn hätte es heissen müssen "ist keine CPU belastung". >Die einzigen Ausnahmen sind die RAM-Disk und der interne >IDE-Kontroller des A1200/4000. Die erzeugen wirklich CPU-Last. Ja und was muss ich benutzen ohne das DTs bilder im Speicher aktzeptieren? Die Ram-Disk. [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2008, 21:06 Uhr Holger Posts: 8116 Nutzer |
Zitat:Es ist mir echt zu blöd, mit Dir über den Unterschied von "wenig" oder "keine" CPU-Belastung zu diskutieren, wenn Du laut eigener Aussage "100%" Belastung hast, was weder "wenig", noch "keine" ist. Wenn Du optimieren willst, mach es da, wo die "100%" CPU-Belastung erzeugt werden, nicht da wo "wenig" oder "keine" entstehen. Hirn einschalten! Zitat:Liest Du überhaupt, bevor Du antwortest? Ich habe Dich jetzt zwei mal auf den http-handler hingewiesen, der das Zwischenspeichern einsparen könnte. Außerdem hättest Du, wenn Du wirklich verstanden hättest, was wenig CPU-Belastung dank DMA bedeutet, auch begriffen, dass unter Umständen ein ordentlich parallelisiertes Zwischenspeichern auf der Festplatte weniger Overhead als ein Zwischenspeichern in der RAM-Disk erzeugt. Ach ich vergaß, ordentlich programmieren, dass kommt bei Dir nicht in Frage. Nun gut, dann lehnen wir uns jetzt alle zurück und warten, bis Du in Deiner unnachahmlichen Art erklärst, dass Du "die Lösung ganz alleine gefunden hast, weil Dir niemand helfen konnte"... -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2008, 12:01 Uhr MaikG Posts: 5172 Nutzer |
@Holger: Ich sagte bereits das alles andere optimiert ist! Da geht nicht mehr. Das wäre der einzigste punkt wo man ansetzen kann. Das ding?: >Short: HTTP: device for accessing web-hosted files >Author: Chris Young >Uploader: chris unsatisfactorysoftware co uk (Chris Young) >Type: comm/www >Version: 1.9 >Replaces: comm/www/httphandler.lha >Architecture: ppc-amigaos >= 4.0.0 Man beachte die Architecture!!! Nein das speichern auf platte ist trotz DMA langsamer als in Ram, das habe ich bereits gemessen. Davon ab, ich möchte den Krach dabei nicht. Ursprünglich wollte ich nur wissen warum DTST_Memory nicht will, das wäre eine einfache art der Optimierung gewesen. Nach einer komplizierten hab ich gar nicht gesucht, deswegen wird es keine weitere änderung am Programm geben. Das Aufwand/Nutzen Verhältniss muss schon stimmen. [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > DTST_Memory | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|