Scrollen mit Word Wrap

[Helmut]

Hm... müsste das nicht doch gehen? Man müsste halt rückwärts suchen, bis man entweder genügend Wörter zusammen hat, um eine Zeile vollzumachen, oder bei längerem Wort als Zeile den ersten möglichen Umbruch findet. Und in letzterem Fall müsste man dann halt das Langwort über Zeilen verteilen und rechtsbündig ausrichten, dann kann man die Zeilen anzeigen. Müsste theoretisch deterministisch sein, also immer die selben Zeilen ergeben.

Es geht schon, aber was du vorschlägst hat viele Nachteile. Zum einen ist das, wie ich ja schon sagte, um ein Vielfaches aufwändiger zu implementieren und zum anderen hat es im worst-case eine katastrophale Performance (und der worst-case scheint hier nicht so unwahrscheinlich zu sein). Man müsste dann nämlich bei jedem Scrollvorgang nach oben die ganze Datei durchgehen. Da ist dann selbst notepad.exe schneller. Man könnte dann natürlich versuchen das mit irgendeinem Cache zu verbessern, aber dann kann man auch gleich die Variante implementieren, bei der man bei jeder Fenstergrößenänderung alle Zeilen berechnet und sich so den Riesenaufwand für die Scrollfunktionen sparen (und hat nebenbei auch wartbareren Code und die Möglichkeit Scrollbars einzublenden)

[Schrompf]

Nein, da haben wir uns wohl missverstanden. Man muss eben nicht durch die ganze Datei zurückgehen, sondern nur, bis entweder die vorherige Zeile oder das Länger-Als-Zeile-Wort voll sind.

- Zeilenanfang
- rückwärts losmarschieren, Darstellungsbreite der Symbole aufsummieren
- akkumulierte Darstellungsbreite erreicht verfügbaren Platz
- bin ich immernoch beim ersten Wort?
---> es ist ein Mehr-Als-Zeile-Langes-Wort
---> bis zum Anfang des Wortes weitersuchen
---> dessen Anfang als Zeilenanfang nehmen
---> und im Wort umbrechen, so oft nötig
- ich bin schon bei mehr als einem Wort
---> Die Trennstelle danach ist der Zeilenanfang

Geht natürlich nur, wenn man wirklich nur zeilenweise springt. Sobald man mittendrin den verfügbaren Platz ändert, z.b. durch Fenstergröße, ist die aktuelle Start-Trennstelle links oben, an der sich Vorwärts- wie Rückwärts-Suche ausrichten, nicht mehr zwangsweise auch ganze Zeilen vom Dokumentanfang entfernt. Aber nach meinem Verständnis ist das eh immer ein Problem, egal wie man es angeht. Und Zeilenunterteilung der gesamten Datei sollte ja vermieden werden, wenn ich das Problem richtig verstanden habe. Das wäre allerdings wohl auch mein Ansatz gewesen, weil ich ein fauler Mensch bin.

[Alexander Kornrumpf]

Nein, da haben wir uns wohl missverstanden.

Sei nicht böse, aber ich bin nicht sicher ob du das Problem verstanden hast. Mit überlangen Wörtern hat es eigentlich nichts zu tun.

Beispiel (ohne Leerzeichen wie bei Krishty):

Zeilenbreite: 5
Text: 1231212312345

Darstellung Vorwärts:

12312
123
[*]12345

Darstellung Rückwärts, ab dem bekannten Zeilenanfang [*]:

123
12123
12345

[Schrompf]

Stimmt, da war ich wirklich auf dem falschen Dampfer. Danke!

Bliebe die Überlegung, ob man das nicht aus der (bekannten) Länge der folgenden Zeile ausrechnen kann, dass Rückwärtssuche dort schon trennen muss. Immerhin trennt die Vorwärtssuche das ja nur deswegen so, weil das nachfolgende Wort nicht mehr auf die zweite Zeile geht.

[Alexander Kornrumpf]

Inzwischen habe ich sogar verstanden, was Helmut dachte, dass du gemeint hättest :)

