Allgemeines > Atari - Talk
Entwicklerunterstützung - Atari Browser
m0n0:
--- Zitat ---Das ist aus historischen Gründen nicht ganz der Fall. Gerade in den früheren RAM beschnittenen Zeiten hätte das bedeutet, das zunächst mal die Seite (xxx Bytes) + ein Klone in DOM-Treeformat im RAM gelegen hätte. Deswegen werden zu jeden Tag nur rudimentäre Informationen gespeichert.
--- Ende Zitat ---
Ich habe auch versucht mir das zu erklären und ich bin auch zu diesem Schluss gekommen, jedenfalls teilweise. Man könnte aber ja auch nicht mehr benötigte Teile des Dokument-Speichers wieder freigeben...
Ein anderer Punkt ist die Geschwindigkeit, bei einem Tree Model muss erstmal das Dokument geparst werden und dann würde ein zweites Parsen des trees stattfinden + rendering.
--- Zitat ---Generell kennt aber jedes Tag seinen Anfang und Ende und das sollte sich auch als DOM umarbeiten lassen.
--- Ende Zitat ---
Naja, ich habe an JavaScript elemente wie z.b. mydiv.innerHTML="<b>text</b>"; gedacht, oder an sowas wie div.innerHTML = div.InnerHTML + "eine geänderte website";
das wäre natürlich blöd wenn man deswegen die komplette page neu rendern muesste ... zumal so ein rendering vorgang bei älteren Ataris ja nicht gerade schnell von statten geht :)
Mathias:
--- Zitat von: jh am Mi 12.05.2010, 18:27:54 ---Falsch: Die unvollendete 2.0 hat bereits partiellen CSS Support.
--- Ende Zitat ---
Hallo Jens, schön von Dir zu lesen!
Ganz direkte Frage. Was schätzt Du wie lange dauert es "Dein" Paket auf wirklich aktuellen Stand zu bringen. Und wieviel kostet es wenn Du dafür unbezahlten Urlaub von Deinem derzeitigen Brot-Job nimmst?
guest1994:
--- Zitat von: m0n0 am Mi 12.05.2010, 19:06:16 ---
--- Zitat ---Das ist aus historischen Gründen nicht ganz der Fall. Gerade in den früheren RAM beschnittenen Zeiten hätte das bedeutet, das zunächst mal die Seite (xxx Bytes) + ein Klone in DOM-Treeformat im RAM gelegen hätte. Deswegen werden zu jeden Tag nur rudimentäre Informationen gespeichert.
--- Ende Zitat ---
Ich habe auch versucht mir das zu erklären und ich bin auch zu diesem Schluss gekommen, jedenfalls teilweise. Man könnte aber ja auch nicht mehr benötigte Teile des Dokument-Speichers wieder freigeben...
Ein anderer Punkt ist die Geschwindigkeit, bei einem Tree Model muss erstmal das Dokument geparst werden und dann würde ein zweites Parsen des trees stattfinden + rendering.
--- Ende Zitat ---
Korrekt. Obwohl man da evtl. im ersten Arbeitsschritt ein paar dinge vielleicht sowieso gleich mit erledigen kann, so dass vielleicht nur noch ein minimaler zusätzlicher Renderingprozess nötig ist (Tabellen z.B.)
--- Zitat ---
--- Zitat ---Generell kennt aber jedes Tag seinen Anfang und Ende und das sollte sich auch als DOM umarbeiten lassen.
--- Ende Zitat ---
Naja, ich habe an JavaScript elemente wie z.b. mydiv.innerHTML="<b>text</b>"; gedacht, oder an sowas wie div.innerHTML = div.InnerHTML + "eine geänderte website";
das wäre natürlich blöd wenn man deswegen die komplette page neu rendern muesste ... zumal so ein rendering vorgang bei älteren Ataris ja nicht gerade schnell von statten geht :)
--- Ende Zitat ---
Genau dafür. Wie gesagt, wenn es nicht auf den Speicher ankommt wäre das der Weg und das ließe sich umarbeiten.
Generell wurden auch die verschiedenen Browseralternativen nicht ausschließen. Ich würde allerdings für eine Portierung eine der Mobile Varianten in Erwägung ziehen. z.B. WebKit for Mobile. Die sind meisten deutlich weniger Speicherhungrig, auf schlappe Prozessoren ausgelegt und haben einen kleineren Sourceumfang. Würde aber wahrscheinlich trotzdem bedeuten, dass nur aktuelle HW eine Zielplattform ist. Mit gcc und Mint sollte das aber u.U. machbar sein. Besonders bei Webkit handelt es sich ja um das reine Rendering, so dass das GUI drum rum lediglich hinzugebaut werden müsste.
Machbarkeit????
guest1994:
--- Zitat von: Mathias am Mi 12.05.2010, 19:14:37 ---
--- Zitat von: jh am Mi 12.05.2010, 18:27:54 ---Falsch: Die unvollendete 2.0 hat bereits partiellen CSS Support.
--- Ende Zitat ---
Hallo Jens, schön von Dir zu lesen!
Ganz direkte Frage. Was schätzt Du wie lange dauert es "Dein" Paket auf wirklich aktuellen Stand zu bringen. Und wieviel kostet es wenn Du dafür unbezahlten Urlaub von Deinem derzeitigen Brot-Job nimmst?
--- Ende Zitat ---
Unmöglich und sicherlich unbezahlbar.
m0n0:
--- Zitat ---Generell wurden auch die verschiedenen Browseralternativen nicht ausschließen. Ich würde allerdings für eine Portierung eine der Mobile Varianten in Erwägung ziehen. z.B. WebKit for Mobile. Die sind meisten deutlich weniger Speicherhungrig, auf schlappe Prozessoren ausgelegt und haben einen kleineren Sourceumfang. Würde aber wahrscheinlich trotzdem bedeuten, dass nur aktuelle HW eine Zielplattform ist. Mit gcc und Mint sollte das aber u.U. machbar sein. Besonders bei Webkit handelt es sich ja um das reine Rendering, so dass das GUI drum rum lediglich hinzugebaut werden müsste.
--- Ende Zitat ---
mit GCC... das meinte ich mit "die Rückwärtskompatibilität steht im Wege" ... bei HW ist es ja z.b. so das auch compiler wie lattice C und pure C unterstützt werden, aber das bringt auch viele Probleme mit sich... z.b. können die Libs die von GCC kompiliert werden von keinem der anderen Compiler genutzt werden :( das heisst ALLE source müssen auch mit pure C kompilierbar sein :( Ob das nun mehr Entwickler-Einsatz garantiert als wenn man mehr features aber nur gcc ermöglicht, ist fraglich. Aber ich merke es bei der Java Script library..., es ist eher nervig das teil PureC kompatibel zu machen ;) BUS Error beim Garbage collector, na toll >:D mit GCC lief die Kompilierung/laufzeit ohne auch nur eine Zeile code zu verändern... und es war lauffähig auf einem normalen ST...
WebKit werde ich mal anschauen... aber ich glaube aus irgend nem grund ist das nicht in Frage gekommen, glaube ich.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln