NetSurf GEM - erste Bilder

[m0n0]

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:


Ein Directory Listing wird dargestellt



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.

[Atari060]

Das sieht ja schonmal SEHR vielversprechend aus!

TOLLE ARBEIT DIE DU DA MACHST!

 

[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?

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

[m0n0]

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

[tost40]

Hallo m0n0,

klasse Arbeit!!!

Gruss Martin

[caesar]

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.

[Heinz Schmidt]

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

[gstoll]

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

[m0n0]

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?

[HelmutK]

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?

[m0n0]

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

[HelmutK]

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.

[Arthur]

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.

[m0n0]

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....

[HelmutK]

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.

[m0n0]

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









Die NetSurf Homepage


Darf natürlich auch nicht fehlen, leider werden von NetSurf keine Hintergrund Bilder unterstützt, so das das Logo nicht zu sehen ist.


NetSurf eignet sich auch als Image Viewer
 

[Atari060]

  Wow, echt cool... wird wohl ein Weihnachtsgeschenk 

[Mathias]

m0n0 Du bist der Beste!

Bittebitte dranbleiben (und wenn der GEM-Port fertig ist, JavaScript im Netsurf-Team vorantreiben  )!


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, ... 

[Atari060]

Hast Du schon "online- Unterstützung" integriert... wenn Du einen Beta Tester brauchst...

[Heinz Schmidt]

Wow, sehr beeindruckende Bilder. So gut hat Atari-home.de noch mit keinem Atari Browser ausgesehen. Ich bin schwer beeindruckt!

Gruß Heinz