Ist schon witzig, wie jeder ein anderes mentales Modell für den Sachverhalt aufbaut.

Im Rennen scheinen tatsächlich die beiden Lösungen zu sein:

- Neu umbrechen "wenn es nötig ist" und Umbrüche merken. (Mit den hier anfangs genannten Gegenargumenten)
- Naiver Rückwärtsumbruch (Mit den genannten Problemen)

Ist wohl ein Trade-Off.


-

[BeRsErKeR]

Hab mir hier nicht alles durchgelesen. Aber mein Vorschläg wäre einen Monospace-Font zu nutzen. Es reicht dann die Breite der TextBox in Zeichen zu kennen. Dann kannst du an beliebiger Stelle die Position eines Zeichens oder Zeilenanfangs berechnen. Hier wäre das einzige Problem dann ein echter Zeilenumbruch. Man kann aber die Berechnung anstatt auf den Gesamtinhalt dann auf einen Sub-String vom letzten echten Zeilenumbruch an berechnen.

[Alexander Kornrumpf]

Hab mir hier nicht alles durchgelesen. Aber mein Vorschläg wäre einen Monospace-Font zu nutzen. Es reicht dann die Breite der TextBox in Zeichen zu kennen. Dann kannst du an beliebiger Stelle die Position eines Zeichens oder Zeilenanfangs berechnen. Hier wäre das einzige Problem dann ein echter Zeilenumbruch. Man kann aber die Berechnung anstatt auf den Gesamtinhalt dann auf einen Sub-String vom letzten echten Zeilenumbruch an berechnen.

Dein Vorschlag hat mit der Diskussion gar nichts zu tun :) Es gab irgendwann mal ganz am Anfang die Rede von Pixelbreiten, aber darüber sind wir längst hinweg.

[marcgfx]

ich verstehe nicht, wieso der aufbau einer geeigneten datenstruktur hier nicht diskutiert wird. ist das nicht entscheidend um alle operationen hoch/runter/veränderungen in sinnvoller zeit durchzuführen?

[Spiele Programmierer]

Wurde doch?
Eine "geeignete Datenstruktur" würde schnell so groß werden, dass sie nicht mehr in den RAM passt und unglaublich lange aufzubauen dauern. Man denke nur an die Möglichkeit, wenn der Hex Editor auch direkt Datenträger öffnen kann.

Außerdem kostet diese "geeignete Datenstruktur" so oder so Speicher, und das wo Speicher heutzutage das mit großen Abstand langsamste Komponente ist.

Allerdings sehe ich noch ein anderes Problem: Der Scrollbalken(wenn es einen solchen geben soll) der vorhin angesprochen wurde. Um die Dimensionierung dieses Balkens korrekt zu bestimmen, müsste man so oder so die gesamte Datei auslesen. :!:

[marcgfx]

anscheinend kann eh auf den scrollbalken verzichtet werden. wenn die datei allerdings wirklich so riesig sein kann, könnte eine schätzung für einen scrollbalken ausreichen. evtl. könnte auch einfach ein ausschnitt der daten berechnet werden? ein problem scheint ja zu sein, dass wenn man hoch oder runterscrollt unterschiedliche resultate erhält. evtl. in fixe blöcke unterteilen, dann könnte pro block die darstellung konsistent gehalten werden. mit einem übergang zwischen den blöcken müsste man aber leben, ebenso mit halbierten wörtern. die blöcke nummerieren und optisch unterscheiden wäre evtl. sogar praktisch?

[Alexander Kornrumpf]

ich verstehe nicht, wieso der aufbau einer geeigneten datenstruktur hier nicht diskutiert wird. ist das nicht entscheidend um alle operationen hoch/runter/veränderungen in sinnvoller zeit durchzuführen?

Zu jedem Wort zu speichern zu welcher Zeile es gehört (dein Vorschlag) ist offensichtlich aufwändiger als nur die Positionen der Zeilenumbrüche zu speichern.

Wie ich oben schon schrieb: Word speichert solche Dinge. Es war aber da schon klar dass das hier nicht die gesuchte Lösung ist, und Krishty hat dann auch nochmal erklärt weshalb.

