atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: m0n0 am Do 14.10.2010, 15:26:14
-
Hallo,
ich weiss es sieht noch längst nicht so schön aus wie bei der Framebuffer version - aber ich bin ungeduldig und ich wollte euch trotzdem an meinen Entwicklungs-Tätigkeiten am GEM port von NetSurf teil nehmen lassen :)
Gerendert werden die Webseiten bisher nur mit einem VDI Renderer, d.h. nur 256 Farben (bzw. 216 - die WebSichere Palette), nur Systemfonts, und der Inhalt muss immer neu gerendert werden sobald ein vorher verdeckter Bereich sichtbar wird ( mangels fehlender Offscreen bitmaps im Standard VDI - auf NVDI möchte ich ja verzichten!) .
Hauptsächlich wurde dieser Renderer dafür gemacht mich bei der Entwicklung zu unterstützen, also
ich kann Kontrollieren ob mein Scrolling code, update von Fenster Bereichen, Textausgabe etc. korrekt
funktioniert. Aber es kann später auch mal als Fallback Lösung genutzt werden wenn die Direkten
Renderer die vorhandene Hardware nicht unterstützen.
Hier zwei screenshots:
(http://freeshell.de/~monokrom/tmp/snap000.jpg)
Ein Directory Listing wird dargestellt
(http://freeshell.de/~monokrom/tmp/snap003.jpg)
Mehrere Fenster und resize ist natürlich möglich.
FOlgendes steht momentan auf meiner TODO Liste:
- Frames implementieren
- Direkte Renderer implementieren
- Bookmarks
- Besserer SSL Dialog
- Text innerhalb webseite Suchen / Copy und Paste
Ich habe die nächsten 2 Wochen noch Zeit, danach muss dieses Projekt zurückstecken, aber ich hoffe trotzdem das ich bis zur Auslieferung der Firebee eine Version habe die eigentlich nur noch für die Firebee angepasst werden muss... mal schauen ob das was wird.
-
Das sieht ja schonmal SEHR vielversprechend aus!
TOLLE ARBEIT DIE DU DA MACHST!
:) :) :)
-
Hallo M0n0,
eine tolle Idee und kaum zu glauben mit was für Sprüngen Du immer voran schreitest. Noch ein paar Fragen zu deiner todo Liste:
1. Konnte NSFB nicht schon mit Frames umgehen oder verwechsele ich da was?
2. Was meinst Du mit "Direkte Renderer implementieren"?
3. Und was hällst Du von Tab's, die sind ja mittlerweile sehr beliebt und sehr praktisch allerdings auf den Ataris vielleicht schwer zu realisieren?
Ich schließe mich Atari060 an...einen tollen Job machst du da.
FOlgendes steht momentan auf meiner TODO Liste:
- Frames implementieren
- Direkte Renderer implementieren
- Bookmarks
- Besserer SSL Dialog
- Text innerhalb webseite Suchen / Copy und Paste
Gruß Arthur
-
Hallo M0n0,
eine tolle Idee und kaum zu glauben mit was für Sprüngen Du immer voran schreitest. Noch ein paar Fragen zu deiner todo Liste:
1. Konnte NSFB nicht schon mit Frames umgehen oder verwechsele ich da was?
2. Was meinst Du mit "Direkte Renderer implementieren"?
3. Und was hällst Du von Tab's, die sind ja mittlerweile sehr beliebt und sehr praktisch allerdings auf den Ataris vielleicht schwer zu realisieren?
1. Die erste Alpha vom Framebuffer Port konnte, meine ich, noch mit Frames umgehen...
Nun ist es aber so das der Frame Code im NetSurf umgeschrieben wird, so das Momentan jede
Entwicklerversion keine Unterstuetzung von Frames bietet, soweit ich das Verstanden habe und
sofern der Port keine besonderen Massnahmen ergreift...
Von daher stellt sich auch die Frage ob es Sinn macht nun Frames zu implementieren...
denn spaeter soll das alles vom Kern gehandelt werden, so
das sich die Eigentliche GUI nicht darum kuemmern muss... was
natuerlich auch bedeutet das keine Nativen-Scrollbars zu sehen
sein werden, sondernd die vom Core selbst gezeichneten. Also erstmal abwarten.
2. Direkte Renderer: Anstatt VDI funktionen wie circle oder
rectangle aufzurufen muessen diese Formen durch eigenen Code
in den Bildschirmspeicher geschrieben werden, was aufgrund der
Vielzahl von Bildschirmspeicherformaten nicht ganz Trivial ist.
Und man muss natuerlich wissen wie man einen Kreis per Code
zeichnen kann, also ohne VDI... Ich werde fuer die Konvertierung
in verschiedene Formate die Hermes Library nutzen... Aber es wird
auch kein Problem sein neue Formate hinzuzufuegen, diejenigen die von Hermes
nicht unterstuetzt werden oder assembler optimierte routinen, das heisst aber natuerlich zusaetzlichen
Programmieraufwand...
3. Tabs habe ich erstmal aussen vor gelassen. Es ist nicht so das
der Weg dorthin verbaut ist, aber ich kuemmere mich erstmal
nicht darum. Kommt vielleicht spaeter :) aber es ist halt auch
so das jedes Fenster seinen Speicher benoetigt, tabs verleiten
ja dazu das man viele Seiten offen hat, und auch jeder Tab
benoetigt seinen Bildschirmspeicher...
Gruss,
m
-
Hallo m0n0,
klasse Arbeit!!! :D
Gruss Martin
-
Das ist ja mal was Interessantes! Ich benutze NetSurf auf meinem Acorn seit langem und bin mit dem Leistungsumfang ganz zufrieden. Bin gespannt, wie es weitergeht mit der GEM Implementation.
-
Wow, ich bin total platt was Du so schnell auf die Beine stellst. Schreibst Du das GUI eigentlich komplett neu, oder kannst Du z.B. von HighWire noch Code verwenden?
Gruß Heinz
-
mangels fehlender Offscreen bitmaps im Standard VDI - auf NVDI möchte ich ja verzichten!
Mit Offscreen bitmaps, meinst Du wahrscheinlich alle Funktion die vorhanden sind falls der Cookie EdDI da ist? Also dafür gibt es extra Zusatzprogramm um die Funktionen auch ohne NVDI zur Verfügung zu stellen.
Einzig möglicher Nachteil: Mir ist i.M. nur bekannt, daß die Versionsnummer 1.00 unterstützt wird.
Gerhard
-
Hallo Gerhard,
das klingt natürlich sehr Interessant! ( Das wäre doch auch evt. um GemDict ohne NVDI laufen zu lassen, oder? :) )
Aber ich glaube letztendlich ist es besser eigene Routinen dafür zu verwenden anstatt auf die VDI Funktionen zurückzugreifen... Trotzdem danke für die Info... welche Programme meinst Du genau? Ist auf jedenfall interessant - aber sind die auch open source?
-
Hallo Gerhard,
das klingt natürlich sehr Interessant! ( Das wäre doch auch evt. um GemDict ohne NVDI laufen zu lassen, oder? :) )
Aber ich glaube letztendlich ist es besser eigene Routinen dafür zu verwenden anstatt auf die VDI Funktionen zurückzugreifen... Trotzdem danke für die Info... welche Programme meinst Du genau? Ist auf jedenfall interessant - aber sind die auch open source?
Also um verdeckten Fensterinhalt sichtbar zu machen braucht man aber keine offscreen-bitmaps. Die braucht man doch nur, wenn der Inhalt sich im verdeckten Zustand geändert hat, oder man will im Hintergrund zeichnen, und dann alles auf einmal zeigen. Normal reicht doch vro_cpyfm, oder sehe ich da was falsch?
-
Hallo,
also erstmal: der Ausdruck direkter renderer war etwas ungluecklich
gewaehlt... ich meinte damit halt in ein offscreen bitmap zeichnen
und bei bedarf den Inhalt des offscreen bitmaps in den bildschirmspeicher
kopieren. VDI ist eigentlich direkter, da es ja direkt in den Bildschirm schreibt,
ohne ein Offscreen bitmap zu nutzen...
zu vro_cpyfm:
Prinzipiell wuerde das natuerlich gehen, aber das bedeutet das ich eine Liste der Bereiche
die gerendert wurden verwalten muesste, denn es werden nur die Bereiche gerendert die
Sichtbar sind. Man kann nicht davon ausgehen das das Fenster
beim Rendern komplett sichtbar war..., nach dem Rendern muessten diese Bereiche dann
gespeichert werden, was zusaetzlichen Zeit-Aufwand durch malloc bedeutet...
Diese Liste koennte man dann beim Sichtbar werden eines Bereiches
abarbeiten und schauen ob der neu Sichtbar gewordene Bereich schon in der Liste
vorhanden ist... Fuer mich klingt das nach vielen Dingen die
Dabei schief gehen koennen und nach Artefakten, letzlich ist
es mir zu viel Aufwand, da es ja eh nur fuer den VDI renderer waere -
mit einem eigenen Offscreen renderer der eh die Komplette page
rendern kann, ohne Ruecksicht auf momentan Sichtbare Bereiche,
entfaellt das Problem ja eh...
Gruß,
m
-
Hallo,
also erstmal: der Ausdruck direkter renderer war etwas ungluecklich
gewaehlt... ich meinte damit halt in ein offscreen bitmap zeichnen
und bei bedarf den Inhalt des offscreen bitmaps in den bildschirmspeicher
kopieren. VDI ist eigentlich direkter, da es ja direkt in den Bildschirm schreibt,
ohne ein Offscreen bitmap zu nutzen...
zu vro_cpyfm:
Prinzipiell wuerde das natuerlich gehen, aber das bedeutet das ich eine Liste der Bereiche
die gerendert wurden verwalten muesste, denn es werden nur die Bereiche gerendert die
Sichtbar sind. Man kann nicht davon ausgehen das das Fenster
beim Rendern komplett sichtbar war..., nach dem Rendern muessten diese Bereiche dann
gespeichert werden, was zusaetzlichen Zeit-Aufwand durch malloc bedeutet...
Diese Liste koennte man dann beim Sichtbar werden eines Bereiches
abarbeiten und schauen ob der neu Sichtbar gewordene Bereich schon in der Liste
vorhanden ist... Fuer mich klingt das nach vielen Dingen die
Dabei schief gehen koennen und nach Artefakten, letzlich ist
es mir zu viel Aufwand, da es ja eh nur fuer den VDI renderer waere -
mit einem eigenen Offscreen renderer der eh die Komplette page
rendern kann, ohne Ruecksicht auf momentan Sichtbare Bereiche,
entfaellt das Problem ja eh...
Gruß,
m
Wie gesagt: Wenn der verdeckte Bereich noch nicht gezeichnet wurde, muss er natürlich beim Freiwerden neu gezeichnet werden.
Nach Deiner Beschreibung brauchst Du aber sowieso für jedes Fenster so eine offscreen-bitmap. Warum nicht für jedes Fenster einen screenbuffer anlegen, und die Rechtecke dann entsprechend blitten. Solange der Inhalt sich nicht zwischenzeitlich geändert hat, sollte das funktionieren. Falls doch, wird es natürlich kompliziert.
Ich denke, in den meisten Fällen ist das Fenster, in das gezeichnet wird, oben, so dass auch alles dargestellt wird. Falls etwas verdeckt ist, kann man sich das merken, und entweder die verdeckten Bereiche in einer Liste speichern oder das ganze Fenster immer neu malen.
Wie sieht das zB aus, wenn unter XaAES das drop-down-menu über einem netsurf-Fenster ist? Dann müssten die jeweils freigewordenen Bereiche ja jedesmal neu gezeichnet werden, oder? Dafür könnte man immerhin einen screen-buffer für das ganze Programm vorsehen, auch für den Fall, dass ein Fenster von einem anderen Programm etwas von netsurf freigibt.
Hab ich jedenfalls mal so gemacht: Einen globalen buffer, und jeweils einen für die langsamen Fenster (immer nur nur die letzten 3 um Speicher zu sparen). Dann beim blitten entweder über Rechteckliste oder falls das bremst (denke nicht), diese selber speichern
Nach jedem redraw wird der gezeichnete Bereich in beide buffer kopiert. Läuft auch auf dem TT schnell genug.
Das ist nicht allzu viel Aufwand, aber wenn Du sowieso offscreen-bitmaps verwenden willst, dann wird das evtl. später überflüssig.
-
Ich habe es bei m0n0 genau so gedacht wie Du es gerade erklärt hast. Sonst müsst ja jedes mal ein kompletter Redraw gemacht werden und dann gute nacht.
-
Hallo,
natürlich muss beim Frei werden von Fensterhbereichen kein kompletter Redraw gemacht werden... sondernd nur der Bereich der Frei geworden ist... habe mich etwas falsch ausgedrückt, die wird natürlich nur einmal gerendert ( oder halt öffters wenn DHTML mit im Spiel ist), und entsprechende Bereiche aus dem Rendering Ergebniss können dann neu gezeichnet werden.
Wie sieht das zB aus, wenn unter XaAES das drop-down-menu über einem netsurf-Fenster ist? Dann müssten die jeweils freigewordenen Bereiche ja jedesmal neu gezeichnet werden, oder? Dafür könnte man immerhin einen screen-buffer für das ganze Programm vorsehen, auch für den Fall, dass ein Fenster von einem anderen Programm etwas von netsurf freigibt.
Hab ich jedenfalls mal so gemacht: Einen globalen buffer, und jeweils einen für die langsamen Fenster (immer nur nur die letzten 3 um Speicher zu sparen). Dann beim blitten entweder über Rechteckliste oder falls das bremst (denke nicht), diese selber speichern
Ja, OK, daran habe ich noch nicht so genau gedacht... würde ja auch durchaus Sinn machen....
-
Wie sieht das zB aus, wenn unter XaAES das drop-down-menu über einem netsurf-Fenster ist? Dann müssten die jeweils freigewordenen Bereiche ja jedesmal neu gezeichnet werden, oder? Dafür könnte man immerhin einen screen-buffer für das ganze Programm vorsehen, auch für den Fall, dass ein Fenster von einem anderen Programm etwas von netsurf freigibt.
Hab ich jedenfalls mal so gemacht: Einen globalen buffer, und jeweils einen für die langsamen Fenster (immer nur nur die letzten 3 um Speicher zu sparen). Dann beim blitten entweder über Rechteckliste oder falls das bremst (denke nicht), diese selber speichern
Ja, OK, daran habe ich noch nicht so genau gedacht... würde ja auch durchaus Sinn machen....
Diese Funktion übernimmt ja normalerweise das AES, nur XaAES halt nicht.
Letztlich ist wahrscheinlich offscreen-bitmap die beste Lösung, man muss halt vorher wissen, ob's nicht auch einfacher geht.
-
Einen Offscreen Renderer habe ich zwar noch nicht implementiert, aber dafür gibt es jetzt ein paar Screenshot in denen die Fonts mit FreeType2 gerendert werden, ausserdem werden Bilder unterstützt, natürlich auch Transparenz ;)
Leider gibt es noch ein Problem mit den Umlauten, aber es gibt ja schlimmeres ;)
(http://nic-nac-project.org/~monokrom/monochrom.net/atari/img/nsprev/1.jpg)
(http://nic-nac-project.org/~monokrom/monochrom.net/atari/img/nsprev/2.jpeg)
(http://nic-nac-project.org/~monokrom/monochrom.net/atari/img/nsprev/3.jpeg)
(http://nic-nac-project.org/~monokrom/monochrom.net/atari/img/nsprev/4.jpeg)
Die NetSurf Homepage
(http://nic-nac-project.org/~monokrom/monochrom.net/atari/img/nsprev/5.jpeg)
Darf natürlich auch nicht fehlen, leider werden von NetSurf keine Hintergrund Bilder unterstützt, so das das Logo nicht zu sehen ist.
(http://nic-nac-project.org/~monokrom/monochrom.net/atari/img/nsprev/6.jpeg)
NetSurf eignet sich auch als Image Viewer ;)
-
:o Wow, echt cool... wird wohl ein Weihnachtsgeschenk ;D
-
m0n0 Du bist der Beste!
Bittebitte dranbleiben (und wenn der GEM-Port fertig ist, JavaScript im Netsurf-Team vorantreiben >:D )!
Ich wundere mich nur, was ich unter Linux falsch mache, daß das Rendering mit Netsurf total trashig ist? Das Layout bei Deinen Versionen ist um Welten besser als hier live mit Ubuntu, ... ???
-
Hast Du schon "online- Unterstützung" integriert... wenn Du einen Beta Tester brauchst... :)
-
Wow, sehr beeindruckende Bilder. So gut hat Atari-home.de noch mit keinem Atari Browser ausgesehen. Ich bin schwer beeindruckt!
Gruß Heinz
-
Respekt! Das hat echt Potential!
-
Hast Du schon "online- Unterstützung" integriert... wenn Du einen Beta Tester brauchst...
Klaro hat das schon Online-Unterstützung. Aber bei den Entwicklungsarbeiten wurde ein Bug im FreeMinT Kernel entdeckt... das heisst entweder inet4.xdd austauschen, oder kernel updaten. Und letztere möglichkeit ist eigentlich die einzigst richtige... Aber ich werde auch ein gefixtes inet4.xdd bereitstellen.
Das Problem hat sich so geäussert, das eine Verbindung nicht immer korrekt erstellt wurde, bzw. die Verbindung fehlerhaft als "Verbunden" angesehen wurde... woraufhin NetSurf Daten senden will, was aber noch garnicht geht... Das endet dann in einem Fehler und NetSurf (bzw. cURL) gibt sofort auf es weiter zu versuchen...
Ich wundere mich nur, was ich unter Linux falsch mache, daß das Rendering mit Netsurf total trashig ist? Das Layout bei Deinen Versionen ist um Welten besser als hier live mit Ubuntu, ...
Versuchst Du selber zu kompilieren? Ansonsten, das Paket bei Ubuntu ist veraltet... müsste eigentlich mal geupdatet werden. Aktuell ist Version 2.6
Ausserdem ist unter GTK die Pango Library für das Font Rendering zuständig, die wrappt Freetype nochmal... und ich glaube da gabs mal Probleme, ich meine das ist in der aktuellsten Version behoben.
-
Ähm nur soeine Idee! Aber soein Phenomen kenne ich!! Bei der Konfiguration via DHCP!
Es scheint alles richtig Konfiguriert, dennoch gehen keine Pakete raus!
-
Kann gut sein das es das selbe Problem ist. ...Aber ich glaube... DHCP, arbeitet das nicht mit dem UDP Protokoll, bei dem eh keine Verbindung hergestellt wird...? Hm... wenn ja, dann ist es etwas anderes.
-
Nein, also es ist so das alles korrekt eingerichtet ist! Auch IP Vergeben worden ist und anscheinend alles Funktionieren sollte. Dennoch gehen keine Pakete raus oder rein. Dieses Phenomen habe ich schon sehr oft beobachtet, das erste mal ist es mir bei Aranym aufgefallen.
-
Dann ist das höchst wahrscheinlich ein anders Problem oder ein folgefehler von den einzelnen Programmen...
-
Hi Mono,
ich bin offiziell beeindruckt.
Weiter so, tolles projekt und hervorragende Resultate !
-
Neue Features:
- Such Dialog zum Suchen innerhalb der Webseite
- Download Dialog zum Herunterladen von Webseiten
- Datei Upload ( dies ist ein Test)
Gruß,
m0n0
P.S. Fehlt nur noch der Falcon CT60 zum Testen bevor ich eine Beta veröffentliche ;)
-
Meinen allergrößten Respekt!
Wo war m0n0 egtl früher? Man hätte ihn immer brauchen können. Auch auf der mint ML und im IRC ist er immer da.
Mensch, danke für Dich und Deine große Leidenschaft!
-
Kann man sich NetSurf GEM schon fix und fertig (binary) wo downloaden und klappts auch schon online?
P.S. Kleiner Verbesserungsvorschlag:
Die Pfeile vor und zurück gehören direkt nebeneinander das home hat dazwischen nichts zu suchen. ;)
-
Also das mit den Pfeilen finde ich so richtig! Links Vor Rechts !! Warum solll man der Masse nach gehen? Atari ist doch anders oder?
-
Also wie dir Buttons aufgereit sind, ist eher geschmakssache oder eine (an)gewohnheit.
ausserdem gehe ich davon aus das hier
http://freeshell.de/~monokrom/monochrom.net/atari/img/nsfb_sc_2.jpg
aktuelleScreenshots sind, und da ists doch passabl.
nen donwload hast auf der Seite auch.
Hab ich aber noch nicht ausprobiert
Gruß Matthias
-
Wieso macht man die Türklinke dahin wo sie ist...weil es sich bewährt hat. wenn ich also vor und zurück blättere sind die Mauswege kürzer wenn die Pfeile nah beieinander sind.
Warum solll man der Masse nach gehen? Atari ist doch anders oder?
Wie meinste das denn nu? Wegen mir kannste die Pfeile auch 30cm auseinander anordnen wenn das Atarilike sein soll...von mir aus... :P
-
Bezüglich der Bilder: Die anordnung kann ja jeder selber mit dem ResourceMaster veraendern :P
Matashen: Die screenshots und downloads Die Du meinst sind alt und haben so gut wie nichts mehr gemein mit dem port dessen Bilder ich hier gepostet habe. Die GEM Version ist ein komplett eigener Port. Der renderer hat sogar ein kleines Feature mehr - er unterstützt tiled Bitmaps. (Also wer CSS kennt: x-repeat und y-repeat). Ausserdem ist er Port GEM basiert - dadurch werden solche Features werden solche Features wie Drag n Drop + mehrere Fenster erst moeglich :)
Fuer Netzwerk brauch man allerdings FreeMiNT...
-
Kann man sich NetSurf GEM schon fix und fertig (binary) wo downloaden und klappts auch schon online?
Schieb
-
Hallo,
eigentlich wollte ich ja schon release machen, aber...
1. Soll will ich noch alle libraries für ColdFire im Kasten haben... (das ist echt eine scheiss arbeit alle libraries zu kompilieren und als RPM zu verpacken - dauert ewig... :/ Wenn jemand das kann, wäre ich über hilfe sehr dankbar... )
2. Kann sich jeder die Sourcen aus dem SVN saugen und einen eigen Build erstellen ;)
P.S. eigentlich wollte ich ja nochmal selbst auf einem Falcon CT60 testen 8) ;D
... Ansonsten ist es aber bald soweit für eine GEM Alpha Version :)
http://source.netsurf-browser.org/trunk/netsurf/atari/
-
Netsurf für Gem wäre so genial.
Habe sowohl Cab als auch Highwire und Draconis versucht.
Selbst auf meinem Amd 1090T 6 Core Prozessor unter Magic PC ist an ein vernünftiges Browsen nicht zu denken...
Go on, please! :)
-
Zustimm... :)
Feine Sache mOnO !!!