Software > Software (16-/32-Bit)

NetSurf GEM - erste Bilder

(1/8) > >>

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.



--- Zitat von: m0n0 am Do 14.10.2010, 15:26:14 ---
FOlgendes steht momentan auf meiner TODO Liste:
- Frames implementieren
- Direkte Renderer implementieren
- Bookmarks
- Besserer SSL Dialog
- Text innerhalb webseite Suchen / Copy und Paste


--- Ende Zitat ---

Gruß Arthur

m0n0:

--- Zitat von: Arthur am Do 14.10.2010, 17:03:30 ---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?


--- Ende Zitat ---

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!!! :D

Gruss Martin

Navigation

[0] Themen-Index

[#] Nächste Seite