Du müsstest schon erklären, welchen Vorteil deine Datenstruktur für das hier diskutierte Problem haben sollte. Ich seh's nicht.

[marcgfx]

@alex: da hast du recht, es ist aufwändiger. ich habs im zusammenhang mit dem resizing und dem word-wrap überlegt. dafür wäre eine solche struktur mit dem baum vermutlich von vorteil. bei einer riesigen datenmenge wirds zu langsam und zu gross. wenn man die datei aber in kleinere blöcke aufteilen darf, wäre so eine struktur wieder vorteilhaft.

es ist nicht möglich zu wissen wo eine zeile beginnen wird, wenn nicht alles davor bereits berechnet wurde. also bleibt nur aufteilen, oder fliessend nach oben/unten hinzufügen, ohne die bereits berechneten zeilen zu verändern.
block10:
123
12345
12
------
34512
123
12
------
34
beim aufteilen in blöcken wäre es sicher nicht so schwer, halbierte wörter zu erkennen und sie immer dem block zuzuordnen indem sie begonnen wurden.

flow (erste ansicht ist fett):
1
12312
1234
12123
123

im zweiten fall wäre auch eine baumstruktur nützlich, müsste aber dynamisch nodes oben/unten hinzufügen können und wenn es zu gross wird auch wieder entfernen. wird dann ein resize ausgelöst, können die zeilen schneller neu berechnet werden. es muss wirklich nicht der baum sein, aber mir fällt nichts besseres ein.

[Alexander Kornrumpf]

Mich würde eher interessieren, woher Krishty bei einem Binärformat ohne Leerzeichen überhaupt weiß, dass ein Wort endet. Diese Informationsquelle kann man sicherlich bei der geschickten Implementierung ausnutzen bzw. vielleicht tut er das ja auch schon. Um den Preis dass es dann für einen allgemeinen Texteditor endgültig nicht mehr funktionieren würde.

[odenter]

Mich würde eher interessieren, woher Krishty bei einem Binärformat ohne Leerzeichen überhaupt weiß, dass ein Wort endet. Diese Informationsquelle kann man sicherlich bei der geschickten Implementierung ausnutzen bzw. vielleicht tut er das ja auch schon. Um den Preis dass es dann für einen allgemeinen Texteditor endgültig nicht mehr funktionieren würde.

Der Viewer des TotalCommander's macht das auch so. Du konfigurierst maximale Zeilenlänge für Text- und Binärdaten.

Bei Binärdaten wird der Zeilenumbruch ignoriert und es erscheinen Scrollbalken.
Bei Textdaten wird der Zeilenumbruch nicht ignoriert und es wird umgebrochen.

Beim Scrollen ist es dann bei den Textdaten kein Problem. Wenn Du intern die Daten in einer vernünftigen Struktur hast und aktuell Zeile 10 ganz oben ist und Du jetzt hoch scrollst weisst Du, Du kannst 80 Zeichen anzeigen (Fontgröße und so) in Zeile 9 aber in Deiner internen Struktur 140 Zeichen sind, dann wendest Deine WievieleZeichenKannIchAnzeigenFunktion an und bekommst 60 Zeichen zum anzeigen geliefert und gibst die an die RenderMeineTextFunktion.

Das gleiche würde auch gelten wenn ich meine Binärdaten in eine interne Liste mit Items der Länge x einlese.

Zur Performance kann ich nur auf den Code von http://www.catch22.net verweisen, das Ding kann mit größen Dateien (gerade 1GB getestet) und ist trotzdem noch fix, geht also.

EDIT:
Wenn ich nur Binärdaten habe dann reicht es natürlich auch intern nur ein Array zu haben. Wenn ich dann immer fix x Zeichen pro Zeile anzeige ist es einfach.

[Krishty]

Mich würde eher interessieren, woher Krishty bei einem Binärformat ohne Leerzeichen überhaupt weiß, dass ein Wort endet. Diese Informationsquelle kann man sicherlich bei der geschickten Implementierung ausnutzen bzw. vielleicht tut er das ja auch schon. Um den Preis dass es dann für einen allgemeinen Texteditor endgültig nicht mehr funktionieren würde.

