amiga-news 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:
TAGLIST workbuf&, _
   DTA_SourceAddress&,  MemAdr&,_
   DTA_SourceSize&,     MemSize&,_
   DTA_SourceType&,	DTST_Memory&,_
   DTA_GroupID&,	GID_PICTURE&, _
   PDTA_Screen&, 	NULL&, _
   PDTA_Remap&,		TRUE&, _
   PDTA_DestMode&,      1&, _
  TAG_END&
  REM dtobjekt& = NewDTObjectA& (SADD("hd2:test.gif"+CHR$(0)), workbuf&)
  dtobjekt& = NewDTObjectA& (NULL&, workbuf&)


[ - 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:
Original von Thore:
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.


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: 7650
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: 8038
Nutzer
Zitat:
Original von MaikG:
Schade, könnte man höchstens noch über das Clipboard
gehen.
Ich hatte ebend noch das akgif.datatype Installiert, damit gehts
auch nicht.

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: 8038
Nutzer
Zitat:
Original von MaikG:
Hab ich momentan mit Ram:t, aber eigentlich ist das unnötiger overhead.
Es geht um tausende gifs, wenns eins wäre kein thema.

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: 262
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: 8038
Nutzer
Zitat:
Original von MaikG:
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.

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: 8038
Nutzer
Zitat:
Original von MaikG:
Die Bilder dsin nicht auf einen Festspeicher, die kommen aus dem
Netzwerk. Gleich verarbeiten ist deswegen schneller als erst speichern und dann wieder laden.

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:
Da ich parallel noch andere Sachen mache (100% CPU) lässt sich da auf anderen wege nichts optimieren.
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: 8038
Nutzer
Zitat:
Original von MaikG:
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.

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: 8038
Nutzer
Zitat:
Original von MaikG:
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".

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:
Ja und was muss ich benutzen ohne das DTs bilder im
Speicher aktzeptieren? Die Ram-Disk.

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 © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.