Kurz weil Grippe: Die macht der Benutzer selber. Ich benutze das Ding um unbekannte Binärformate zu verstehen; dann kann ich da z.B. vier Bytes markieren, als unsigned int (4 B, little endian) deklarieren, und von da an befindet sich an dieser Stelle ein Block der mit einer bestimmten Farbe hinterlegt, umrahmt, und nicht umgebrochen wird. Und der ist für diese Diskussion ein Wort.

[odenter]

Hättest Du es dann nicht?

Wenn Du ein Byte-Array hast. Und sagst ich zeige pro Zeile 64 Zeichen an.
Dann würde das ja erstmal funktionieren.

Wenn Du jetzt sagst ok ich habe ab Array-Index 60, 10 Zeichen markiert. Dann merkst Du Dir das ja irgendwo.

Wenn Du nun also 64 Zeichen pro Zeile anzeigst, dann klappt das solange bis Du bei dieser einen Zeile ankommst.
Dort zeigst Du dann nur 60 an, weil die nächsten 10 gruppiert in eine Zeile sollen, plus die nächsten 54 um wieder auf die 64 zu kommen.
Ab dann wieder weiter mit 64 Zeichen pro Zeile es sei denn Du triffst wieder auf eine Gruppe.

Beim Hochscrollen alles eben nur rückwärts.
Du zeigst aktuell eine Gruppe von 10 Zeichen + 54 an um die Zeile voll zu bekommen.
Du scrollst hoch, gehst in Deinem Array 64 Zeichen zurück und guckst ist da ne Gruppe am Ende muss ich umbrechen?
Wenn ja brichst Du um und renderst nur die Gruppe in einer eigenen Zeile über der aktuellen.

Den Rest vor der Gruppe renderst Du zwei Zeilen über der aktuellen. Wenn ich jetzt nicht nen Mega Knoten im Kopf habe sollte das beim Auf- und Abwärtsscrollen gleiche Ergebnisse bringen. Vorraussetzung ist im Grunde ne feste Breite.

[Sternmull]

Das heißt dann aber das du die Wortlängen vor der Darstellung bereits kennst. Also braucht man auch nicht mehr nach Wortgrenzen im Zeichensalat suchen. Das vereinfacht das Problem.

[Alexander Kornrumpf]

Beim Scrollen ist es dann bei den Textdaten kein Problem. Wenn Du intern die Daten in einer vernünftigen Struktur hast und aktuell Zeile 10 ganz oben ist und Du jetzt hoch scrollst weisst Du, Du kannst 80 Zeichen anzeigen (Fontgröße und so) in Zeile 9 aber in Deiner internen Struktur 140 Zeichen sind, dann wendest Deine WievieleZeichenKannIchAnzeigenFunktion an und bekommst 60 Zeichen zum anzeigen geliefert und gibst die an die RenderMeineTextFunktion.

Was hat das mit dem Problem zu tun?

EDIT:
Wenn ich nur Binärdaten habe dann reicht es natürlich auch intern nur ein Array zu haben. Wenn ich dann immer fix x Zeichen pro Zeile anzeige ist es einfach.

Bingo. Krishtys Ansinnen ist es genau, eben keine fixe Länge pro Zeile zu haben, sondern eine Maximallänge, die unterschritten werden kann, wenn ein Wort nicht mehr in die aktuelle Zeile passt. Es sei denn ich hätte es die ganze Zeit falsch verstanden, das wäre dann aber hoffentlich jemandem aufgefallen.

Kurz weil Grippe: Die macht der Benutzer selber. Ich benutze das Ding um unbekannte Binärformate zu verstehen; dann kann ich da z.B. vier Bytes markieren, als unsigned int (4 B, little endian) deklarieren, und von da an befindet sich an dieser Stelle ein Block der mit einer bestimmten Farbe hinterlegt, umrahmt, und nicht umgebrochen wird. Und der ist für diese Diskussion ein Wort.

Das heißt aber dass dein Umbruchmechanismus intern eh mit Wörtern und nicht mit Zeichen arbeitet?
As in: Zeichenbasiert in normalem Text, würde ich vielleicht bis zum nächsten Leerzeichen suchen und wüsste nicht wann das kommt. Du weißt aber im Vorhinein schon "hier beginnt ein Wort und dort wird es enden"?!

Wenn Du ein Byte-Array hast. Und sagst ich zeige pro Zeile 64 Zeichen an. Dann würde das ja erstmal funktionieren.

Das ist nicht das was er will.

Den Rest vor der Gruppe renderst Du zwei Zeilen über der aktuellen. Wenn ich jetzt nicht nen Mega Knoten im Kopf habe sollte das beim Auf- und Abwärtsscrollen gleiche Ergebnisse bringen. Vorraussetzung ist im Grunde ne feste Breite.

Ich glaube wir alle, insbesondere Kristhy, sind Programmierer genug, um nicht seitenlang darüber zu diskutieren, wie man Zeilen fester Länge in einem fixed-width Font effizient rendert. Das vorliegende Problem ist geringfügig komplexer. Oder verstehe ich deinen Vorschlag falsch.

[Alexander Kornrumpf]

Das heißt dann aber das du die Wortlängen vor der Darstellung bereits kennst. Also braucht man auch nicht mehr nach Wortgrenzen im Zeichensalat suchen. Das vereinfacht das Problem.

So verstehe ich es auch.

[odenter]

Beim Scrollen ist es dann bei den Textdaten kein Problem. Wenn Du intern die Daten in einer vernünftigen Struktur hast und aktuell Zeile 10 ganz oben ist und Du jetzt hoch scrollst weisst Du, Du kannst 80 Zeichen anzeigen (Fontgröße und so) in Zeile 9 aber in Deiner internen Struktur 140 Zeichen sind, dann wendest Deine WievieleZeichenKannIchAnzeigenFunktion an und bekommst 60 Zeichen zum anzeigen geliefert und gibst die an die RenderMeineTextFunktion.

Was hat das mit dem Problem zu tun?

Das er beim Scrollen dann nicht seinen Versatz bekommt. Ausführliches Beispiel folgt.

Wenn Du ein Byte-Array hast. Und sagst ich zeige pro Zeile 64 Zeichen an. Dann würde das ja erstmal funktionieren.

Das ist nicht das was er will.

Das ist die Alternative zu dem obigen Beispiel (ausführlich unten).

Den Rest vor der Gruppe renderst Du zwei Zeilen über der aktuellen. Wenn ich jetzt nicht nen Mega Knoten im Kopf habe sollte das beim Auf- und Abwärtsscrollen gleiche Ergebnisse bringen. Vorraussetzung ist im Grunde ne feste Breite.

Ich glaube wir alle, insbesondere Kristhy, sind Programmierer genug, um nicht seitenlang darüber zu diskutieren, wie man Zeilen fester Länge in einem fixed-width Font effizient rendert. Das vorliegende Problem ist geringfügig komplexer. Oder verstehe ich deinen Vorschlag falsch.

Ich glaube Du verstehst mich falsch, mein Beispiel war vielleicht nicht ausführlich genug.

Nehmen wir an Du hast eine Datei von 64 Byte größe. Der Benutzer hat "FF FF" als ein Wort definiert. Seine Wörter kommen in unterschiedlichen Abständen vor. Aufgrund Deiner Schriftart/Schriftgröße und Fensterbreite kannst Du maximal 5 Byte in einer Zeile anzeigen.

Die Datei würde also wie folgt aussehen: (Willkürlich gewählt)
00 00 FF FF 00 00 FF FF
00 00 FF FF FF FF 00 00
FF FF 00 00 FF FF 00 00
00 00 00 00 00 00 00 00
FF FF 00 00 FF FF 00 00
FF FF FF FF 00 00 FF FF
FF FF 00 00 FF FF 00 00
FF FF FF FF 00 00 FF FF

Das ganze soll also immer so dargestellt werden:

Code: Alles auswählen

01 00 00 FF FF 
02 00 00 FF FF 00 
03 00 FF FF FF FF 
04 00 00 FF FF 
05 00 00 FF FF 00 
06 00 00 00 00 00 
07 00 00 00 00 
08 FF FF 00 00 
09 FF FF 00 00 
10 FF FF FF FF 00 
11 00 FF FF FF FF 
12 00 00 FF FF 00 
13 00 FF FF FF FF 
14 00 00 FF FF 

So ich hoffe ich hab mich jetzt nicht verzählt, ist schon spät.
Wenn er an diesem Beispiel 5 Zeilen in der Höhe anzeigen kann, weil sein Fenster nunmal nicht Höher ist.
Dann würde er vielleicht folgendes anzeigen: (Renderer bekommt StartOffset 41 und soviele Daten wie maximal ins Fenster passen)

Code: Alles auswählen

10 FF FF FF FF 00 
11 00 FF FF FF FF 
12 00 00 FF FF 00 
13 00 FF FF FF FF 
14 00 00 FF FF

Er will jetzt eine Zeile nach oben Scrollen und seinen WordWrap behalten, er will also folgendes anzeigen: (Renderer bekommt StartOffset 37)

Code: Alles auswählen

09 FF FF 00 00 
10 FF FF FF FF 00 
11 00 FF FF FF FF 
12 00 00 FF FF 00 
13 00 FF FF FF FF 

Das kann er machen weil er weiss das er ab Byte 41 gerendert hat und in der obersten Zeile 4 Bytes angezeigt werden, das muss er sich merken.
Also gibt er soviele Daten wie er maximal Rendern kann ab Offset 37 an seine Render-Funktion.

Völlig egal wie seine interne Struktur aussieht. Er gibt einfach den neuen StartOffset (Der zu rendernden Zeile) an seine TextRender Funktion und von da an wird dann eben gerendert was ins Bild passt, spielt keine Rolle in welche Richtung gescrollt wird, angezeigt wird immer die identische Reihenfolge ohne Versatz. Darum ging es wenn ich es richtig verstanden habe bzw. seinen mehrfach vorhandenen Code zum durchlaufen der Daten und ermitteln der Umbrüche.
Das bedeutet er muss immer nur soviele Bytes der Daten prüfen wie maximal angezeigt werden können, die Menge kennt er weil er Sie am Anfang berechnet hat. Und nur wenn er Sie auch wirklich darstellt, das wisst Ihr doch am besten. :)
Das ganze ist natürlich einfacher wenn man eine interne Struktur hat, vor allem wenn die Datei dann noch bearbeitet werden soll, was ich vorausgesetzt habe, oder neue/gefundene Wörter zur Laufzeit zusätzlich definiert werden.

Der automatische WordWrap ist immer bei maximaler Anzahl renderbarer Zeichen pro Zeile, einmal am Anfang berechnen und wenn die Fenstergröße verändert wird, und dann springen natürlich auch die Worte hin und her.
Und nach einem oder mehreren Wörtern die durch den Benutzer definiert werden.

Besonderheit:
Wenn Du in der Breite weniger Zeichen anzeigen kannst als Dein längstes Wort lang ist. Dann musst du halt entscheiden ob/wie Du das Wort umbrechen willst, im Zweifel nach der maximal darstellbaren Anzahl Zeichen, und danach geht es normal weiter.

Da er weiss wieviele Zeilen und Bytes pro Zeile er in sein Fenster rendern kann, verschiebt er einfach seinen StarOffset wenn sein Cursor in der ersten angezeigten Zeile steht und ARROW_UP drückt oder wenn sein Cursor in der letzten angezeigten Zeile steht und er ARROW_DOWN drückt.
Gleiches gilt für PAGE_UP und PAGE_DOWN, nur das es dann nicht -1/+1 sondern -RenderbareAnzahlZeilen/+RenderbareAnzahlZeilen ist.

Fertig.

Die Editoren der Seite auf die ich verwiesen habe machen das im Grunde so.
Wenn aus der Datei mittels Memory-Mapped file gelesen wird ist es auch performant genug, die machen den Text sogar noch bunt nebenbei.

Auf den ersten Seiten wurde diese Art von anderen Vorgeschlagen, wurde nicht so beschrieben aber ich glaube das haben Sie gemeint.
Stellt Euch statt ein durch den Benutzer definiertes Wort einfach den Trenner 0D0A vor, schon haste einen normalen Texteditor.

[Alexander Kornrumpf]

Das ganze soll also immer so dargestellt werden:

Code: Alles auswählen

01 00 00 FF FF 
02 00 00 FF FF 00 
03 00 FF FF FF FF 
04 00 00 FF FF 
05 00 00 FF FF 00 
06 00 00 00 00 00 
07 00 00 00 00 
08 FF FF 00 00 
09 FF FF 00 00 
10 FF FF FF FF 00 
11 00 FF FF FF FF 
12 00 00 FF FF 00 
13 00 FF FF FF FF 
14 00 00 FF FF 

Ich verstehe nicht, warum 00 00 manchmal umgebrochen wird und manchmal nicht. Vgl. Zeile 01 und Zeile 05. Aber seis drum, ich glaube das ist nicht kritisch hier.

Dann würde er vielleicht folgendes anzeigen: (Renderer bekommt StartOffset 41 und soviele Daten wie maximal ins Fenster passen)
[...]

Er will jetzt eine Zeile nach oben Scrollen und seinen WordWrap behalten, er will also folgendes anzeigen: (Renderer bekommt StartOffset 37)

[...]

Das kann er machen weil er weiss das er ab Byte 41 gerendert hat und in der obersten Zeile 4 Bytes angezeigt werden, das muss er sich merken.
Also gibt er soviele Daten wie er maximal Rendern kann ab Offset 37 an seine Render-Funktion.

Völlig egal wie seine interne Struktur aussieht. Er gibt einfach den neuen StartOffset (Der zu rendernden Zeile) an seine TextRender Funktion und von da an wird dann eben gerendert was ins Bild passt, spielt keine Rolle in welche Richtung gescrollt wird, angezeigt wird immer die identische Reihenfolge ohne Versatz. Darum ging es wenn ich es richtig verstanden habe bzw. seinen mehrfach vorhandenen Code zum durchlaufen der Daten und ermitteln der Umbrüche.

(Hervorhebung von mir)

Deinen Einsatz in allen Ehren, aber dass es klappt, wenn man sich die Länge aller Zeilen merkt, war bekannt. Wenn ich dein Total Commander Beispiel richtig verstehe gehst du aber von einer festen Zeilenlänge aus. Die gibt es hier nicht, sondern die Zeilenlänge ändert sich mit der Fenstergröße. Dann muss der ganze Text nochmal durchlaufen werden. Du schreibst es ja weiter unten selbst.

Die Frage ist hier ob man das vermeiden kann (eine nicht-perfekte Lösung dafür ist eben Rückwärtssuche) oder, wenn es sich nicht vermeiden lässt, ob es eine schnellere Implementierung dafür gibt, als die naive.

Auf den ersten Seiten wurde diese Art von anderen Vorgeschlagen, wurde nicht so beschrieben aber ich glaube das haben Sie gemeint.

Danke dass du es nochmal erklärt hast, auch weil ich dich beim ersten Mal falsch verstanden hatte. Ich glaube aber die Lösung die du jetzt beschrieben hast war den diskutanten schon klar :/

[odenter]

Dieses Beispiel ist hier jetzt nicht mehr mein TotalCommander (der macht tatsächlich fixe Länge bei Binärdateien [wie eben jeder Hexeditor] in der Anzeige), finde ich persönlich besser aber das will er ja nicht.

Er braucht nicht die Länge ALLER Zeilen. :) Sondern nur die der ERSTEN angezeigten und LETZTEN angezeigten, für das richtige scrollen. (ohne Größenänderung des Fensters)
Und er braucht bei einer Änderung der Fenstergröße auch nicht ALLE Daten erneut durchlaufen.
Sondern nur den Teil der Daten die angezeigt werden.

Die performante, Speicher schonende Lösung für das schnelle lesen/schreiben großer Dateien sind daher Memory-Mapped files, egal in welche Richtung. (Dieser Punkte wurde als mögliches Problem am Anfang in die Diskussion gebracht, ist aber keiner)
Wenn er das macht dann ist das durchlaufen von 4K Daten kein Problem, es sei denn wir reden von einem Smartphone.

00 00 wird mal und mal nicht umgebrochen weil er mindestens zwei Zeilenumbrüche hat.
- Die "Harten" nach bestimmten, definierten Worten
und
- Die "Weichen" (WordWrap) wenn keine Zeichen mehr in das Fenster passen und es kein definiertes Wort ist.

Wenn er das bereits so umgesetzt hat, dann dürfte er kein performance Problem haben und auch keinen doppelten Code für das ermitteln der Zeilenumbrüche, und das war glaube ich ja nicht der Fall.

[Alexander Kornrumpf]

Und er braucht bei einer Änderung der Fenstergröße auch nicht ALLE Daten erneut durchlaufen.
Sondern nur den Teil der Daten die angezeigt werden.

Tut mir leid, ich kapiers immer noch nicht.

In deinem Beispiel werden erst Zeilen 10-14 angezeigt. Um zu wissen dass beim Scrollen zu Zeile 9 der "Offset" um 4 kleiner wird (und nicht um 5 wie es hypothetisch auch möglich wäre) muss ich erstmal wissen dass Zeile 9, eine nicht angezeigte Zeile 4 und nicht 5 Zeichen lang ist. Wenn sich die Fenstergröße ändert, ändern sich auch die Umbrüche der Zeilen die nicht angezeigt werden. Meinetwegen bleibt der Offset der Anzeige sogar gleich, wenn du die linke obere Ecke als Fixpunkt nimmst (dazu hatte ich oben was geschrieben). Was sich aber garantiert ändern wird ist der Offset der neuen vorherigen Zeile.

Frage: Woher kennst du den neuen Offset, der nicht angezeigten Zeile, wenn du nur angezeigte Daten bei Änderung der Fenstergröße neu umbrichst?

Falls es nicht klar sein sollte: Zum alten Offset zurückzuscrollen funktioniert nicht, da es genau zum Worst-Case führt, nämlich dass sich beim scrollen die sichtbaren Zeilenumbrüche ändern. Alle bisher genannten Lösungen sind besser als das.

[BeRsErKeR]

Mich würde eher interessieren, woher Krishty bei einem Binärformat ohne Leerzeichen überhaupt weiß, dass ein Wort endet. Diese Informationsquelle kann man sicherlich bei der geschickten Implementierung ausnutzen bzw. vielleicht tut er das ja auch schon. Um den Preis dass es dann für einen allgemeinen Texteditor endgültig nicht mehr funktionieren würde.

Kurz weil Grippe: Die macht der Benutzer selber. Ich benutze das Ding um unbekannte Binärformate zu verstehen; dann kann ich da z.B. vier Bytes markieren, als unsigned int (4 B, little endian) deklarieren, und von da an befindet sich an dieser Stelle ein Block der mit einer bestimmten Farbe hinterlegt, umrahmt, und nicht umgebrochen wird. Und der ist für diese Diskussion ein Wort.

Wenn du eh schon die Logik für die Definition eines Wortes drin hast; was hält dich davon ab, hinter das definierte Wort ein reales Leerzeichen einzufügen und normales Word-Wrap einzusetzen? Ob das Leerzeichen nun angezeigt wird oder nicht ist ja nicht wichtig. Aber ein Trennzeichen einzufügen, vereinfacht doch den Word-Wrap-Algo ungemein und du kannst definiert sagen wann und wo der hin muss.

[Alexander Kornrumpf]

normales Word-Wrap einzusetzen?

Die Ausgangsfrage war wohl wie "normales" Word-Wrap geht.

[BeRsErKeR]

Das wurde doch nun schon ein paar mal gesagt. Zur Not können die Zeilenumbrüche auch einfach nur dann hinter ein Wort gesetzt werden, wenn das nächste nicht mehr passt. Ist dann noch einfacher.